Na DataRunk, como Professional Services e MSSP, fizemos inúmeros processos de migração de SIEM em nossos clientes, por inúmeras razões. Para todos eles, o SIEM era a ferramenta core de um SOC. Seus recursos formavam a base da detecção e resposta a ameaças.
Sendo o core do SOC ele também costumava ser o grande destinatário dos dados.
Esse cenário é comum. De acordo com o SANS SOC Survey 2025, 42% dos SOCs enviam todos os dados para o SIEM. Isso indica que os SOCs estão se esforçando menos para filtrar dados. Em vez disso, enviam tudo para o SIEM. Embora seja uma decisão contra-intuitiva, para muitos ela está sendo mais econômica do que o investimento de engenharia para determinar antecipadamente quais dados são realmente necessários antes de coletá-los – ainda que com consequências pesadas sobre custo.
Já o SANS State of Engineering Report 2026 mostra que 97% da engenharia de detecção acontece dentro do SIEM.
Se o SIEM é tão essencial dentro de um SOC, quando é o caso de substituí-lo? Quando é o caso de otimizá-lo? E como se prepara para iniciar a migração de SIEM?
Quando fazer uma migração de SIEM?
Várias razões podem levar uma organização a decidir migrar de SIEM, e a maioria delas está relacionada ao valor, isto é, ao retorno obtido ao usar uma tecnologia, com base no investimento realizado.
Pensou em dinheiro?
Normalmente, valor de ferramenta se diz dessa forma, mas há uma combinação de fatores que levam um SIEM a se tornar insustentável. Vejamos abaixo:
1. Funcionalidades limitadas do produto
É possível que o fornecedor não garanta que a tecnologia acompanha o ritmo da inovação e a evolução do cenário de ameaças. Ele pode não fornecer mais o que você precisa para mitigar os riscos a seu negócio.
No caso de uma solução interna, pode ser que ela funcionava bem quando sua empresa era uma startup. Com o crescimento, ela pode ter começado a perder sua utilidade, com limitações técnicas.
SIEMs legados podem não suportar ingestão em escala de nuvem, integração nativa com EDR moderno ou capacidades avançadas de machine learning.
2. Custo total de propriedade (TCO)
A descoberta de que o SIEM atual consome recursos desproporcionais em licenciamento, infraestrutura ou horas de engenharia para customizações é comum, ainda que, para quem armazena tudo no SIEM, essa seja a consequência a se pagar.
Se o custo de propriedade (TCO) de um SIEM for maior do que o valor que você considera razoável pagar, você tem basicamente duas opções:
- Aumentar o valor que o SIEM proporciona (geralmente na forma de mitigação de risco financeiro)
- Reduzir o custo de propriedade do seu SIEM.
Quando se fala de “reduzir o custo de propriedade” não se fala apenas de reduzir o custo da licença. Isso, porque o custo de propriedade envolve mais fatores que apenas o custo da solução. A forma como você calcula esse custo dependerá da sua organização, mas os fatores geralmente incluem:
- Custo da tecnologia
- Custo com pessoal
- Custo dos processos.
Vamos explorar esses conceitos rapidamente para entender melhor.
Custo da tecnologia
Certamente, o custo da licença do seu SIEM atual parece alto, mas o mesmo vale para as soluções adicionais — firewalls, proteção de endpoint, gateways de e-mail seguro e outros — que podem ser necessárias caso faltem funcionalidades no SIEM.
Além disso, há o custo dos outages, que ocorrem quando a tecnologia não funciona como esperado. Outro fator é o custo de engenharia e integrações, especialmente relacionado à integração de novas fontes de dados ou à configuração de novas correlações. Se elas forem excessivamente demoradas e complexas — ou, pior ainda, tão simples a ponto de comprometer a precisão e o valor da solução — mais alto esse custo.
Para reduzir o custo da tecnologia, muitas organizações consolidam diferentes tecnologias. Consolidação significa pegar duas ferramentas — Ferramenta A e Ferramenta B, cada uma cobrindo 50% de um caso de uso — e substituí-las por uma única ferramenta que ofereça 100% de cobertura. Isso pode ser feito de três maneiras:
- Expandindo a cobertura da Ferramenta A para 100%
- Expandindo a cobertura da Ferramenta B para 100%
- Adotando uma nova Ferramenta C, que ofereça algo novo e melhor.
Essa abordagem quase sempre se traduz em uma economia substancial de custos. Pois, embora a mudança envolva um custo (TCC), o CapEx pode se pagar facilmente ao longo do tempo por meio da redução de OpEx no longo prazo.
Custo com pessoas e processos
Os custos com pessoas e processos estão fortemente interligados, por isso estão combinados em uma única seção: o custo total do tempo de um profissional está diretamente relacionado ao tempo necessário para concluir um processo, como a triagem de alertas.
Vamos analisar o seguinte cenário:
- Um SIEM gera 1.000 alertas por dia
- Um analista demora 10 minutos para fazer a triagem de um alerta
- Um analista tem 8 horas disponíveis por dia, ou seja, 480 minutos.
Podemos expressar esse cálculo de forma simplificada:
1.000 alertas x 10 minutos por alerta = 10.000 minutos necessários
Se isso for verdade, significa que são necessários:
10.000 minutos / 480 minutos por analista = ~21 analistas por dia
Se precisamos de 21 analistas em tempo integral por dia e o custo diário total de um analista for de R$ 500, isso significa que devemos gastar, para manter a triagem de alertas em dia:
R$ 500 x 21 analistas = R$ 10.500 por dia
Agora, vamos considerar o impacto dos falsos positivos e outros fatores que podem afetar esses números. Suponha que, dos 10.000 alertas diários, 80% (8.000 alertas) sejam de baixa fidelidade — um número comum para a maioria das organizações.
Detecções de baixa fidelidade costumam gerar ruído e possuem altas taxas de falso positivo (FP). Se a taxa de FP dessas detecções for de 50%, isso significa que 4.000 dos 8.000 alertas são falsos positivos, representando 40% de todos os alertas diários.
Agora, refazendo os cálculos:
- 40% de 10.000 alertas = 4.000 alertas FP
- 4.000 minutos / 480 minutos por analista = ~9 analistas por dia
- R$ 500 x 9 analistas = R$ 4.500 por dia.
Isso mostra como falsos positivos impactam diretamente os custos operacionais do SOC, tornando essencial a otimização das regras de detecção e a automação para reduzir alertas desnecessários.
Se 40% dos seus alertas forem falsos positivos de baixa fidelidade, você acabaria gastando R$ 4.500 por dia apenas para triá-los.
Na prática, calcular o custo de um analista é mais complexo do que esse exemplo simplificado. No entanto, esse exemplo ilustra como gerenciar o custo com processos e pessoas é um fator essencial para otimizar o custo de propriedade.
O que considerar antes de decidir pela migração de SIEM?
Custo total de mudança (TCC)
Se sua empresa decidir que a melhor maneira de reduzir o custo propriedade é substituir um SIEM, essa transição terá um custo.
O Custo Total de Mudança (TCC) abrange todos os custos envolvidos na migração para uma nova tecnologia. O custo de implementação é apenas um dos elementos dele; treinamento e valor percebido também são fatores críticos e devem ser considerados.
Quando falamos em valor percebido, estamos nos referindo ao tempo necessário para atingir o que motivou a aquisição da tecnologia, como o custo de propriedade.
O tempo necessário para que a redução do custo de propriedade seja igual ou maior que o custo de migração é o período necessário para alcançar um ROI positivo.
Observações:
- Um custo de migração mais baixo é positivo, mas apenas se avaliado em relação ao custo de propriedade. Não faz sentido reduzir o custo de migração apenas para aumentar o custo de propriedade na mesma proporção, pois a propriedade é um custo contínuo, enquanto a migração é um custo único.
- Reduzir o custo de propriedade é vantajoso, mas se o custo da migração for muito alto, o tempo para atingir um ROI positivo pode ser inaceitavelmente longo para o negócio.
Relacionamento com o fornecedor
Ao escolher um fornecedor de SIEM, a capacidade do produto e o custo são fatores essenciais. No entanto, um aspecto frequentemente negligenciado é o tipo de relacionamento que sua empresa construirá com esse fornecedor.
Ao avaliar diferentes soluções de SIEM, verifique se o fornecedor possui uma metodologia para percepção de valor baseada nas necessidades da sua organização. Esse fator será fundamental para garantir um ROI positivo e maximizar o valor obtido com a solução.
Quando otimizar o SIEM em vez de migrar?
Nem toda organização precisa migrar de SIEM, desde que haja espaço suficiente para otimizações.
Por exemplo: se o SIEM atual atende 80%+ dos requisitos funcionais e de negócio, o custo de engenharia para otimização (p.ex.: tuning de regras, automação de triagem, eliminação de duplicatas) pode ser menor que o custo de mudança (TCC) de uma migração completa.
Se a taxa de falso positivo está acima de 40%, se o time gasta mais de 30% do tempo integrando novas fontes de dados, se alertas críticos levam horas para serem triados, há muito espaço para otimização em um SIEM moderno.
Se busca otimizar o uso do seu SIEM, fale conosco agora.
Como se preparar para a migração de SIEM
Uma migração de SIEM é um projeto estratégico. Mover operações de segurança de uma plataforma para outra, preservando dados históricos, casos de uso e capacidade de resposta a incidentes é uma tarefa complexa, mesmo quando todo o cenário foi avaliado.
Antes de comparar fabricantes e ferramentas de SIEM, a organização precisa definir o que é inegociável no novo SIEM e o que será apenas diferencial competitivo. Em projetos maduros, o erro mais comum é avaliar só custo e deixar em segundo plano pontos que realmente determinam o sucesso da migração: compatibilidade com a arquitetura atual, esforço de criar casos de uso, previsibilidade de custo, aderência regulatória e capacidade de operar sem blind spots durante a transição.
Por isso, a preparação deve funcionar como um pré-RFP enxuto: não para listar tudo o que um SIEM pode fazer, mas para estabelecer os critérios que sustentam a decisão por um novo fabricante.
A lógica mais útil é dividir a análise em cinco blocos: requisitos eliminatórios, aderência ao ambiente atual, capacidade de detecção, viabilidade da migração e modelo econômico de longo prazo.
1. Defina os critérios eliminatórios antes de falar com fabricantes
Alguns pontos não deveriam entrar em disputa comercial, porque a ausência deles já inviabiliza a solução. Aqui entram o modelo de implantação aceito pela empresa (SaaS, on-premises ou híbrido), requisitos de residência de dados, alta disponibilidade, disaster recovery, RBAC granular, criptografia, trilha de auditoria e aderência aos controles regulatórios que o ambiente exige. Se o fornecedor não atende esses itens nativamente ou com arquitetura validada, ele não deveria seguir para as próximas fases.
2. Mapeie o que precisa ser preservado do SIEM atual
A decisão por um novo fabricante não começa no catálogo do mercado, e sim no inventário do ambiente atual. É essencial levantar as fontes de dados críticas, os parsers customizados, as integrações com ferramentas de segurança, os dashboards usados pelo SOC, os relatórios de auditoria e, principalmente, os casos de uso que hoje sustentam a operação. Sem esse mapeamento, a troca de plataforma vira uma promessa abstrata, porque o fornecedor pode parecer forte na demo, mas fraco naquilo que realmente precisa ser migrado.
3. Avalie a profundidade de integração, não só a lista de conectores
Fabricantes costumam apresentar grande volume de integrações suportadas, mas o ponto decisivo é a qualidade da integração com as fontes que importam para o seu ambiente. Na análise, vale priorizar: conectores nativos homologados para as principais fontes atuais, flexibilidade para criar parsers de sistemas proprietários, suporte a APIs abertas, normalização consistente dos dados e capacidade de correlacionar eventos técnicos com dados de negócio. Esse ponto é especialmente relevante quando o SIEM precisa conversar com sistemas legados, ambientes híbridos e plataformas específicas do setor financeiro ou de prevenção a fraude.
4. Compare fabricantes pela capacidade real de detecção
O novo SIEM precisa provar que consegue detectar pelo menos tão bem quanto o legado ou melhor. A análise deve considerar qualidade do motor de correlação, suporte a regras abertas, cobertura por MITRE ATT&CK, integração com threat intelligence, recursos de threat hunting, UEBA e mecanismos de redução de falso positivo. Quando houver necessidade de unir cibersegurança e fraude, esse critério fica ainda mais importante: o fabricante deve demonstrar que consegue correlacionar comportamento de usuários, eventos de autenticação, telemetria de segurança e eventos transacionais em uma mesma lógica analítica.
5. Trate a migração de conteúdo como parte central da escolha
Em uma substituição de SIEM, o principal risco não está na instalação da plataforma, mas na migração da lógica de detecção. Regras, parsers, dashboards, alertas, enrichment e fluxos de investigação raramente são portáveis em modo lift-and-shift, e esse trabalho pode consumir uma parcela grande do cronograma. Por isso, a avaliação do fabricante deve incluir metodologia de migração, abordagem de priorização por tiers, plano para reescrita e validação dos casos de uso e suporte à operação paralela entre SIEM antigo e novo por 60 a 90 dias.
6. Modele custo com base no uso real, não na proposta comercial inicial
Na prática, muitos projetos erram menos na escolha técnica e mais na escolha financeira. O modelo de licenciamento precisa ser analisado junto com volume de ingestão, crescimento esperado, retenção, armazenamento frio, módulos adicionais, serviços profissionais, treinamento e custo operacional da administração contínua. A comparação entre fabricantes deve considerar TCO de três anos e simulações com o volume real do ambiente, porque modelos por consumo podem parecer baratos na entrada e se tornar caros depois, especialmente quando analytics, UEBA e automação entram em escala.
7. Exija prova prática em vez de resposta declaratória
A melhor forma de reduzir risco é exigir uma prova de conceito com critérios objetivos. O fabricante ideal não é o que diz que atende, mas o que consegue integrar fontes críticas, reproduzir casos de uso relevantes, manter desempenho em volume representativo, gerar relatórios úteis para compliance e mostrar experiência operacional da equipe na plataforma. Em vez de uma PoC genérica, vale definir previamente os cenários que importam para o seu SOC: fontes prioritárias, alertas críticos, consultas de hunting, casos de fraude e métricas mínimas de sucesso.
8. Considere maturidade do fabricante, não apenas do produto
A decisão também deve olhar para capacidade de entrega: referências no setor, presença local, SLA de suporte, professional services, treinamento, documentação e experiência prévia em projetos de migração semelhantes. Um SIEM tecnicamente forte pode fracassar no projeto se o fabricante ou parceiro não tiver método, suporte e time qualificado para conduzir a transição sem perda de cobertura operacional.
Migrando de SIEM com a DataRunk
Independentemente da forma como você calcula o custo da tecnologia, os seguintes princípios podem orientar sua tomada de decisão:
- Considere os custos do produto de forma holística, em vez de focar apenas no custo da licença.
● Avalie o impacto do custo da tecnologia no custo com pessoal.
● Aproveite o poder da consolidação para otimizar investimentos.
Como dissemos no começo, realizamos inúmeras migrações e implantações completas de SIEM ao longo dos anos.
Se você deseja conhecer mais sobre os SIEMs do mercado, fale conosco!
