Migrar as regras de detecção do Splunk para o Microsoft Sentinel

As regras de detecção do Splunk são componentes de gerenciamento de eventos e informações de segurança (SIEM) e podem ser comparadas às regras de análise no Microsoft Sentinel. Este artigo aborda os principais conceitos para identificar, comparar e migrar essas regras para o Microsoft Sentinel. A melhor maneira de começar é utilizando a experiência de migração de SIEM, que identifica automaticamente as regras de análise prontas para uso (OOTB) para tradução automática.

Se você quiser migrar sua implantação de Observabilidade do Splunk, saiba mais sobre como migrar do Splunk para os Logs do Azure Monitor.

Regras de auditoria

O Microsoft Sentinel usa a análise de aprendizado de máquina para criar incidentes acionáveis e de alta fidelidade. Algumas das detecções existentes no Splunk podem ser redundantes no Microsoft Sentinel. Examine essas considerações à medida que identifica as regras de detecção existentes.

• Selecione casos de uso que justifiquem a migração da regra, considerando a prioridade e a eficiência dos negócios.
• Verifique se você entende os tipos de regras do Microsoft Sentinel.
• Verifique se você entende a terminologia de regras.
• Por isso, é importante revisar as regras desatualizadas, principalmente aquelas que não geraram alertas nos últimos 6 a 12 meses, para verificar se ainda são relevantes.
• Elimine ameaças de baixo nível ou alertas que você costuma ignorar.
• Confirme as fontes de dados conectadas e examine os métodos de conexão de dados. A Análise do Microsoft Sentinel exige que o tipo de dados já esteja presente no workspace do Log Analytics antes de habilitar qualquer regra. Reveja as conversas de coleta de dados a fim de garantir a profundidade e a amplitude dos dados nos casos de uso que você planeja detectar. Depois utilize a experiência de migração de SIEM para garantir o correto mapeamento das fontes de dados.

Migrar regras

Depois de identificar as detecções do Splunk a serem migradas, confira estas considerações para o processo de migração:

• Compare as funcionalidades das regras de análise OOTB do Microsoft Sentinel com seus casos de uso atuais. Use a experiência de migração de SIEM para verificar quais detecções do Splunk são automaticamente convertidas em modelos OOTB.
• Traduza manualmente as detecções que não se alinham com as regras de análise OOTB. A melhor maneira de traduzir automaticamente as detecções do Splunk é com a experiência de migração do SIEM.
• Descubra mais algoritmos para os seus casos de uso explorando os recursos da comunidade, como o Marketplace de Detecção de Ameaças do SOC Prime.
• Traduza manualmente as detecções se as regras internas não estiverem disponíveis ou não forem traduzidas automaticamente. Crie as novas consultas KQL e revise o mapeamento de regras.

Para mais informações, confira as melhores práticas para migrar regras de detecção.

Etapas para migrar regras

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

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

   2. Verifique se a equipe tem recursos úteis para testar suas regras migradas.

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

2. Verifique se as detecções estão disponíveis como modelos OOTB no Microsoft Sentinel:

   • Use a experiência de migração do SIEM para automatizar a tradução e a instalação dos modelos OOTB.

     Para obter mais informações, consulte Usar a experiência de migração do SIEM.

   • Se suas detecções não cobrirem todos os seus casos de uso, crie suas próprias regras no workspace usando os modelos de regras OOTB.

     No Microsoft Sentinel, vá para a página Hub de conteúdo.

     Filtre pelo Tipo de conteúdo para obter modelos de Regra de análise.

     Encontre e instale/atualize cada solução correspondente do Hub de conteúdo ou modelo de regra de análise independente.

     Para saber mais, confira Detectar ameaças prontas para uso.

   • Se você tiver detecções que não são cobertas pelas regras OOTB do Microsoft Sentinel, o primeiro passo é tentar a experiência de migração do SIEM para uma tradução automática.

   • Se nem as regras OOTB nem a migração de SIEM conseguirem traduzir completamente a detecção, crie a regra manualmente. Nesses casos, siga as etapas abaixo para criar sua regra:

     1. Identifique as fontes de dados que você deseja usar em sua regra. Identifique as tabelas do Microsoft Sentinel que deseja consultar, criando uma tabela de mapeamento entre as fontes de dados e as tabelas de dados correspondentes.

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

     3. Identifique os critérios de regra e a lógica. Nesta fase, encontre modelos de regras que possam servir de exemplo para construir suas consultas KQL.

        Considere filtros, regras de correlação, listas ativas, conjuntos de referência, watchlists, anomalias de detecção, agregações e assim por diante. Você pode usar referências fornecidas pelo SIEM herdado a fim de entender como mapear melhor a sintaxe da sua consulta.

     4. Identifique a condição de gatilho e a ação de regra e, em seguida, construa e revise sua consulta KQL. Ao revisar sua consulta, considere os recursos de diretrizes de otimização do KQL.

