Seguir A portabilidade de regras de detecção é a prática de escrever e gerenciar a lógica de detecção de ameaças de forma que ela se mova entre plataformas SIEM, EDR e XDR sem uma reescritura completa.
O que acontece com minhas regras de detecção quando migro para uma nova plataforma SIEM?
Regras escritas em uma linguagem de consulta nativa de uma plataforma não viajam. SPL permanece no Splunk. KQL permanece no Microsoft Sentinel. YARA-L permanece no Google SecOps. Quando você migra, essas regras devem ser reescritas ou traduzidas para a plataforma de destino.
A fidelidade da tradução depende da construção, não do par de idiomas. Dois eixos de degradação decidem o que sobrevive.
Eixo 1: mapeamento de campos. As taxonomias de campos de origem (CIM, ASIM, ECS, OCSF, Sysmon-native, vendor-native) mapeiam de forma incompleta. Um campo não mapeado ou renomeado silenciosamente estreita ou quebra a regra.
Eixo 2: semântica de construção. Semântica de agregação e janela de tempo, lógica de sequência ou transação, dialeto regex e funções do tipo eval/lookup/join geralmente têm apenas análogos parciais na plataforma de destino. Este eixo carrega a parcela de reescrita.
Sigma regras são projetadas para tradução. Elas são elaboradas uma vez e traduzidas por backend via pySigma, sigma-cli, ou Uncoder.
A tradução não é preservação. Cada regra traduzida ainda requer validação específica do backend contra os campos analisados do destino antes de ser confiável. Uma tradução sintaticamente correta pode referenciar campos que a nova plataforma nunca popula.
O roteamento do pipeline de telemetria é um mecanismo separado. Roteando um fluxo de log para um novo destino não transporta a lógica de detecção que correu nesse fluxo. SPL permanece SPL independentemente de onde os logs aterrissam.
Qual é a diferença entre regras de detecção específicas de fornecedor e agnósticas de fornecedor?
Uma regra específica de fornecedor é um ativo da plataforma. Uma regra agnóstica de fornecedor é um ativo da equipe.
| Dimensão | SPL (Splunk) | KQL (Microsoft Sentinel) | YARA-L (Google SecOps) | Sigma |
|---|---|---|---|---|
| Executa nativamente em | Splunk | Microsoft Sentinel | Google SecOps | Nenhum diretamente. Traduz para todos os três mais IBM QRadar, Elastic, CrowdStrike, e outros. |
| Movê-lo requer | Reescreva na linguagem alvo | Reescreva na linguagem alvo | Reescreva na linguagem alvo | Tradução via pySigma/sigma-cli ou Uncoder, depois validação de mapeamento de campos |
| Quem possui | A implantação do Splunk | O workspace do Sentinel | O inquilino do SecOps | Sua equipe, no controle de versão |
| Custo multiplataforma | Escrever N cópias | Escrever N cópias | Escrever N cópias | Traduzir uma vez por backend, validar uma vez por backend |
A diferença de custo aparece na migração e na operação multiplataforma. A lógica de detecção agnóstica de fornecedor permanece portátil em todo o seu stack.
Como faço para migrar conteúdo de detecção do Splunk para o Microsoft Sentinel?
Seis passos. Este é um dos pares de idiomas mais difíceis porque SPL e KQL diferem no modelo de dados, nomeação de campos e semântica de funções.
- Inventário das regras SPL. Exporte cada pesquisa salva, alerta e pesquisa de correlação. Registre as dependências do modelo de dados de cada regra (tipo de fonte, índice, nomes de campos).
- Classifique por tipo de construção. Classifique as regras em três cestos: lógica de seleção simples (ports clean), dependente de mapeamento de campos (ports com trabalho de mapeamento) e lógica de correlação/estado (espera uma reescrita manual).
- Traduza via Sigma. Converta regras SPL para Sigma, depois traduza Sigma para KQL usando pySigma com o backend do Microsoft Sentinel, sigma-cli, ou Uncoder. Isso lida com sintaxe. Não lida com mapeamento de campos.
- Mapeie campos contra o esquema Sentinel. Alinhe os nomes de campos CIM aos equivalentes ASIM. Microsoft documenta seu esquema em learn.microsoft.com. Cada campo na regra traduzida deve se resolver para uma coluna na tabela de destino.
- Teste em tabelas do Sentinel. Execute cada regra traduzida contra dados reais ingeridos. Mantenha um evento de teste por regra para que você possa verificar a correspondência após qualquer alteração de esquema.
- Realize a mudança com uma janela de execução paralela. Execute ambas as plataformas nas mesmas fontes de log. Compare a saída de alertas. Retire a versão SPL somente após a versão KQL acionar os mesmos eventos.
Antes da mudança, mapeie as regras implantadas em ambas as plataformas para MITRE ATT&CK técnicas e compare os dois mapas, para que uma técnica que a migração deixe de fora apareça antes da mudança, não depois; o MITRE ATT&CK Audit do SOC Prime mapeia detecções e fontes de dados implantadas para ATT&CK como um serviço.
Migrando uma biblioteca de regras? Explore o Prime Architect do SOC Prime para tradução de regras entre plataformas, pesquisa de ameaças e fluxos de trabalho de engenharia de detecção.
Quais são as melhores práticas para traduzir linguagens de consulta como SPL para KQL?
Traduza a lógica, não a sintaxe. Uma portação caractere a caractere produz regras frágeis que referenciam campos que o destino pode não preencher.
- Mapeie campos contra o esquema de destino. Não presuma que os nomes de campos se transferem. Splunk CIM e Sentinel ASIM são contratos diferentes. O esforço de migração se concentra no mapeamento entre eles.
- Mantenha um evento de teste por regra. Um evento conhecido como ruim pareado com um evento conhecido como benigno. Se a regra traduzida não corresponder ao ruim e rejeitar o benigno, algo quebrou na tradução.
- Revise qualquer coisa que o tradutor sinalize. Tradutores automatizados lidam bem com lógica de seleção simples. Regras de correlação, funções proprietárias e agregações complexas precisam de revisão humana.
- Nomeie suas ferramentas. Prime Architect do SOC Prime traduz Sigma em 65 linguagens de detecção, migra entre linguagens de consulta nativas como SPL e KQL, aplica predefinições de mapeamento de campos para o ambiente que você conecta, e implanta a partir de um repositório governado de regras em uma plataforma de destino suportada. O Uncoder IO de código aberto cobre a etapa de tradução e pode ser executado de forma auto-hospedada (código-fonte no GitHub). Nenhum dos três elimina a validação de mapeamento de campos.
Exemplo: uma regra simples de criação de processo traduzindo EventCode=4688 e New_Process_Name (CIM Splunk) para EventID == 4688 e NewProcessName (tabela SecurityEvent do Sentinel). Mesmo fato, nome de campo diferente por contrato de plataforma.
O curinga ancorado no final do SPL se torna um operador endswith no KQL. Este par funciona porque é uma correspondência de campo de evento único. Regras de correlação não traduzem tão claramente.
Quanto tempo leva para migrar uma biblioteca de regras, e o que a impulsiona?
Três fatores determinam o esforço.
Contagem de regras. Mais regras, mais ciclos de validação. Cada regra traduzida precisa de um teste contra os dados ingeridos do destino.
Campos personalizados e dependências do modelo de dados. Regras que referenciam campos específicos de fornecedores, extrações personalizadas ou tabelas de consulta exigem trabalho de mapeamento por campo. Quanto mais personalização no código-fonte, mais trabalho manual na migração.
Esforço de validação. Cada regra traduzida deve ser validada contra os campos analisados da plataforma de destino. Uma tradução sintaticamente correta pode falhar silenciosamente se o esquema-alvo não preencher o campo referenciado.
O resultado honesto de uma avaliação de migração é uma classificação por regra: portas limpas, portas com trabalho de mapeamento ou requer uma reescrita manual. Uma única estimativa de tempo para toda a biblioteca representa incorretamente a distribuição de esforço.
Como evitar o lock-in na próxima vez?
Três práticas.
- Autor em Sigma. Escreva lógica de detecção agnóstica de fornecedor desde o início. Regras Sigma se traduzem para cada plataforma SIEM, EDR e XDR principal. Conteúdo de detecção já baseado em Sigma, como as regras Sigma em Core do SOC Prime, mantém a biblioteca portátil desde a primeira regra.
- Mantenha a lógica no controle de versão. Armazene suas regras de detecção no Git juntamente com os mapeamentos de campos e eventos de teste para cada backend alvo. As regras viajam com a equipe, não com a plataforma.
- Traduza na implantação. Use pySigma, sigma-cli ou Uncoder para gerar consultas nativas da plataforma no momento da implantação. O código-fonte permanece portátil. A saída compilada é descartável.
Esta separação significa que uma migração de plataforma muda o alvo da tradução, não a lógica de detecção.
Roteamento de telemetria através de um pipeline é o mesmo que portar suas detecções?
Não. Um pipeline de telemetria (Cribl e ferramentas semelhantes) move dados. Ele não move a lógica de detecção.
Roteando um fluxo de log do Splunk para o Microsoft Sentinel através de um pipeline entrega os eventos para um novo destino. As regras SPL que rodavam nessas séries de eventos no Splunk não seguem. SPL permanece SPL. A lógica de detecção ainda precisa ser traduzida ou reescrita para a plataforma de destino.
O roteamento de pipeline resolve o problema de entrega dos dados. A portabilidade de detecção resolve o problema de tradução de lógica. Eles são independentes. Uma equipe que roteia telemetria para um novo SIEM sem portar suas detecções tem dados em um novo lugar e sem regras para coincidir com eles.
A exceção é um pipeline que executa as detecções: o Prime Detect do SOC Prime.
aplica regras em Sigma na camada do pipeline antes do SIEM, e sua edição de código aberto está no
. Este caso não se aplica
- Nem tudo se traduz, mesmo com Sigma. Quatro classes de construção exigem reescritas manuais na plataforma de destino. Lógica de correlação e estado.
- Contagem e agregação de valor, sequência temporal, correlação multi-evento. Sigma adicionou tipos de regras de correlação em sua especificação v2, mas o suporte no backend varia por backend do pySigma. A programação versus execução em fluxo também muda o que uma regra pode expressar. Funções proprietárias.
- Transação Splunk, expressões eval, enriquecimento acionado por pesquisa, macros. Análogos no KQL são parciais. Alguns padrões de agregação.
- Construtos de limiar-sobre-janela e padrões de stats … by … span= traduzem de forma desigual entre plataformas. Referências a campos dependentes de esquema.
A mesma regra process_creation do Sigma aterrissa em um campo diferente dependendo do pipeline. No Sysmon é Image. No Splunk Windows Security é New_Process_Name. A tradução é correta somente contra o esquema realmente implantado.
Esses construtos são onde a classificação por regra importa mais. Espere que eles requeiram validação manual e, em muitos casos, uma reescrita completa.
Lista de verificação de prontidão para migração
[ ] Inventário completo de regras exportado (pesquisas salvas, alertas, pesquisas de correlação)
[ ] Cada regra classificada: portas limpas / portas com mapeamento / reescrita necessária
[ ] Tabela de mapeamento de campos construída: esquema de origem para esquema de destino
[ ] Versões Sigma de regras portáveis criadas e armazenadas no controle de versão
[ ] Ferramentas de tradução selecionadas (pySigma/sigma-cli, Uncoder ou ambos)
[ ] Pares de eventos de teste criados por regra (um conhecido ruim, um conhecido benigno)
[ ] Regras traduzidas validadas contra tabelas de destino com dados reais ingeridos
[ ] Regras de correlação e estado identificadas para reescrita manual
[ ] Funções proprietárias catalogadas (transação, eval, pesquisas, macros)
[ ] Janela de execução paralela definida: ambas as plataformas ingerindo as mesmas fontes
[ ] Critérios de comparação de saída de alerta documentados
FAQ
O que acontece com minhas regras de detecção quando migro para uma nova plataforma SIEM?
[ ] Plano de rollback definido: condições para reverter para a plataforma de origem
Como faço para migrar conteúdo de detecção do Splunk para o Microsoft Sentinel?
Inventarie as regras SPL, classifique cada uma pelo tipo de construção, traduza através do Sigma com pySigma ou Uncoder, mapeie os campos do esquema do Splunk para o esquema do Sentinel, teste cada regra contra dados reais ingeridos do Sentinel, depois siga com uma janela de execução paralela antes de aposentar a versão SPL. Microsoft documenta o esquema do Sentinel em learn.microsoft.com.
Qual é a diferença entre regras de detecção específicas de fornecedor e agnósticas de fornecedor?
Uma regra específica de fornecedor é um ativo da plataforma na qual ela roda. Uma regra agnóstica de fornecedor elaborada em Sigma é um ativo da equipe, mantida no controle de versão e traduzida por backend. A diferença de custo surge na migração e na operação multiplataforma.
O roteamento de telemetria através de um pipeline torna minhas detecções portáteis?
Não. Um pipeline de telemetria move dados para um novo destino. Não move a lógica de detecção que rodou em cima deles. SPL permanece SPL onde quer que os logs aterrissam, então as regras ainda precisam de tradução ou reescrita.
Quais são as melhores práticas para traduzir uma linguagem de consulta como SPL para KQL?
Traduza a lógica, não a sintaxe. Mapeie todos os campos contra o esquema de destino, mantenha um evento de teste conhecido como ruim e um conhecido como benigno por regra, e revise qualquer coisa que o tradutor sinalize, pois regras de correlação e funções proprietárias precisam de revisão humana. pySigma, sigma-cli e Uncoder lidam com a tradução Sigma, e nenhum deles remove a validação de mapeamento de campos.
Avalie sua cobertura SIEM existente e crie um plano para sua transição usando Prime Hunt. Prime Hunt revisa todas as suas regras SIEM, identifica lacunas e traça um curso para cobertura completa – trabalho crítico antes de uma migração SIEM.
