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

As regras de deteção do Splunk são componentes de gestão de informações e eventos de segurança (SIEM) que se comparam às regras de análise no Microsoft Sentinel. Este artigo descreve os conceitos para identificar, comparar e migrar para Microsoft Sentinel. A melhor forma é começar com a experiência de migração SIEM, que identifica regras de análise OOTB (out-of-the-box) para traduzir automaticamente.

Se quiser migrar a implementação de Observabilidade do Splunk, saiba mais sobre como migrar do Splunk para o Azure Monitorizar Registos.

Regras de auditoria

Microsoft Sentinel utiliza a análise de machine learning para criar incidentes acionáveis e de alta fidelidade. Algumas das suas deteções do Splunk existentes podem ser redundantes no Microsoft Sentinel, por isso não as migre todas cegamente. 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 desatualizadas que não têm 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.
• Confirme as origens de dados ligadas e reveja os métodos de ligação de dados. Microsoft Sentinel Analytics requer que o tipo de dados esteja presente na área de trabalho do Log Analytics antes de uma regra ser ativada. 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. Em seguida, utilize a experiência de migração SIEM para garantir que as origens de dados são mapeadas adequadamente.

Migrar regras

Depois de identificar as deteções do Splunk a migrar, veja estas considerações sobre o processo de migração:

• Compare a funcionalidade existente das regras de análise OOTB do Microsoft Sentinel com os seus casos de utilização atuais. Utilize a experiência de migração SIEM para ver que deteções do Splunk são convertidas automaticamente em modelos OOTB.
• Traduzir deteções que não estão alinhadas com as regras de análise OOTB. A melhor forma de traduzir automaticamente deteções do Splunk é com a experiência de migração SIEM.
• Descubra mais algoritmos para os seus casos de utilização ao explorar recursos da comunidade, como o Marketplace de Deteção de Ameaças Principais do SOC.
• Traduzir manualmente as deteções se as regras incorporadas não estiverem disponíveis ou não forem traduzidas automaticamente. Crie as novas consultas KQL e reveja o mapeamento de regras.

Para obter mais informações, veja melhores práticas para migrar regras de deteção.

Passos de migração de regras

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 OOTB no Microsoft Sentinel:

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

     Para obter mais informações, veja Utilizar a experiência de migração SIEM.

   • Se tiver casos de utilização não refletidos nas deteções, crie regras para a sua própria área de trabalho com modelos de regras OOTB.

     Em Microsoft Sentinel, aceda ao Hub de conteúdos.

     Filtrar Tipo de conteúdo para modelos de regras de Análise .

     Localizar e Instalar/Atualizar cada solução do Hub de conteúdos correspondente ou modelo de regra de análise autónoma.

     Para obter mais informações, consulte Detetar ameaças fora da caixa.

   • Se tiver deteções que não estão abrangidas pelas regras OOTB de Microsoft Sentinel, experimente primeiro a experiência de migração SIEM para tradução automática.

   • Se nem as regras OOTB nem a migração SIEM traduzirem completamente a deteção, crie a regra manualmente. Nestes casos, utilize os seguintes passos para criar a regra:

     1. Identifique as origens de dados que pretende utilizar na regra. Identifique as tabelas de Microsoft Sentinel que pretende consultar ao criar uma tabela de mapeamento entre origens de dados e tabelas de dados.

     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, considere encontrar 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, reveja e edite o KQL e teste-o novamente.

4. Quando estiver satisfeito, considere 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 Consulta 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 Ponto de Extremidade e o Application Insights.

Comparar terminologia de regra

Esta tabela ajuda-o a clarificar o conceito de uma regra com base no Linguagem de Consulta Kusto (KQL) no Microsoft Sentinel em comparação com uma deteção do Splunk com base na Linguagem de Processamento de Pesquisa (SPL).

Mapear e comparar exemplos de regras

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

Comandos de pesquisa comuns

lookup comando: 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 
])) | ... 

stats comando: exemplo de KQL

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

mstats comando: exemplo de KQL

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

transaction comando: exemplo de SPL

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

transaction comando: 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

Utilize row_window_session() para calcular valores de início de sessão para uma coluna num conjunto de linhas serializado.

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

eventstats comando: exemplo de SPL

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

eventstats comando: exemplo de KQL

Eis um exemplo com a join instrução :

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

Eis um exemplo com a make_list instrução :

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

anomalydetection comando: exemplo de SPL

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

anomalydetection comando: 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 comuns eval

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

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

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

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

if(X,Y,Z) Exemplo de KQL

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

isint(X) Exemplo de KQL

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

isstr(X) Exemplo de KQL

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

like(X,"y") exemplo

… | where field has "addr"

… | where field contains "addr"

… | where field startswith "addr"

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

min(X,…) Exemplo de KQL

min_of (expr_1, expr_2 ...)

…|summarize min(expr)

…| summarize arg_min(Price,*) by Product

mvfilter(X) Exemplo de KQL

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

mvjoin(X,Y) Exemplo de KQL

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

relative time(X,Y) Exemplo de KQL

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

replace(X,Y,Z) Exemplo de KQL

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

strptime(X,Y) Exemplo de KQL

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

time() Exemplo de KQL

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

tostring(X,Y)

Devolve um valor de campo de X como uma cadeia.

• Se o valor de X for um número, X será reformatado para um valor de cadeia.
• Se X for um valor booleano, X é reformatado para TRUE ou FALSE.
• Se X for um número, o segundo argumento Y é opcional e pode ser hex (convertido X num hexadecimal), commas (formatos com vírgulas X 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).

tostring(X,Y) Exemplo de SPL

Este exemplo devolve:

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

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

urldecode(X) Exemplo de SPL

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

Exemplo de KQL de comandos comuns stats

Próximas etapas

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