3. Teste a regra com cada um de seus casos de uso relevantes. Revise e edite o KQL se os resultados não forem satisfatórios, testando novamente até alcançar os resultados esperados.

4. Quando os resultados forem satisfatórios, você poderá considerar a regra migrada. Crie um guia estratégico para sua ação de regra, conforme necessário. Para saber mais, confira Automatizar a resposta a ameaças com guias estratégicos no Microsoft Sentinel.

Saiba mais sobre as regras de análise:

• Criar regras de análise personalizadas para detectar ameaças. Use o agrupamento de alertas para reduzir a fadiga agrupando os alertas que ocorrem em um determinado período de tempo.
• Mapeie campos de dados para entidades no Microsoft Sentinel a fim de permitir que os engenheiros de SOC definam entidades como parte da evidência a ser rastreada durante uma investigação. O mapeamento de entidade também possibilita que os analistas do SOC tirem proveito de um intuitivo [gráfico de investigação] (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 do UEBA, como um exemplo de como usar evidências para ver eventos, alertas e quaisquer indicadores associados a um incidente específico no painel de visualização de incidentes.
• O KQL (Linguagem de Consulta Kusto), que você pode usar para enviar solicitações somente leitura ao 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 para Ponto de Extremidade e o Application Insights.

Comparar a terminologia de regra

Esta tabela esclarece as diferenças entre uma regra baseada na Linguagem de Consulta Kusto (KQL) no Microsoft Sentinel comparada a uma detecção do Splunk, que usa a Linguagem de Processamento de Busca (SPL).

Mapear e comparar exemplos de regra

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

Comandos de pesquisa comuns

Comando lookup: exemplo de KQL

Users 
| where UserID in ((externaldata (UserID:string) [
@"https://storageaccount.blob.core.windows.net/storagecontainer/users.txt" 
h@"?...SAS..." // Secret token to access the blob 
])) | ... 

Comando stats: exemplo de KQL

Sales 
| summarize NumTransactions=count(), 
Total=sum(UnitPrice * NumUnits) by Fruit, 
StartOfMonth=startofmonth(SellDateTime) 

Comando mstats: exemplo de KQL

T | summarize count() by price_range=bin(price, 10.0) 

Comando transaction: exemplo de SPL

sourcetype=MyLogTable type=Event
| transaction ActivityId startswith="Start" endswith="Stop"
| Rename timestamp as StartTime
| Table City, ActivityId, StartTime, Duration

Comando transaction: exemplo de KQL

let Events = MyLogTable | where type=="Event";
Events
| where Name == "Start"
| project Name, City, ActivityId, StartTime=timestamp
| join (Events
| where Name == "Stop"
| project StopTime=timestamp, ActivityId)
on ActivityId
| project City, ActivityId, StartTime, 
Duration = StopTime – StartTime

Use row_window_session() para calcular os valores de início da sessão para uma coluna em um conjunto de linhas serializado.

...| extend SessionStarted = row_window_session(
Timestamp, 1h, 5m, ID != prev(ID))

Comando eventstats: exemplo de SPL

… | bin span=1m _time
|stats count AS count_i by _time, category
| eventstats sum(count_i) as count_total by _time

Comando eventstats: exemplo de KQL

Aqui está um exemplo com a instrução join:

let binSize = 1h;
let detail = SecurityEvent 
| summarize detail_count = count() by EventID,
tbin = bin(TimeGenerated, binSize);
let summary = SecurityEvent
| summarize sum_count = count() by 
tbin = bin(TimeGenerated, binSize);
detail 
| join kind=leftouter (summary) on tbin 
| project-away tbin1

Aqui está um exemplo com a instrução make_list:

let binSize = 1m;
SecurityEvent
| where TimeGenerated >= ago(24h)
| summarize TotalEvents = count() by EventID, 
groupBin =bin(TimeGenerated, binSize)
|summarize make_list(EventID), make_list(TotalEvents), 
sum(TotalEvents) by groupBin
| mvexpand list_EventID, list_TotalEvents

Comando anomalydetection: exemplo de SPL

sourcetype=nasdaq earliest=-10y
| anomalydetection Close _ Price

Comando anomalydetection: exemplo de KQL

let LookBackPeriod= 7d;
let disableAccountLogon=SignIn
| where ResultType == "50057"
| where ResultDescription has "account is disabled";
disableAccountLogon
| make-series Trend=count() default=0 on TimeGenerated 
in range(startofday(ago(LookBackPeriod)), now(), 1d)
| extend (RSquare,Slope,Variance,RVariance,Interception,
LineFit)=series_fit_line(Trend)
| extend (anomalies,score) = 
series_decompose_anomalies(Trend)

Comandos eval comuns

Exemplo de SPL case(X,"Y",…)

case(error == 404, "Not found",
error == 500,"Internal Server Error",
error == 200, "OK")

Exemplo de KQL case(X,"Y",…)

T
| extend Message = case(error == 404, "Not found", 
error == 500,"Internal Server Error", "OK") 

Exemplo de KQL if(X,Y,Z)

iif(floor(Timestamp, 1d)==floor(now(), 1d), 
"today", "anotherday")

Exemplo de KQL isint(X)

iif(gettype(X) =="long","TRUE","FALSE")

Exemplo de KQL isstr(X)

iif(gettype(X) =="string","TRUE","FALSE")

Exemplo do like(X,"y")

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

… | where field matches regex "^addr.*"

Exemplo de KQL min(X,…)

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

Exemplo de KQL mvfilter(X)

T | mv-apply Metric to typeof(real) on 
(
 top 2 by Metric desc
)

Exemplo de KQL mvjoin(X,Y)

strcat_array(dynamic([1, 2, 3]), "->")

Exemplo de KQL relative time(X,Y)

let toUnixTime = (dt:datetime)
{
(dt - datetime(1970-01-01))/1s 
};

Exemplo de KQL replace(X,Y,Z)

replace( @'^(\d{1,2})/(\d{1,2})/', @'\2/\1/',date)

Exemplo de KQL strptime(X,Y)

format_datetime(datetime('2017-08-16 11:25:10'),
'HH:mm')

Exemplo de KQL time()

format_datetime(datetime(2015-12-14 02:03:04),
'h:m:s')

tostring(X,Y)

Retorna um valor de campo X como uma cadeia de caracteres.

• Se o valor X for um número, X será reformatado como um valor de cadeia de caracteres.
• Se X for um valor booliano, X será reformatado para TRUE ou FALSE.
• Se X for um número, o segundo argumento Y será opcional e poderá ser hex (converte X para hexadecimal), commas (formata X com vírgulas e duas casas decimais) ou duration (converte X de um formato de tempo em segundos para um formato de tempo legível: HH:MM:SS).

Exemplo de SPL tostring(X,Y)

Este exemplo retorna:

foo=615 and foo2=00:10:15:

… | eval foo=615 | eval foo2 = tostring(
foo, "duration")

Exemplo de SPL urldecode(X)

urldecode("http%3A%2F%2Fwww.splunk.com%2Fdownload%3Fr%3Dheader")

Exemplo de KQL de comandos stats comuns

Próximas etapas

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