Mas a facilidade da resposta não exclui o desafio. E não estou me referindo apenas à escolha de plataforma, de temas de treinamentos e da frequência das campanhas. 

Programas bem estruturados de conscientização não começam pelo conteúdo. Eles começam na conexão e alinhamento entre programa de conscientização com programa de segurança como um todo, com governança e indicadores claros. O programa não pode ser avulso, desconectado das políticas, riscos e objetivos organizacionais.

Dito isso, o centro da discussão passa a ser  como planejar o pilar de pessoas do programa de segurança para depois chegar à operacionalização. E é sobre isso que vamos falar aqui.

Estruturando um programa de conscientização em cibersegurança

Executivos, equipes financeiras, atendimento, tecnologia, operações e terceiros podem ser tratados da mesma forma em um programa de conscientização? Dificilmente.

Quem aprova pagamentos, por exemplo, pode estar sujeito a BEC, urgência artificial e validação. Quem opera credenciais privilegiadas precisa de reforço em MFA, higiene de senha, phishing direcionado e padrões de reporte. Quem trabalha em regime híbrido exige rotinas mais fortes de navegação segura, colaboração em nuvem e proteção de dispositivos.

Nós sabemos disso na prática em segurança, mas nem sempre levamos esse conhecimento para a estruturação do programa de conscientização. Então, pensando em termos de passos, temos que:

1. Diagnosticar o cenário atual

Respondemos a perguntas como:

• Quais os vetores que aparecem com mais frequência no ambiente?
• Quais os processos críticos sujeitos a ameaças com tais vetores que sofreriam o maior impacto?
• Quais áreas têm maior exposição ou concentram maior probabilidade de erro?
• Como está a cultura de reporte?
• Quais comportamentos precisam mudar primeiro porque expõem mais a organização? 

Sem esse baseline, o programa corre o risco de virar um calendário de ações sem relação clara com risco real.

2. Definir objetivos comportamentais, além de educacionais

“Capacitar usuários para adotarem comportamentos mais conscientes em segurança” é um objetivo legítimo para um programa voltado às pessoas, mas também amplo demais. 

Por isso, mais abaixo desse norte comum, os resultados objetivos do programa podem ser formulados como: 

• Reduzir a taxa de clique em simulações
• Aumentar o volume de reporte de mensagens suspeitas
• Diminuir a reincidência entre usuários de maior risco 
• Reduzir o tempo entre recebimento do e-mail suspeito e abertura do alerta para o SOC ou service desk.

3. Desenho do programa 

Definido o cenário as-is e os objetivos to-be, torna-se mais fácil descer para o estabelecimento do programa em termos práticos.

E aqui, cabe definir trilhas por perfil de risco, matriz de temas obrigatórios para toda a companhia, cadência de simulações, integração com políticas de segurança, normas e regulações.

Outro ponto: a literatura de mercado e os benchmarks de medição convergem para programas contínuos, com reforços frequentes, simulações recorrentes e medição de comportamento real, não apenas teste de conhecimento.

4. Estabelecer a governança e indicadores de sucesso

O programa de conscientização precisa ter dono, rito de acompanhamento e espaço formal na governança de riscos. Sem isso, o awareness tende a perder prioridade diante de outras agendas do programa.

Isso implica estabelecer indicadores regulares, revisar resultados e usar dados de simulações e incidentes para recalibrar campanhas, trilhas e mensagens.

Métricas como reporting rate, repeat offenders e tempo de reporte existem justamente porque awareness eficaz precisa aparecer no comportamento cotidiano.

Esse ciclo precisa ser contínuo, inclusive, para acompanhar o ambiente de ameaças. À medida que o padrão de ameaça muda, o programa também precisa mudar, atualizando exemplos, cenários, testes e critérios de risco comportamental.

Um bom modelo de gestão é trabalhar awareness como produto interno de segurança: com backlog, hipóteses, métricas, testes, iteração e accountability. Isso ajuda a romper com o formato tradicional de campanha sazonal e aproxima o programa da linguagem que gestores de ciber já usam para gerir controles, exposição e efetividade operacional.

Temas que não podem faltar em um programa de conscientização

Os tópicos centrais já conhecidos são críticos porque correspondem aos vetores com maior recorrência. Phishing, spear phishing, engenharia social, roubo de credenciais, senhas, MFA, uso seguro de e-mail, navegação, classificação da informação, trabalho remoto e reporte de incidentes seguem entre os blocos fundamentais de qualquer trilha séria.

O programa também pode contemplar normas (como ISO e outras), políticas internas e regulações (LGPD, CVM, BCB etc.) seguidas pela organização.

Ainda assim, o melhor programa não organiza conteúdo apenas por “tema de segurança”, mas por situação de decisão.

Moldar o conteúdo para que o colaborador visualize a situação no dia a dia, reconheça a ameaça e saiba precisa saber o que fazer quando recebe um pedido urgente de pagamento, quando um login parece legítimo demais, quando uma ferramenta de IA pede dados internos ou quando um colega solicita acesso por um canal incomum. 

Como justificar o programa para a alta gestão

A melhor forma de justificar o investimento em um programa de conscientização é conectar a importância do comportamento humano à importância de ferramentas e processos do programa de cibersegurança – o que, aliás, pode ter um custo substancialmente menor. 

O discurso executivo mais convincente é o que mostra que tecnologia pode fazer muito, mas sozinha não neutraliza pedidos fraudulentos, abuso de confiança, urgência socialmente construída e uso indevido de identidade. 

Nesses cenários, a pessoa treinada não substitui o controle técnico, mas aumenta a chance de que o controle seja acionado a tempo. É por isso que programas de conscientização bem estruturados precisam ser tratados como componente estratégico da postura de defesa, não como ação acessória de comunicação interna.

Treinamento de segurança em que seu time realmente joga junto

Para colocar um programa de conscientização contínuo, segmentado e focado em comportamento de pé, adotar uma plataforma para sustentar a iniciativa é essencial para ter agilidade.

A DataRunk é usuária e parceira da Hacker Ranger, uma plataforma desenhada para programas com esse foco. Você pode criar suas temporadas com trilhas de treinamento de acordo com seus objetivos e riscos para cada equipe. 

Para isso, o acervo tem:

• 300+ cursos em nanolearning, todos narrados e legendados
• 450+ quizzes para validar e fixar o aprendizado
• 260+ template de phishing para treinar na tomar de decisão.

Para mensurar a qualidade do programa e evidências de auditoria, você pode monitorar 23 KPIs. Ao usar a plataforma, a empresa entra automaticamente no programa de certificação Hacker Ranger, que chancela seus resultados por meio de certificados.

Se você quer transformar risco humano em defesa humana, conheça mais sobre o Hacker Ranger!

O post Como estruturar um programa de conscientização em cibersegurança que reduza risco humano apareceu primeiro em DataRunk.

Sem perder a sua centralidade, o SIEM já aparece funcionando junto com outras soluções, como SOAR – security orchestration, automation and response, UEBA – user entity and behavior analytics e TIPs – threat intelligence platforms.

Como então escolher um SIEM? Que recursos e funcionalidades todo SIEM deve ter? O que você deve considerar sobre o seu ambiente ao levar esse recurso para a organização?

Neste artigo, você encontra as respostas do Gartner para essas perguntas, complementadas por aprendizados nossos em projetos de engenharia de detecção, SOC e CFC.

Definição de mercado para o SIEM

O Gartner define o SIEM como um sistema configurável que agrega e analisa dados de ambientes on‑premise e cloud para identificar, investigar, apoiar respostas e relatar eventos de segurança. Ele é o centro nervoso de um SOC, conectando diversas fontes de logs, eventos e sinais de risco.

Em projetos com clientes de médio e grande porte, vemos o SIEM assumir três papéis principais: 

→ Concentrar e normalizar dados de segurança

→ Habilitar detecções e investigações mais rápidas 

→ Fornecer evidências para auditorias e requisitos regulatórios.

O Gartner aponta um conjunto de funcionalidades mínimas que qualquer SIEM sério precisa oferecer. Elas servem como um checklist inicial na avaliação de fornecedores.

Funcionalidades obrigatórias

Todo SIEM deve ser capaz de:

• Coletar dados relevantes em segurança a partir de ativos localizados on‑premise e/ou cloud.
• Permitir que os usuários desenvolvam, modifiquem e mantenham seus próprios casos de uso de detecção, com base em métodos de correlação, análise e assinaturas customizados.
• Fornecer conteúdo para customizações, cobrindo áreas como análise, normalização de dados, coleta e enriquecimento.
• Disponibilizar gerenciamento de casos e suporte para atividades de resposta a incidentes.
• Gerar relatórios para atender necessidades de negócios, compliance e auditorias.

Funcionalidades standard de um SIEM moderno

Além do mínimo, o Gartner descreve um conjunto de capacidades que hoje são consideradas padrão em SIEMs líderes:

• Armazenamento de dados sobre eventos de segurança, com disponibilidade para pesquisa posterior.
• Coleta de dados de eventos provenientes de fontes diversas, utilizando múltiplos mecanismos (fluxo de logs, API, processamento de arquivos) para casos de uso de detecção de ameaças, relatórios e investigações de incidentes.
• Múltiplas opções de implantação, incluindo on‑premise, cloud, cloud‑native ou SaaS.
• Normalização, enriquecimento e pontuação de risco de dados provenientes de sistemas de terceiros.
• Orquestração e automação de tarefas e workflows de investigação para mitigar o impacto de incidentes.
• SOAR integrado ou nativamente disponível.
• Funcionalidades de análise avançadas, com UEBA e machine learning.
• TIP (Threat Intelligence Platform), para fornecer informações contextuais sobre ameaças.

Funcionalidades optativas de um SIEM

Dependendo da maturidade da operação e do orçamento, alguns recursos opcionais tornam‑se diferenciais na decisão:

• Integração com outras tecnologias por meio de app stores, marketplaces e integrações prontas.
• Federated search.
• Busca e consulta de eventos para além do repositório de dados do SIEM, visando ao enriquecimento de informações de eventos.
• Tecnologias complementares, como detecção e resposta em endpoints (EDR) e detecção e resposta em rede (NDR).
• Integração com plataformas de data lake.

Tendências e mudanças no mercado de SIEM

O Gartner observa algumas tendências importantes na evolução do mercado de SIEM:

• SIEM as a service.
• Compatibilidade com APIs de acesso a dados.
• Soluções centradas nas principais necessidades de coleta de logs e no processo, detecção e resposta tradicionalmente realizadas por um SIEM, que, apesar de menos flexíveis, atraem operações menos maduras.
• Automação e orquestração cada vez mais presentes no core do produto.

Do lado da prática, temos visto empresas migrarem de implantações on‑premise complexas para modelos cloud‑native e SaaS, justamente para reduzir esforço de manutenção, acelerar o time‑to‑value e explorar melhor automações embarcadas.

Checklist de funcionalidades críticas em um SIEM (para diferentes cenários)

A seguir, organizamos os pontos que o Gartner destaca como críticos em um SIEM em formato de checklist prático.

1. Arquitetura e implantação

• O SIEM deve se adequar a ambientes on‑premise, cloud‑native ou hospedagem em cloud, integrando‑se a outros serviços para coletar e monitorar dados.
• Em operações menos maduras, arquiteturas cloud‑native ou SaaS com conteúdo pronto tendem a reduzir complexidade e custo de implantação.
• Em operações com SOC estruturado, vale priorizar flexibilidade de arquitetura, integrações avançadas e controle de custos de ingestão.

2. Coleta de dados em escala

• Capacidade e facilidade de gerenciar logs, chamadas de API e outros dados, independentemente do volume e da fonte, com velocidade.
• Conectores prontos para principais clouds, sistemas críticos de negócio e ferramentas de segurança já existentes.
• Mecanismos de normalização consistentes para evitar “lixo estruturado” e facilitar correlações.

3. Add‑ons e extensão da plataforma

• Disponibilidade de soluções complementares e integradas no mesmo fornecedor de SIEM, incluindo SOAR, TIP, UEBA, XDR, entre outros.
• Avaliação do que faz sentido agora e do que pode ser ativado gradualmente, conforme a equipe amadurece.

4. Conteúdo pronto e frameworks

• Presença de ferramentas de interesse geral já disponíveis no SIEM para detectar, priorizar e reportar anomalias comuns (playbooks, frameworks, dashboards e correlações preconstruídas).
• Alinhamento do conteúdo com padrões e frameworks relevantes ao seu setor (por exemplo, MITRE ATT&CK, PCI‑DSS e LGPD).

5. Compatibilidade e gestão de conteúdo

• Conjunto robusto de recursos para gerenciar o conteúdo disponível: conectores, integrações, parsers, regras e playbooks.
• Facilidade para versionar, testar e promover conteúdo de detecção entre ambientes (dev, homologação e produção).

6. Integrações

• Capacidade de trabalhar bidirecionalmente com outras plataformas, focadas ou não em segurança (ITSM, ferramentas de observabilidade, soluções de identidade, etc.).
• API bem documentada para integrações customizadas.

7. Roadmap do produto

• Roadmap claro para evolução do SIEM, considerando mudanças na superfície de ataque e novas demandas de compliance.
• Frequência e qualidade de releases, bem como histórico de execução do roadmap pelo fornecedor.

8. Interface do usuário

• Interface adaptável a diferentes perfis de usuário, do analista júnior ao engenheiro de ameaças.
• Facilidade de uso na criação de queries, dashboards, playbooks e investigações.

9. Funcionalidades prontas para uso

• Conteúdo out‑of‑the‑box relevante para monitorias comuns de segurança e requisitos de compliance.
• Importante sobretudo em operações menos maduras, que não têm equipe para construir tudo do zero.

10. Customização avançada

• Capacidade de configurar a plataforma SIEM para atender diferentes requisitos de segurança, com base em uma compreensão sólida da superfície de exposição a riscos da organização.
• Impacto direto sobre geração de alertas, análises, relatórios e dashboards customizados.

11. Detecção, investigação e resposta

• Recursos de detecção, investigação e resposta integrados, permitindo que o SIEM seja de fato o centro da operação de segurança.
• Integração fluida com processos de incident response internos ou serviços gerenciados.

Em nossos projetos, é comum vermos organizações que compram um SIEM tecnicamente robusto, mas têm dificuldade para extrair valor porque não alinharam esses critérios à própria realidade de ambiente, equipe e orçamento.

Quando buscar um SIEM (e qual modelo faz sentido)

Sendo o core de um SOC, o SIEM pode estar presente em operações com variados níveis de maturidade e tamanho, mas isso muda bastante as funcionalidades requeridas. A variação de SIEMs disponíveis no mercado é grande, com plataformas cloud‑nativas universalizadas e menor complexidade de implementação, além de opções mais customizáveis para operações maduras.

Sinais de que você já deveria ter um SIEM

Considere priorizar a adoção de um SIEM quando:

• Já não consegue investigar alertas de segurança apenas com as ferramentas nativas de cada sistema ou cloud.
• Precisa comprovar aderência a normas ou frameworks (como ISO 27001, LGPD e PCI‑DSS) com relatórios consistentes de logs e incidentes.
• Tem incidentes recorrentes que demoram a ser detectados ou são descobertos por terceiros (fornecedores, clientes ou reguladores).

De acordo com a análise do Gartner, os CISOs devem determinar e documentar com precisão o escopo e os casos de uso em que pretendem aplicar um SIEM antes de ir ao mercado. Fatores como infraestrutura, necessidades de compliance e auditorias influenciam diretamente na arquitetura da solução, bem como nos recursos requeridos.

SIEM próprio, SIEM gerenciado ou híbrido?

• Operações menos maduras tendem a se beneficiar de SIEM as a service, com conteúdo pronto, automações preconstruídas e suporte especializado.
• Operações com SOC consolidado muitas vezes combinam SIEM com SOAR, UEBA e XDR para ter mais controle sobre casos de uso avançados e integração com outras ferramentas.

Além disso, o SIEM não é um plug‑and‑play: para alcançar o valor máximo do investimento, a melhoria contínua da operação é fundamental, tanto para os casos de uso previstos quanto para a adoção de novos recursos e tecnologias complementares.

Magic Quadrant for SIEM 2025

No Magic Quadrant for Security Information and Event Management 2024, o Gartner posiciona alguns fornecedores como líderes globais de SIEM. Entre eles, destacam‑se Splunk e Microsoft, seguidos por Google, Securonix, Exbeam e Gurucul.

Para muitas organizações, esses players aparecem como referência de capacidade técnica e visão de futuro, mas a escolha final deve considerar aderência ao contexto local, modelo de licenciamento, ecossistema de parceiros e disponibilidade de especialistas para implementação e operação.

SIEM: o centro da sua operação de segurança

Neste artigo, você viu o que se pode esperar de um SIEM e, mais do que isso, o que deve considerar ao buscar um para estruturar o SOC e a estratégia de segurança da informação da organização, com base nas recomendações do Gartner. Também exploramos critérios práticos para avaliar funcionalidades críticas, encaixar o SIEM no seu cenário de maturidade e entender quando faz sentido optar por modelos as a service ou arquiteturas mais customizáveis.

Ainda assim, apoio especializado pode fazer a diferença, sobretudo em operações críticas. Nisso, a DataRunk pode ajudar você: atuamos no mapeamento do ambiente, definição de casos de uso, identificação de tecnologias, dimensionamento e implantação do SIEM, além de treinamento da sua equipe e suporte à evolução contínua do SOC.

Fale conosco

 para estruturar ou evoluir o seu SOC com uma abordagem alinhada ao Gartner e à realidade da sua operação.

O post Como escolher um SIEM, de acordo com o Gartner apareceu primeiro em DataRunk.

Mas nosso interesse aqui não é estritamente o que precisa ser feito, pois o regulador já estabeleceu a régua mínima de higiene cibernética. A pergunta é: como vamos fazer para nos adequar, monitorando APIs, risco de fornecedores, insiders para saber que o que a instituição está transacionando neste momento é o mesmo que o Banco Central está reconhecendo?

O conceito técnico que vem respondendo mais rapidamente a essa pergunta, na nossa experiência prática com clientes do setor, é: Cyber Fusion Center (CFC).

O CFC extrapola o conceito tradicional de SOC para incluir monitoramento do negócio, usando a inteligência em cibersegurança para a proteção antifraude em uma única arquitetura operacional.

Neste artigo, vou esclarecer melhor o que nós chamamos de CFC, por que ele tem sido a estrutura ideal para postura de defesa no setor financeiro e, não exaustivamente, como uma instituição financeira pode caminhar para esse modelo.

O que é um Cyber Fusion Center 

O CFC vai além de um SOC, mas não se desfazendo de sua estrutura, e sim aproveitando a estrutura dele para chegar no monitoramento do negócio. 

Um cyber fusion center é um modelo de operação que integra dados, detecções e operações de segurança a monitoramento de comportamento, hunting e threat intelligence com viés de antifraude, riscos de terceiros e gestão de crises em um único fluxo de trabalho.

Na definição usada por consultorias globais, o CFC atua como um hub de defesa proativo que consolida telemetria interna, inteligência externa e sinais de fraude para orientar decisões em tempo quase real. 

Como nasceu o conceito de CFC e quem está puxando a agenda

O conceito de cyber fusion center veio de uma necessidade das áreas de cibersegurança, chamadas a dar respostas às áreas de negócio sobre incidentes cibernéticos que redundaram em fraudes vultosas. Embora não seja exclusividade do setor financeiro, este setor é exemplar desse tipo de incidente.

O CFC vem para resolver o problema dos silos entre times que olham para os mesmos dados por ângulos diferentes. 

Nos últimos anos, o CFC foi a resposta natural à convergência entre cyber, fraude e risco operacional nas instituições financeiras. 

Segundo estimativa citada por analista, hoje cerca de 5% das grandes organizações mantêm centros de fusão cyber‑fraude, com previsão de chegar a 20% até 2028, mostrando que o modelo está saindo do nicho visionário para se tornar mainstream em empresas de maior porte.

Por que o setor financeiro se beneficia de um CFC 

Após as atualizações regulatórias, os participantes precisaram passar por uma adequação profunda em sua arquitetura de segurança.

As áreas de cibersegurança das instituições do setor financeiro têm necessidade de monitorar dados de negócio para detectar atividades suspeitas e anomalias dentro de seus fluxos transacionais, isto é, no fluxo da comunicação com o sistema financeiro, da iniciação de um pagamento dentro de um canal até a liquidação. 

Para isso, o setor precisa reconhecer a estrutura, fazer o desenho da arquitetura tecnológica e de todos os processos que rodam em cima dela do ponto de vista de segurança, para apontar quais são as vulnerabilidades e melhorias para a defesa adequada.

O gargalo está na capacidade de conectar, em minutos, sinais dispersos (logs, alertas, padrões anômalos, reclamações de clientes, tentativas de fraude) e transformá‑los em uma decisão clara: bloquear, mitigar, comunicar, escalar.

O CFC foi desenhado para facilitar essa conexão dos sinais a decisões. Ele se posiciona como uma camada de orquestração acima (e junto) do SOC, com governança explícita de quem decide o quê, com base em quais sinais, e em que condições. O objetivo é agir rapidamente, mitigando riscos ao negócio.

Cyber Fusion Center e SOC comparados

De forma simplificada, o SOC é um centro de detecção, investigação e resposta a alertas cibernéticos; o CFC também, mas conectando detecção de anomalias a fraudes. 

A tabela abaixo resume as diferenças relevantes para uma instituição financeira:

Na prática, o CFC reorganiza o trabalho em torno de problemas de negócio. Em um ataque de account takeover em larga escala, por exemplo, ele acompanha desde os primeiros indicadores de campanha (intel, IOC, padrões anômalos) até o ajuste de políticas de canal, a calibragem de motores de fraude, a comunicação a clientes e o reporte regulatório, tudo dentro do mesmo modelo de decisão.

Elementos essenciais de um Cyber Fusion Center maduro

1. Governança e modelo operacional

Um CFC maduro começa com relação com comitês de governança, risco e compliance, comitê de crise e áreas antifraude. Nele, ficam explícitos os serviços que o centro entrega (por exemplo: gestão de incidentes críticos, coordenação de resposta a fraudes) e como se medem esses serviços.

Papéis e responsabilidades também são redesenhados: CISO, donos de jornada de negócio, limites de risco operacional, jurídico, comunicação e, muitas vezes, áreas de produtos participam da governança. Essa estrutura permite alinhar rapidamente decisões sobre risco, experiência de cliente e impacto operacional durante um incidente.

2. Telemetria, inteligência e automação

Sem telemetria, não há SOC, nem CFC. No setor financeiro, isso significa integrar dados de canais digitais, core bancário, motores de fraude, IAM, infraestrutura de nuvem e terceiros críticos em um modelo onde o contexto de negócio é construído a partir de eventos técnicos.

A partir daí, SIEM, EDR, UEBA e ferramentas de fraude passam a operar de forma integrada, com automação (SOAR) executando tarefas repetitivas: enriquecimento de IOC, bloqueio temporário de contas, ajustes em regras de detecção, abertura de casos unificados para múltiplos times. A automação não substitui o analista; ela libera capacidade para tratar os 10–20% de casos que realmente exigem julgamento humano e coordenação interárea.

3. Convergência com fraude 

Em bancos e fintechs, a fronteira entre cyber e fraude digital já é apenas artificial. Engenharia social para cooptação, comprometimento de credenciais e abuso de APIs geralmente terminam em perdas financeiras diretas e indiretas.

O CFC endereça essa convergência trazendo as áreas de antifraude para o centro do modelo, como donas de fluxos e decisões. Isso inclui desde o desenho conjunto de regras em motores transacionais até war rooms híbridos em incidentes que combinam ataque, fraude e vazamento de dados, com visão única de perdas reais e evitadas.

Caminho de implantação: da visão ao runbook

Muitas instituições financeiras já investiram pesado em seus SOCs – com plataformas avançadas de SIEM e EDR, SOAR etc. Esse stack tecnológico é capaz de suportar a monitoria do negócio, quando bem aproveitado. 

Embora aproveite a estrutura instalada do SOC, o CFC representa uma mudança profunda do ponto de vista organizacional, ampliando suas funções, responsabilidades e prioridades. 

Fase 1: fundamentação 

O primeiro passo é mapear jornadas críticas (PIX, cartões, mobile banking, open finance), principais cenários de fraude/ataque e obrigações regulatórias mais sensíveis.

Depois, consolidar o entendimento sobre a cobertura do SOC atual dos fluxos críticos de negócio mapeados: o que ele já entrega bem e onde estão os gaps de monitoria.

A partir disso podem ser enquadrados os problemas de negócio que o CFC precisa resolver.

Em paralelo, define‑se o modelo operacional: in‑house, cogerenciado ou outsourced com parceiros especializados, considerando maturidade interna, disponibilidade de talentos e exigência de cobertura 24×7. 

Fase 2: construção

Com o problema bem definido, a construção começa pela priorização de poucos casos de uso de alto impacto. Por exemplo, anomalias em comportamentos de usuários, monitoramento de consultas ao DICT, atipicidades em certificados digitais. 

Para cada caso, desenham‑se e validam-se as monitorias, onboarding de dados, playbooks integrados, com critérios claros de escalonamento e de tomada de decisão.

Também é o momento de estruturar rituais: war rooms para incidentes de alta criticidade, reports executivos periódicos, sessões de lições aprendidas com foco em mudanças estruturais (processos, produtos, parceiros). 

Mesmo antes de o CFC estar “100% pronto”, esses ritos já começam a criar o comportamento de fusão entre times.

Fase 3: escala e automação 

Com os primeiros fluxos rodando, o foco passa a ser ampliação de cobertura e eficiência. Aqui entram a expansão de fontes de dados e a automação de tarefas de baixo risco e alto volume: correlação inicial, enriquecimento, bloqueios temporários e notificações internas.

Ao mesmo tempo, refinam‑se indicadores orientados a negócio: tempo para mitigar incidentes relevantes, perdas evitadas em fraudes associadas a ataques, impacto em NPS ou em disponibilidade de jornadas críticas, aderência a SLAs regulatórios. Esses números alimentam o business case contínuo do CFC e ajudam a calibrar investimentos futuros.

Métricas que importam para provar o valor de um CFC

As instituições que avançam mais rápido tendem a conectar indicadores de segurança a métricas financeiras e de negócio, como:

• Redução de perdas por fraude vinculadas a incidentes de cyber ou campanhas específicas.
• Tempo para identificar e mitigar violações que afetem dados sensíveis de clientes ou serviços críticos.
• Redução de falsos positivos e de esforço operacional sem perda de cobertura.

Estudos da EY sobre liderança em cibersegurança mostram que organizações com abordagem integrada de segurança tendem a detectar e responder a incidentes mais rápido e a gerar valor financeiro tangível por iniciativa apoiada pela área de cyber.

Por onde começar: recomendações práticas para CISOs e líderes de segurança

Em muitos casos, faz sentido começar por um fusion team: um time núcleo que integra líderes de cyber, fraude, risco e compliance em jornadas específicas e evoluir para um CFC pleno à medida que a governança e a automação amadurecem.

O importante é que, qualquer que seja o nome, a arquitetura esteja presente: arquitetura do negócio compreendida do ponto de vista de segurança, vulnerabilidades identificadas, inteligência de detecção operando no dia a dia, playbooks estabelecidos, instância clara de coordenação em crises e métricas orientadas a negócio. 

Serviços gerenciados e parceiros podem apoiar parte da monitoração ou da inteligência, mas o comando estratégico do modelo de CFC precisa permanecer dentro da instituição.

CFC como alavanca estratégica, não só técnica

O movimento em direção a Cyber Fusion Centers como expansão do SOC tem sido o modelo mais rápido de adequação às novas necessidades de compliance e de segurança cibernética das instituições. 

Para estendermos essa conversa sobre conceitos para cases reais e para o seu cenários, agende uma conversa comigo.

O post Cyber Fusion Center (CFC): a transformação do SOC no setor financeiro apareceu primeiro em DataRunk.

O trabalho de resposta está essencialmente vinculado ao SOC. É esse time que se envolve diretamente na mitigação dos impactos, manutenção das operações e, em última instância, criação de mecanismos que impeçam que os atacantes alcancem seus objetivos finais. A qualidade e abrangência desse trabalho que visa a recuperação tem a ver com a resiliência cibernética de que tanto falamos.

No entanto, a resposta a um incidente não significa apenas a restauração do ambiente, mas acima de tudo com a recuperação da confiança. E esta não é tão simples assim. Uma organização dificilmente se recupera rápido de um grande ataque. 

Incidentes, dependendo a magnitude, deixam cicatrizes profundas: eles aumentam a pressão sobre o time, podem levar a desligamentos, afetam a confiança e os relacionamentos, levam a impactos financeiros e reputacionais profundos, e por aí vai. 

Como reconstruir a confiança?

Por que a confiança pode se perder rapidamente em cibersegurança

Quando falamos em confiança em cibersegurança, estamos falando de pontos bem concretos:

• A confiança do board e das lideranças de negócio de que o time de segurança sabe o que está fazendo para mitigar impactos.
• A confiança das equipes internas de que informações são compartilhadas de forma transparente, sem caça às bruxas.
• A confiança de clientes e parceiros de que a organização cuida seriamente de dados, responde rápido a incidentes e não esconde problemas.

Essa confiança se erode rapidamente quando:

• A comunicação é lenta, truncada ou contraditória.
• As decisões parecem buscar apenas a autodefesa (para proteger reputação) mais do que a legítima proteção de pessoas, dados e continuidade.
• Não há clareza sobre papéis, responsabilidades e plano de ação durante a crise.

Nós temos como evitar essa erosão – apesar de tudo. Vou detalhar abaixo.

Quatro pilares para construir e reconstruir confiança em incidentes

Inspirada em recomendações da Splunk, de organismos especializados e na prática prática com clientes do DataRunk SOC, organizei quatro pilares para manter e recuperar a confiança diante de incidentes de cibersegurança.

1. Construa confiança antes do incidente de cibersegurança (não no meio dele)

Antes do que se pode fazer após um incidente para restaurar a confiança, devemos pensar em como construi-la antes de que ele aconteça. Durante um incidente crítico, não é hora de convencer stakeholders de que o SOC sabe o que está fazendo. Essa confiança precisa existir antes. 

Comunicação, colaboração e entendimento, assim como na vida, estão na base do trabalho em conjunto e, consequentemente, da confiança. Para as equipes de cibersegurança, isso significa se conectar com outras áreas e partes interessadas. TI, jurídico, comunicação, RH e fornecedores terceirizados podem ser fortes aliados.  

Algumas ações concretas:

• Rodar exercícios de simulação (tabletop) com frequência
  Simulações de cenário – por exemplo, ransomware em ambiente crítico ou vazamento de dados sensíveis – ajudam times a testar plano de resposta, comunicação e tomada de decisão sob pressão. Organizações que rodam pelo menos dois tabletop exercises por ano tendem a conter incidentes mais rápido, reduzir probabilidade de pagamento de resgate e ter melhor desempenho em auditorias.
• Envolver áreas de negócio, jurídico, comunicação e RH nas simulações
  Incidente não é assunto só de TI. Exercícios mais maduros envolvem líderes de negócio, jurídico, comunicação, finanças e RH, tornando o diálogo em crise mais fluido e reduzindo atritos.
• Definir papéis e canais de comunicação antes do incidente
  Quem fala com o board? Quem fala com imprensa? Quem fala com clientes chave? Qual canal oficial será usado internamente? Ter isso definido e testado em simulações reduz ruído e evita disputa de narrativa.

Como vemos na DataRunk
Em clientes nos quais atuamos, vemos uma diferença clara quando a organização já passou por pelo menos um ciclo de tabletop: o time sabe onde buscar informação, quais painéis olhar, quem precisa estar na sala e quais decisões são críticas nas primeiras horas. Isso transmite confiança imediata para a liderança – mesmo quando a resposta ao incidente ainda está em evolução.

2. Compartilhe informações durante um incidente em cibersegurança, mas não perca o controle da narrativa 

Ninguém gosta de ficar no escuro diante de uma crise. Quando os responsáveis por lidar com uma crise a assumem e informam adequadamente quem é ou pode ser afetado por ela, eles demonstram um compromisso com as partes interessadas, o que é determinante para a confiança.

Ainda assim, é preciso ter cuidado com o que se informa, para não perder o controle. Ter já mapeado um plano de comunicação, quando um incidente ocorre, vai ser fundamental para reduzir a incerteza e alinhar as expectativas, mesmo que nem todas as informações possam ser compartilhadas com todos os detalhes. 

Alguns princípios práticos:

• Comunique cedo, mesmo com informações incompletas
  Em vez de esperar a foto perfeita (que nunca vai existir), deixe claro o que se sabe, o que está em investigação e quando haverá atualização. Isso vale para comunicação interna e, quando for o caso, externa.
• Crie um boletim de incidente com cadência fixa
  Definir janelas claras de atualização (por exemplo, a cada 2 horas no início, depois a cada 4 ou 8 horas) ajuda a reduzir ansiedade, tanto do board quanto do time operacional.
• Use linguagem clara, sem jargão técnico desnecessário
  A liderança quer entender o que aconteceu, qual é o impacto, o que estamos fazendo agora e o que vamos fazer em seguida. Traduza termos técnicos para implicações de negócio – perda de receita, indisponibilidade de serviço, risco regulatório.
• Registre decisões e premissas
  Manter trilha de decisões críticas (por exemplo, desligar sistemas, notificar regulador, acionar seguro cibernético) e suas premissas ajuda a reconstruir a narrativa depois e mostra que o time não estava “atuando no escuro”.

Como vemos na DataRunk 
Centralizar telemetria, evidências e contexto de incidentes em um só lugar facilita não só a resposta técnica, mas também a reconstrução da história do incidente para lideranças. Quando dados de detecção, investigação e resposta estão consolidados, a tradução para status executivos fica mais rápida e menos dependente de heróis individuais.

3. Supere a relutância em colaborar

Eventos de segurança raramente acontecem de forma isolada. A maioria atravessa múltiplas equipes – segurança, infraestrutura, desenvolvimento, operação, atendimento, jurídico. Quando esses grupos não confiam uns nos outros ou não compartilham informações, o incidente se alonga, o estresse aumenta e a confiança geral despenca.

O instinto muitas vezes é tirar o seu da reta tanto quanto possível e não colaborar. Porém, todo setor de cibersegurança sabe que a retenção de informações pode tornar a situação ainda mais difícil de gerenciar.

Tratar esse instinto de não colaboração antecipadamente, estabelecendo mecanismos claros como NDAs, contratos e políticas, permitindo que as equipes compartilhem informações com confiança quando necessário. 

Boas práticas para alinhar times:

• Criar um war room claro (físico ou virtual)
  Em incidentes críticos, estabeleça um canal único de coordenação: uma sala de crise com responsáveis claros, agenda de atualização e espaço para decisões.
• Definir RACI de incidentes
  Ter um modelo de quem é responsável, quem aprova, quem precisa ser consultado e quem só é informado em cada tipo de incidente evita disputas e acelera decisões.
• Fomentar cultura de “problema do time, não da pessoa”
  Em organizações maduras, a pergunta não é quem errou, mas quais condições permitiram que isso acontecesse? Essa mudança de postura reduz medo, incentiva transparência e aumenta o fluxo de informação útil.
• Normalizar reporte de quase-incidentes
  Incentivar a comunicação de quase-incidentes e tratá-los como oportunidade de aprendizado ajuda a identificar fragilidades antes que virem crises reais. Isso exige confiança de que o reporte não será usado contra a pessoa.

Na prática com clientes DataRunk
Times que usam uma visão unificada de dados de segurança – em vez de cada ferramenta “falando por si” – conseguem debater fatos, e não opiniões. Isso reduz disputas entre áreas (“não é problema meu”, “não tenho evidência disso”) e aumenta a confiança nos encaminhamentos.

4. Reconheça o fator humano – Layer 8

Incidentes não são apenas eventos técnicos; são eventos humanos. Podem causar culpa, exaustão, burnout e até pedidos de desligamento, cobrando um alto preço das equipes. Ignorar esse fator é uma forma rápida de destruir confiança. O bem-estar das pessoas deve ser, mais do que considerado, ativamente gerenciado.  

Quando a recuperação leva semanas, meses ou até anos, apoiar o bem-estar da equipe ajuda a manter a resiliência e o sucesso a longo prazo.

Pontos de atenção:

• Gerir carga de trabalho e plantões durante o incidente
  Crises longas exigem turnos, descanso mínimo e substituições planejadas. Time exausto erra mais, comunica pior e se fecha para colaboração.
• Evitar culpabilização pública
  Expor publicamente “o analista que clicou” ou “a equipe que não aplicou o patch” é uma das maneiras mais eficientes de matar a confiança futura. O foco deve ser sistêmico: por que o processo permitiu que isso acontecesse?
• Promover debrief estruturado (post-incident review)
  Depois do incidente, faça uma revisão com foco em aprendizado – o que funcionou bem, o que não funcionou, quais melhorias serão implementadas, com responsáveis e prazos.
• Cuidar do bem‑estar da equipe
  Em incidentes graves, é razoável oferecer apoio psicológico, folgas compensatórias ou revezamento temporário de funções. Isso sinaliza que a organização valoriza as pessoas, não só os sistemas.

Como isso aparece na nossa experiência
Vemos que times com cultura de aprendizado e cuidado com as pessoas estão mais dispostos a relatar problemas cedo, compartilhar dúvidas e assumir responsabilidades – exatamente o tipo de comportamento que constrói confiança.

Confiança em incidentes de cibersegurança: um trabalho contínuo

A confiança deve ser construída antes dos incidentes em cibersegurança e, com a postura adequada, mantida durante eles. 

Comunicar-se, ter a colaboração e dar segurança para os envolvidos durante um incidente é fundamental para preservá-la. 

Se incidentes acontecem em torno de 47 vezes por ano, semanalmente a confiança vai ser posta à prova. 

Construa desde o primeiro dia. 

O post Como reconstruir a confiança quando incidentes em cibersegurança acontecem apareceu primeiro em DataRunk.

Na prática, as empresas usam Splunk para reforçar segurança (SIEM e SOAR), ganhar visibilidade de ponta a ponta e reduzir o tempo entre uma anomalia técnica e o impacto real no negócio.

Na DataRunk, vemos Splunk gerar mais retorno em ambientes complexos: múltiplas nuvens, aplicações críticas de alto volume, requisitos rígidos de compliance e times pressionados por incidentes recorrentes e auditorias constantes.

O que é Splunk?

Splunk é uma plataforma que transforma dados de máquina, ou seja, tudo o que servidores, aplicações, containers, firewalls e serviços em nuvem registram, em informação acionável para segurança, observabilidade e continuidade de negócios.

Em vez de cada sistema ter seu próprio log isolado, Splunk centraliza tudo, organiza em índices e permite buscas, dashboards, alertas e automações em cima desses dados, em tempo quase real.

Do ponto de vista técnico, Splunk combina capacidade de ingestão de dados em grande volume, mecanismo de busca avançado (SPL – Search Processing Language) e um conjunto de apps e integrações para diferentes casos de uso, como SIEM, SOAR e observabilidade de aplicações.

Para que serve o Splunk na prática no dia a dia?

Splunk foi desenhado para responder três perguntas essenciais do time de TI e segurança: o que está acontecendo agora, o que pode dar errado no futuro e quanto isso ameaça o negócio.

Ele faz isso centralizando dados de diferentes fontes, correlacionando eventos, destacando anomalias e disparando alertas e playbooks de resposta quando algo foge do padrão.

Os usos mais comuns do Splunk em 2026 são:

• Detecção e resposta a incidentes de segurança (SIEM + SOAR)
• Monitoramento de aplicações e infraestrutura (observabilidade full-stack)
• Análise de desempenho e disponibilidade de serviços digitais
• Atendimento a requisitos de compliance e auditoria (logs e trilhas de auditoria centralizados)
• Investigação de problemas complexos que cruzam várias camadas (rede, app, banco, nuvem, identidade)

Quais problemas Splunk resolve em segurança (SIEM e SOAR)?

Em segurança, Splunk atua como um SIEM moderno que coleta eventos de firewalls, IDS/IPS, EDR, proxies, identidade, nuvem e aplicações, correlacionando sinais para destacar ameaças relevantes em meio a milhares de alertas diários – e costumar ser o centro do SOC e BSOC/CFC.

Com Splunk SOAR, é possível automatizar partes da resposta a incidentes — como enriquecer indicadores, bloquear IPs, isolar máquinas e atualizar tickets — liberando o time de SOC para investigar o que realmente importa.

Na DataRunk, vemos impacto maior quando Splunk é usado para:

• Unificar alertas de várias ferramentas legadas em um único painel de priorização
• Padronizar playbooks de resposta a incidentes (por tipo de ataque ou criticidade)
• Reduzir o tempo entre detecção e ação (MTTR) em ambientes com muito ruído e alertas falsos positivos.

Na maioria dos projetos, Splunk pode substituir ou consolidar SIEMs legados, sobretudo quando há necessidade de maior flexibilidade de correlação, automação com SOAR e integração com fontes modernas de dados (nuvem, containers, identidades).

Como o Splunk ajuda na observabilidade e confiabilidade de aplicações?

Segurança é uma área forte para este fabricante, mas a Splunk hoje se posiciona como plataforma de resiliência digital, conectando segurança, observabilidade e análise operacional em cima do mesmo conjunto de dados.

Na parte de observabilidade, Splunk conecta logs, métricas e traces em uma visão única, permitindo que times de desenvolvimento e operações enxerguem rapidamente onde está o gargalo ou a causa raiz de um problema.

Isso vale tanto para ambientes tradicionais quanto para arquiteturas modernas baseadas em microserviços, Kubernetes e multicloud.

Com as soluções de observabilidade da Splunk, empresas conseguem:

• Monitorar SLAs e SLOs críticos com alertas baseados em impacto real no usuário
• Identificar regressões de performance após deploys
• Cruzar dados de infraestrutura, aplicação e experiência do usuário em um único painel

Nos projetos da DataRunk, isso costuma se traduzir em menos incidentes em horário de pico, redução de apagões em aplicações de faturamento e menor esforço de salas de guerra entre times de desenvolvimento, infraestrutura e segurança.

Quais são os principais produtos da Splunk e para que serve cada um?

A Splunk organiza seu portfólio em torno de uma plataforma central e módulos específicos para segurança e observabilidade.

Na DataRunk, normalmente vemos: Splunk Platform como base de dados de observabilidade e segurança, módulos de Security quando o foco é SOC e compliance, e observability cloud quando o desafio principal é performance de aplicações críticas.

Como funciona a arquitetura do Splunk (Forwarder, Indexer e Search Head)?

Em um cenário típico, o Splunk funciona como um pipeline de dados: agentes e integrações coletam logs e métricas, esses dados são enviados para componentes que armazenam e indexam, e interfaces de busca e dashboards permitem explorar e automatizar ações.

De forma simplificada:

• Forwarder: componente responsável por coletar e enviar dados das fontes (servidores, apps, appliances de segurança) para o Splunk.
• Indexer: recebe os dados, indexa e armazena de forma otimizada para busca e correlação.
• Search Head: camada de interface onde usuários criam buscas, dashboards, relatórios e alertas.

Essa arquitetura permite escalar o ambiente Splunk conforme o volume de dados cresce, mantendo desempenho de busca e retenção de logs para compliance.

O Splunk é para qualquer empresa ou só para grandes corporações?

Splunk pode ser usado por empresas de vários portes, mas ele tende a gerar mais retorno em organizações que já sentem dor real com incidentes, auditorias e ambientes distribuídos.

Se o seu time ainda consegue acompanhar tudo em poucos servidores e ferramentas simples de log, o investimento em Splunk talvez seja prematuro; se você vive em crises e planilhas paralelas, provavelmente já passou da hora.

Na experiência da DataRunk:

• Empresas médias: costumam começar com 1–3 casos de uso bem definidos (por exemplo, monitorar uma aplicação de faturamento ou centralizar logs de segurança para uma auditoria específica).
• Empresas grandes: geralmente usam Splunk para substituir SIEMs legados, consolidar observabilidade multicloud e reduzir o número de ferramentas desconectadas em uso.

Quando faz sentido priorizar Splunk em vez de alternativas?

Splunk se destaca quando você precisa correlacionar muitos tipos de dados diferentes, em alto volume, com requisitos fortes de segurança, auditoria e disponibilidade.

Ferramentas de logging mais simples, soluções puramente open source ou produtos focados em um único domínio podem atender cenários menores, mas tendem a perder fôlego quando a complexidade e as exigências de governança aumentam.

Alguns sinais práticos de que Splunk é uma boa escolha:

• Você tem múltiplas ferramentas de monitoração e SIEM que não conversam bem
• Auditorias estão cada vez mais difíceis por causa de logs distribuídos e incompletos
• Incidentes críticos geram discussões longas sobre onde está o problema em vez de ações rápidas
• O tempo entre um alerta relevante e uma ação eficaz é alto e difícil de medir.

Quais os benefícios de negócio que o Splunk traz em 2026?

Em 2026, organizações usam Splunk não só para ver dados, mas para melhorar resiliência digital — capacidade de evitar grandes falhas, absorver choques e continuar operando mesmo em cenários adversos.

Isso impacta diretamente receita, reputação e custos operacionais, especialmente em empresas com forte exposição digital.

Os ganhos mais comuns que vemos em projetos são:

• Redução de MTTR (Mean Time To Resolution) em incidentes de aplicações críticas
• Menos tempo gasto montando relatórios e evidências para auditorias e comitês
• Menor dependência de heróis individuais e maior padronização de resposta a incidentes
• Visão unificada de risco e performance, permitindo decisões mais rápidas e embasadas

Como começar com Splunk com menos risco?

A melhor forma de começar com Splunk é com um projeto orientado a casos de uso claros, em vez de tentar indexar tudo logo de início.

Isso ajuda a medir valor, calibrar volume de dados, licenciamento e esforço do time sem travar o projeto em discussões abstratas de arquitetura.

Um caminho que adotamos na DataRunk é:

1. Escolher casos de uso com impacto direto em negócio (por exemplo, segurança de um canal digital ou disponibilidade de uma aplicação core).
2. Mapear quais fontes de dados são realmente necessárias para esses casos.
3. Definir métricas de sucesso (redução de MTTR, menos chamados, ganho de visibilidade, atendimento a requisitos de auditoria).
4. Implementar dashboards, alertas e, quando fizer sentido, playbooks de automação.
5. Só depois expandir para outros times, aplicações e fontes de dados.

Erros comuns que vemos ao adotar Splunk

Alguns padrões se repetem em projetos de Splunk e prejudicam o retorno sobre o investimento:

• Tentar levar todos os logs possíveis, sem priorização por valor de negócio, para dentro do Splunk
• Tratar Splunk só como caixa de logs, sem explorar correlação, automação e observabilidade
• Falta de governança sobre quem cria buscas, dashboards e alertas (ambiente vira uma colcha de retalhos)
• Ausência de um dono claro por caso de uso: segurança, operações, desenvolvimento e negócio não se coordenam

Evitar esses erros passa por começar pequeno, com objetivos claros, e ter um parceiro experiente para orientar desenho de arquitetura, ingestão e uso de funcionalidades avançadas.

Como aprender a usar o Splunk e formar um time competente?

Para tirar todo o valor da plataforma, você precisa de pessoas capazes de escrever buscas em SPL, desenhar dashboards centrados em negócio e configurar alertas e playbooks de forma consistente.

O ecossistema oficial da Splunk oferece documentação extensa, cursos, certificações e uma comunidade ativa, e muitos times combinam isso com treinamento prático direcionado aos seus casos de uso.

Alguns caminhos úteis:

• Documentação e tutoriais oficiais Splunk, incluindo casos de uso de segurança e observabilidade
• Trilhas de certificação para administradores, analistas de segurança e engenheiros de observabilidade
• Treinamentos customizados baseados nos dados e nos problemas reais da sua empresa.

Sobre a Splunk: de startup a empresa Cisco

A Splunk foi fundada em 2003, em São Francisco, por Michael Baum, Rob Das e Erik Swan. A ideia central era simples: tornar pesquisáveis os logs e dados de máquina que as empresas geravam, mas não sabiam como usar. O resultado foi o que o mercado chamou de Google para dados de máquina.

A empresa cresceu rapidamente e abriu capital na Nasdaq em 2012, captando US$ 230 milhões. Pouco mais de uma década depois, em março de 2024, a Cisco concluiu a aquisição do Splunk por US$ 28 bilhões, a maior da história da Cisco.

A combinação faz sentido estratégico: a Cisco lidera em redes e infraestrutura; a Splunk, em segurança e análise de dados. Juntas, entregam visibilidade unificada do endpoint à nuvem, com o reforço do Cisco Talos — uma das maiores bases de threat intelligence do mundo — integrado ao ecossistema Splunk.

Para quem avalia o Splunk Enterprise Security hoje, a aquisição é um ativo: a plataforma segue evoluindo, agora com o respaldo tecnológico e financeiro de uma das maiores empresas de tecnologia do planeta.

Onde a DataRunk entra na jornada com Splunk?

A DataRunk é o Splunk Partner Elite brasileiro mais recomendado. Atuamos justamente no ponto em que a teoria da plataforma encontra os desafios do mundo real: múltiplos times, sistemas legados, nuvens diferentes, requisitos de compliance e pressão por resultados rápidos.

Combinamos conhecimento profundo de Splunk com experiência prática em cenários de alta criticidade em observabilidade, segurança e governança de dados para priorizar casos de uso, estruturar ingestão, desenhar dashboards e automatizar respostas de forma alinhada com objetivos de negócio, com as melhores práticas de desenvolvimento.

Se você está avaliando Splunk ou querendo extrair mais da plataforma que já tem, um bom próximo passo é mapear seus principais incidentes e dores atuais e entender onde um Splunk Partner pode ajudar a reduzir risco e acelerar a tomada de decisão. 

Se você quer falar de Splunk, encontrou o interlocutor certo. Solicite nosso contato.

O post Splunk: o que é, para que serve e quando usar apareceu primeiro em DataRunk.

Os dados corroboram o que você vê: 

• 82% dos Centros de Operações de Segurança não atingem o nível de maturidade mínimo esperado, segundo o estudo HPE State of Security Operations
• A maturidade média dos SOCs que avaliamos no DataRunk Advisory & Strategy é de 21%. 

Geralmente, essa parada de evolução não tem como causa inerente as ferramentas implantadas, as pessoas ou os processos de SOC. O problema de maturidade do SOC tem a ver com a conexão e aproveitamento desses recursos. 

Como definir essas causas?

O que separa um SOC maduro de um SOC ocupado

Na DataRunk nós analisamos e trabalhamos o diagnóstico de maturidade do SOC no Runk Advisor sob três dimensões interdependentes: pessoas, ferramentas e processos. 

Quando uma delas está quebrada, as outras duas colapsam junto: tecnologia mal calibrada performa mal, gera ruído e crise constante, que sobrecarregam pessoas; pessoas sobrecarregadas não mantêm ou melhoram processos; processos deteriorados deixam a tecnologia ainda mais mal aproveitada.

Na maioria dos cenários, os ajustes nesse círculo vicioso não passam pela aquisição de novas ferramentas, renovação do time ou redesenho completo de processos. 

Para identificar em que ponto você deve mexer para mudar os ponteiros, você precisa diagnosticar. 

O relatório completo da maturidade do SOC está esperando por você

Com base em 200 projetos ao longo dos anos, produzimos nosso Relatório de Estado de Maturidade do SOC, que reúne as causas mais comuns que impedem o SOC de evoluir.

O diagnóstico detalha cada causa dentro das três dimensões que analisamos em nosso assessment inicial (Processos, Pessoas e Tecnologias), com dados e sinais práticos que você pode checar hoje na sua operação.

Acesse o relatório completo na DataRunk aqui.

O roadmap para alçar a maturidade da sua operação

Operações de segurança maduras se preocupam em consolidar o seu stack, ter qualidade da detecção, criar playbooks de resposta e unificar as operações das pessoas que os executam.

• Tecnologia não é vista como fim em si mesmo, e sim como suporte da inteligência de cibersegurança para detecção, investigação e resposta da operação.
• Processos não apenas funcionam apenas no papel, mas para orientar a ação dos times de engenharia e CSIRT
• Pessoas não apenas apagam incêndios, mas sabem o seu papel dentro do processo e como aproveitar a capacidade tecnológica de que dispõem para colaborar entre si.

Se você já sabe quais são os desafios do seu SOC, mas precisa de ajuda para construir, executar e avaliar o roadmap de ações, nós podemos apoiar você. Agende agora a sua conversa.

O post Maturidade do SOC: por que 82% das operações de segurança ainda falham apareceu primeiro em DataRunk.

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:

1. Expandindo a cobertura da Ferramenta A para 100%
2. Expandindo a cobertura da Ferramenta B para 100%
3. 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!

O post Guia da migração de SIEM: quando e como se preparar apareceu primeiro em DataRunk.

Esse é um limite que muitas empresas que fazem BAS encontram: a ferramenta funciona, mas a postura de defesa não tem uma melhora incremental na velocidade esperada.

Como destaca o CTEM.org, o BAS é “uma das formas mais escaláveis de produzir evidência contínua e repetível de que os controles de segurança se comportam como esperado”. Mas essa evidência precisa entrar em um ciclo que a transforme em ação. É essa ação que geralmente não acontece de maneira adequada.

A razão é mais estrutural do que técnica, pois o BAS é um mecanismo de validação, não de mobilização. 

Nós temos conseguido resultados muito melhores quando realizamos o BAS dentro de um programa CTEM — Continuous Threat Exposure Management.

Neste artigo explicamos por que e como a integração BAS-CTEM muda o resultado.

O que o BAS entrega bem 

O Breach and Attack Simulation automatiza a execução de técnicas adversariais em um ambiente real, com o objetivo de verificar se os controles de segurança — EDR, SIEM, firewall, SOAR, controles de e-mail — detectam, bloqueiam ou respondem como esperado.

Na prática, uma plataforma de BAS executa TTPs (táticas, técnicas e procedimentos) mapeadas no MITRE ATT&CK, simula movimentos laterais, exfiltração de dados e escalonamento de privilégios, e retorna evidências mensuráveis, como “esse controle bloqueou”, “esse não detectou”, “essa cadeia de ataque chegou até aqui”.

O que o BAS entrega bem:

• Verificação contínua da eficácia dos controles
• Identificação de lacunas de detecção (telemetria ausente, regras mal configuradas…)
• Evidência técnica auditável, repetível, sem depender de janela de pentest anual
• Testes orientados a TTPs de ameaças reais e relevantes ao setor.

O que o BAS não foi projetado para fazer sozinho

• Definir o que proteger primeiro com base em risco de negócio
• Descobrir a superfície de ataque da organização
• Priorizar a remediação considerando a criticidade de ativo, probabilidade de exploração e impacto operacional
• Garantir que os achados se transformem em correção atribuída, rastreada e verificada.

É normalmente nessas respostas que a ferramenta BAS não entrega que estão o problema. Vejamos os efeitos abaixo:

Gap de remediação 

O BAS pode sinalizar um controle falho de EDR hoje. Se não houver um processo formal de priorização de patches, atribuição e SLA de remediação, essa descoberta vai engrossar o backlog, e provavelmente ainda estará lá quando o próximo ciclo de simulação rodar.

Descobertas se tornam ruído

O BAS, quando opera sem integração a um processo de priorização por risco de negócio, contribui para um problema que já assola os programas de segurança: sobrecarga de alertas. 

O efeito prático: analistas passam a tratar achados de BAS como mais um item na fila. Sem contexto de negócio — “esse controle falhou em uma cadeia que pode chegar ao sistema de faturamento” —, a urgência se dissolve.

Dados do Ponemon-Sullivan Report mostram que 26% das organizações citam a priorização de risco pouco clara como o maior obstáculo para remediar exposições. 

Escopo do BAS é parcial por definição

Ferramentas de BAS simulam ataques em condições controladas. Cada execução cobre um subconjunto do ambiente, com técnicas pré-carregadas. O BAS responde bem a “esse controle funciona contra esse TTP?”, mas isso não necessariamente responde se o caminho de ataque ameaça mais ativo mais crítico agora?.

Essa correlação é talvez o ponto mais negligenciado. Porque a organização pode rodar centenas de simulações por mês e nunca chegar a testar um caminho de ataque que pode ser bem-sucedido, simplesmente porque ele não estava no escopo padrão da ferramenta.

Segundo a XM Cyber, ferramentas tradicionais de BAS frequentemente:

• Focam em vulnerabilidades individuais, sem simular cadeias de ataque complexas
• Oferecem visão estática da postura de segurança, sem monitoramento contínuo adaptativo
• Apresentam limitações de integração com ambientes cloud
• Dependem de cenários predefinidos que podem não refletir as TTPs mais recentes.

O BAS dentro do CTEM

Diferentemente do BAS, que é uma ferramenta, o CTEM é definido pelo Gartner como um programa operacional contínuo que opera em cinco fases interdependentes. Para ver uma descrição detalhada das etapas, acesse este artigo. Em resumo, temos:

1. Scoping — Definir o que importa para o negócio
2. Discovery — Mapear a superfície de ataque real
3. Prioritization — Focar no que tem impacto real
4. Validation — Onde o BAS entra como protagonista
5. Mobilization — Garantir que a correção aconteça.

Vamos analisar ponto a ponto os benefícios de incluir o BAS dentro de um programa CTEM.

O BAS passa a testar o que foi priorizado, não o que é conveniente testar

Dentro do CTEM, os cenários de BAS são escolhidos a partir das exposições priorizadas nas fases anteriores. Se a fase de priorização identificou que o caminho crítico passa por credenciais de serviço em ambiente Azure com acesso a dados PCI, os cenários de BAS são ancorados exatamente ali, não em um catálogo genérico de simulações.

O CTEM.org propõe uma classificação prática de cenários:

• Tier 1 (sempre ativo): conjunto reduzido de testes de alto sinal conectados a ativos críticos e controles essenciais. Roda com frequência, gera baseline.
• Tier 2 (acionado por mudança): acionado quando há atualização de política de EDR, mudança de identidade, novo deployment em cloud.
• Tier 3 (campanha): pacotes de cenários mais profundos ligados a ameaças emergentes, inteligência de ameaças recente ou iniciativas de negócio específicas.

As descobertas têm destino certo: remediação rastreável

No modelo CTEM, um achado de BAS não termina em um relatório. Ele entra em um backlog priorizado com contexto de risco, responsável designado e SLA. O reteste fecha o ciclo e fornece a métrica que importa: a exposição foi realmente corrigida?

As métricas recomendadas pelo CTEM.org para esse ciclo incluem:

O contexto de negócio transforma a linguagem do BAS

Um CISO não consegue justificar investimentos quando diz que 53% das simulações falharam no controle X, ele consegue quando afirma que a equipe identificou um caminho de ataque validado do vetor de phishing até o ambiente de dados de clientes, com impacto estimado em caso de exploração que inclui notificação regulatória e potencial de R$ Y em multa da LGPD.

O CTEM fornece o contexto de negócio que transforma o output técnico do BAS em linguagem executiva acionável.

Exemplo prático: como o mesmo achado tem destinos diferentes no CTEM e no BAS

Cenário 1 – BAS isolado
Uma simulação identifica que o controle de EDR não detecta técnica de process injection (T1055 do MITRE ATT&CK) em 3 endpoints do setor financeiro. O relatório é gerado. O analista abre um ticket. O ticket entra na fila junto com 47 outros. Três meses depois, o BAS roda novamente. A mesma técnica ainda não é detectada.

Cenário 2 – BAS dentro do CTEM
A fase de priorização do CTEM identificou que esses 3 endpoints têm acesso direto ao sistema de aprovação de pagamentos — uma joia da coroa. O BAS é acionado com cenário Tier 1 para validar exatamente esse caminho. A falha de detecção é validada com evidência técnica. A exposição entra no backlog com contexto: processo de injeção não detectado em endpoints com acesso ao sistema de pagamentos — risco de impacto financeiro direto. Responsável designado. SLA de 15 dias. Reteste agendado. Em 3 semanas, o controle está ajustado e o reteste confirma a detecção.

Mesmo achado técnico. Destinos completamente diferentes.

Sem CTEM, o BAS testa o que está no catálogo padrão da ferramenta, gera relatórios técnicos, alimenta backlog sem priorização clara e raramente fecha o ciclo com reteste verificado. Dentro CTEM, o BAS vai testar cenários derivados das exposições priorizadas por risco de negócio.

Ter uma ferramenta de BAS é suficiente para implementar CTEM?

Não. Como vimos, o CTEM envolve outras etapas. Ele requer scoping orientado a negócio, descoberta contínua de superfície de ataque, priorização com contexto de impacto real, validação da exposição e um processo formal de mobilização.

O BAS é um dos mecanismos da fase de validação; não é o programa completo.

Mas é possível começar o CTEM tendo apenas uma ferramenta de BAS como ponto de entrada.

Usando os dados históricos de BAS, você pode identificar padrões de falha e os ativos mais expostos. Esses dados pode informar a fase de scoping e priorização inicial do CTEM. 

BAS é combustível, CTEM é o motor

O erro mais comum do BAS não está na ferramenta. Novamente, está no processo, que não foi desenhado para transformar evidência em ação.

As ferramentas BAS entregam o que prometem: validação contínua, técnica, repetível da eficácia dos controles.

Mas validação sem priorização baseada em risco real, sem atribuição clara e sem mobilização estruturada não reduz a postura de exposição da organização.

O Gartner projetou uma redução de dois terços no exposição para organizações que estruturam seus investimentos em segurança com base em CTEM. Essa projeção não está atrelada à compra de uma ferramenta específica. Está atrelada à existência de um programa que conecta cada achado técnico a uma decisão de negócio e a uma ação verificável.

Você quer ver uma jornada para o CTEM? Acesse este guia que construímos.

O post BAS: por que dá mais resultados dentro de um CTEM apareceu primeiro em DataRunk.

A engenharia de detecção ganhou outro estatuto dentro do SOC. Ela é prioridade – e o coração da operação. Nessa esteira, as práticas de engenharia de detecção estão amadurecendo. 

O State of Detection Engineering 2026 da SANS, traz um bom quadro dessas mudanças.

A principal é uma realidade dura: 80% dos profissionais ainda estão apenas nadando contra a corrente ou ficando ativamente para trás em relação às ameaças emergentes. Apenas 18% dos profissionais relatam estar à frente das ameaças.

Como ter uma engenharia de detecção adequada?

Primeiro, vamos detalhar o que estamos compreendendo por engenharia de detecção.

Engenharia de detecção além da tradicional detecção de ameaças

De acordo com matéria do CSO, quando se fala em engenharia de detecção, diz-se algo distinto das práticas tradicionais de detecção de ameaças. E isso em questão de abordagem, metodologia e integração com o ciclo de vida de desenvolvimento. 

Os processos tradicionais de detecção de ameaças são tipicamente reativos, dependente de regras pré-construídas por fornecedores. Ou seja, eles têm baixo nível de personalização. Isso não é um problema por si só. As detecções dos fornecedores são essenciais para acelerar a cobertura da superfície de ataque. O problema é quando se fica só nisso, sem adotar uma engenharia de detecção.

A engenharia de detecção se apropria de técnicas de desenvolvimento de softwares para criar e manter lógicas de detecção personalizadas ao cenário de ameaças de uma organização. 

Isso frequentemente envolve uma ênfase maior em detecções baseadas em comportamento, integração de threat intelligence para criar detecções alinhadas com as táticas reais de adversários, e uso de modelagem de ameaças para antecipar possíveis caminhos de ataque, cita um especialista entrevistado pelo CSO. 

Visto isso, podemos conceituar engenharia de detecção.

Conceito básico de engenharia de detecção

A engenharia de detecção é a criação e implementação de regras inteligentes para identificar possíveis ameaças de segurança dentro do ambiente tecnológico de uma organização, sem gerar uma enxurrada de falsos positivos. 

O processo de engenharia de detecção normalmente envolve modelagem de ameaças, compreensão das táticas, técnicas e procedimentos (TTPs) dos atacantes, redação, testes e validação de regras de detecção, além da adaptação das detecções com base em novas ameaças e técnicas de ataque.

Ferramentas mais adotadas para engenharia de detecção

Como fazer engenharia de detecção de maneira sistemática

A maioria das organizações — especialmente de grande porte — pode se beneficiar da implementação de uma abordagem sistemática para desenvolver detecções adaptadas ao seu perfil de ameaças e com alto grau de fidelidade.

Com uma abordagem sistemática, a equipe passa a ver a engenharia de detecção como um processo. Existem fluxos de trabalho bem conhecidos, como SIEM Use Cases Development (Alex Teixeira) e Detection as Code, que servem de referência para a construção de detecções que gerem alertas de alta fidelidade.

Alguns requisitos fundamentais para adotar uma abordagem sistemática em engenharia de detecção:

Ter um time de profissionais dedicados

Em muitos casos, os times de engenharia de detecção têm de uma ou duas pessoas ou estão atrelados ao SOC.

A despeito da especificidade de cada cenário, verdade seja dita: uma função crítica de segurança não pode estar atrelada a uma equipe tão reduzida ou com outra atividade primária. Nesse tipo de cenário, o trabalho fica dependente da estabilidade do pessoal, e os efeitos recaem sobre a continuidade da cobertura, a retenção de conhecimento e a velocidade de detecção da organização.

Investir em uma equipe dedicada de engenharia de detecção é um passo fundamental para resolver problemas estruturais que a excelência de um indivíduo não consegue superar. É o que fazemos aqui na DataRunk, com a squad de SIEM. Nos clientes em que operamos o SOC, sempre parte do trabalho será executado em cima das detecções vai ser executado pelo time. Porém, criação ou modificações em detecções complexas serão desenvolvidas por um time dedicado.

Para construir um programa resiliente, os líderes devem estabelecer uma função de engenharia de detecção definida e com pessoal suficiente para manter a cobertura contínua — recomendando um mínimo de três profissionais.

Além disso, essa equipe precisa de um estatuto documentado que separe explicitamente o seu trabalho especializado de detecção das tarefas gerais de operações de segurança.

Construir as competências necessárias

Fechar lacunas de habilidades técnicas é o segundo passo crítico, logo após estabelecer uma equipe de detecção dedicada. Não subestime esse passo. A falta das competências adequadas é uma das principais razões que impedem o amadurecimento da engenharia de detecção.

De acordo com a SANS, skills como engenharia de software e engenharia de dados “são requisitos absolutos para a análise moderna de ameaças” – que faz uso intensivo de dados – e para a transição do setor em direção à detecção como código (DaC). Além disso, sem essas capacidades centrais de engenharia, a adoção de data lakes modernos ou plataformas nativas em nuvem apenas adiciona complexidade, em vez de realmente fechar as lacunas de cobertura de segurança.

Aqui, o remédio é financiar treinamentos especializados em engenharia de software e de dados para a equipe de detecção atual.

Se desenvolver essas habilidades internamente não for viável, as organizações podem recrutar deliberadamente profissionais que já possuam um forte histórico em engenharia, seja por meio de contratações de profissionais, seja por professional services.

Engenharia de detecção: amplie a capacidade de identificar ameaças

Os SOC precisa de uma engenharia de detecção madura e escalável para acompanhar o ambiente de ameaças protegendo o que interessa para a continuidade do negócio.

Vimos os passos que você pode dar para evoluir essa competência. Pavimentar o caminho para praticar engenharia de detecção em alto nível requer pessoas dedicadas, com as competências adequadas, direcionamento alinhado ao risco para o negócio e capacidade de incorporar IA e automação – em cima da estrutura tecnologia que você já tem.

Você quer acelerar esse caminho? A DataRunk pode ajudar a acelerar essa jornada na sua organização. Fale conosco!

O post Engenharia de detecção: adequando processo ao ritmo das ameaças apareceu primeiro em DataRunk.

Mas o problema não é só a escala, são os silos operacionais entre as equipes de cyber, fraude e AML.

Quando um atacante compromete uma conta via phishing, executa um adversary-in-the-middle para fazer bypass de MFA e em seguida instrui uma transferência fraudulenta, três times diferentes observam o mesmo incidente com vocabulários completamente distintos:

• O SOC registra um ataque de engenharia social e uma sessão de browser comprometida.
• O time de fraude classifica como um account takeover.
• O AML sinaliza uma transação suspeita de alto risco.

Nenhum dos três está errado. Mas, sem uma taxonomia compartilhada, eles raramente chegam a perceber que estão descrevendo o mesmo ator, na mesma campanha, em etapas sequenciais.

O MITRE Fight Fraud Framework (F3) foi construído exatamente para eliminar esse gap.

O que é o MITRE F3?

Lançado em abril de 2026 pelo Center for Threat-Informed Defense (CTID) do MITRE, o F3 é uma base de conhecimento comportamental estruturada em táticas, técnicas e sub-técnicas utilizadas por atores de fraude em incidentes financeiros cibernéticos. 

O framework foi desenvolvido em colaboração com JPMorganChase, Citigroup, FS-ISAC, Lloyds Banking Group, CrowdStrike, Standard Chartered, Verizon Business e outros.

Assim como o MITRE ATT&CK, o F3 organiza o comportamento do adversário em três camadas:

• Táticas: o objetivo do ator em cada estágio (por quê)
• Técnicas: como o ator atinge esse objetivo (como)
• Sub-técnicas: implementações específicas (com o quê).

O F3 é compatível com o ATT&CK e publicado em formato STIX 2.1, disponível publicamente neste portal.

As 7 táticas do F3

As táticas Positioning e Monetization são exclusivas do F3. Portanto, ausentes no ATT&CK clássico. Elas cobrem exatamente o lugar em que a telemetria de fraude vive, e onde a telemetria cibernética tradicional normalmente termina.

Os 7 pontos de conexão entre o MITRE F3 e o SOC

1. Detection engineering: novos casos de uso para SIEM

O ganho mais imediato é usar o MITRE F3 para mapear e expandir a cobertura de detecção. Cada técnica do framework pode ser vinculada a regras SIEM, alertas UEBA ou queries de threat hunting, exatamente como é feito hoje com o ATT&CK Navigator.

As técnicas da série F1XXX – criadas especificamente para o F3, e sem equivalente no ATT&CK – são candidatas diretas ao desenvolvimento de novas regras.

Exemplos de técnicas de alto impacto para use cases no SIEM:

• Phone Number Spoofing / Caller ID Spoofing: falsificação de identidade via voz
• Adversary-in-the-Middle: interceptação de sessão, com bypass de MFA
• MFA Takeover: fatigue attacks e interceptação técnica de OTP
• Steal Web Session Cookie: tokens de sessão roubados para bypass de autenticação
• Account Takeover: via credenciais, API keys, abuso de fluxo de reset de senha
• Credential Stuffing / Brute Force: ataques volumétricos em portais de autenticação

Para cada técnica, a pergunta de detection engineering é: quais fontes de dados da organização cobrem esse comportamento e qual regra SIEM ou alerta UEBA consegue observá-lo?

2. Threat intelligence: Bundle STIX 2.1 pronto para ingestão

O F3 é publicado em STIX 2.1, o mesmo formato padrão usado por plataformas de Threat Intelligence e por SIEMs modernos. Isso significa que o conteúdo do framework pode ser ingerido diretamente em ferramentas como:

• OpenCTI (conector já em desenvolvimento pela comunidade)
• Microsoft Sentinel (via TAXII feed)
• Elastic Security (via custom threat intelligence integration)
• Qualquer TIP com suporte a STIX/TAXII

Para as equipes de CTI do SOC, isso viabiliza a criação de objetos de inteligência – campaigns, threat actors, TTPs – etiquetados com identificadores F3 padronizados. O resultado é inteligência de fraude com o mesmo rigor metodológico aplicado à inteligência cibernética tradicional.

3. Incident response: contexto do ciclo completo

Um alerta de phishing no SIEM pode ser apenas a ponta de um iceberg. O F3 fornece o mapa do ciclo completo de um incidente de fraude — do Reconnaissance ao Monetization —, permitindo que o analista entenda em qual estágio o alerta foi gerado e o que provavelmente vem a seguir.

Isso transforma a forma como playbooks de resposta a incidentes são construídos. Ao invés de tratar cada alerta como um evento isolado, o SOC pode estruturar respostas que considerem a progressão típica de uma campanha de fraude:

• Detecção de adversary-in-the-middle → acionar verificação de Positioning (há manipulação de dados de conta em curso?) e de Monetization (há transferências pendentes ou aprovadas recentemente?)
• Alerta de credential stuffing → correlacionar com logs de mudança de número de telefone ou e-mail de recuperação nas últimas 72h.

Esse raciocínio de cadeia de ataque já é natural para analistas treinados em ATT&CK. O F3 estende essa habilidade para o ciclo de fraude financeira.

4. Threat hunting: hipóteses baseadas em comportamento

O F3 é um modelo comportamental, não baseado em IOCs. Isso o torna especialmente valioso para threat hunting (buscas por comportamentos anômalos antes que qualquer alerta seja disparado).

Caçadores de ameaças podem usar as técnicas do F3 para formular hipóteses de hunting derivadas de incidentes reais documentados no framework:

Hipótese 1 — Steal web session cookie: existem sessões web ativas com o mesmo token de autenticação sendo utilizado em dois contextos geográficos distintos com intervalo menor que 30 minutos?

Hipótese 2 — MFA takeover (fatigue): há padrões de 5+ push notifications de MFA enviados ao mesmo usuário em um intervalo de 10 minutos, seguidos de aprovação?

Hipótese 3 — Positioning / Account takeover: existem alterações de número de telefone ou e-mail de recuperação em contas que realizaram login com sucesso nas últimas 24h, mas não tinham histórico de alterações de dados nos 90 dias anteriores?

5. Conexão SOC <> Fraude <> AML

Este é o ponto de maior valor estratégico. O F3 foi projetado especificamente para ser o tradutor universal entre times que hoje operam em silos — cyber, fraude e AML.

Cada um desses times tem ferramentas, métricas e vocabulário próprios. O F3 fornece a taxonomia compartilhada que permite correlacionar eventos observados por times diferentes como partes do mesmo incidente.

Na prática operacional, isso viabiliza a criação de BSOC, BOC ou CFC: equipes combinadas de analistas de cyber, fraude e AML, com workflows integrados e análise conjunta de incidentes. O F3 atua como o documento de referência comum que sustenta esses workflows — do ticket inicial no SIEM ao relatório de investigação final.

Como os autores do MITRE descrevem:

Fraud actors do not operate within the boundaries of organizational charts. They move seamlessly across cyber systems and fraud channels, combining techniques to steal your money and the bank’s money.

6. Gap analysis: mapeamento de cobertura de controles

A matriz F3 pode ser usada diretamente para conduzir uma análise de cobertura de controles, seguindo a mesma metodologia usada com o ATT&CK:

1. Para cada técnica F3, identificar se há detecção ativa (alerta disparado), detecção passiva (log disponível, sem alerta) ou gap (sem visibilidade)
2. Cruzar esse mapeamento com a criticidade das técnicas observadas em incidentes reais da organização
3. Priorizar o desenvolvimento de use cases com base no impacto potencial e na facilidade de implementação.

O resultado é uma lista objetiva de prioridades para o time de detection engineering, especialmente útil quando os recursos são escassos e a pressão para demonstrar ROI é alta.

7. Métricas e reporting: padronização para CISO e compliance

A taxonomia padronizada do F3 permite que incidentes de fraude sejam reportados com a mesma consistência e rastreabilidade que incidentes cibernéticos tradicionais. Para o CISO, isso significa:

• Dashboards de tendência por tática e técnica ao longo do tempo
• Comparação por período de quais estágios do ciclo de fraude estão sendo mais explorados
• Evidências estruturadas para relatórios regulatórios (BACEN, resolução BCB nº 538/2025, PCI-DSS)

Para compliance e auditoria, a documentação de incidentes com referências a técnicas F3 padronizadas aumenta a rastreabilidade e facilita tanto auditorias internas quanto a produção de evidências em investigações formais.

MITRE F3 e MITRE ATT&CK: uso complementar, não substituição

O F3 não substitui o ATT&CK. Muito pelo contrário. Os dois frameworks são complementares e cobrem partes distintas do mesmo ciclo de ataque:

A recomendação operacional do MITRE CTID é usar o ATT&CK para mapear o comprometimento técnico e o F3 para mapear o ciclo de vida de fraudes que decorrem desse comprometimento técnico. Na prática, os dois frameworks se articulam: onde o ATT&CK termina (acesso inicial, execução de código), o F3 continua (Positioning, Monetization).

Limitações do F3

O F3 é um modelo de coordenadas, não de decisão. Ele descreve comportamentos e não pontua transações, não substitui modelos de ML e não isenta a organização das obrigações regulatórias de AML/KYC. A qualidade da detecção ainda depende da maturidade do pipeline de dados e da cobertura de logs da organização.

O framework foi lançado em abril de 2026 e ainda não inclui, na versão inicial, fontes de dados mapeadas por técnica nem mitigações recomendadas. Esses recursos o MITRE planeja adicionar nas próximas iterações. 

Como começar a implementar o F3 em um SOC existente?

O MITRE CTID recomenda cinco passos: 

1. Integrar operacionalmente os times de fraude e cyber
2. Documentar incidentes usando a taxonomia F3
3. Mapear técnicas às fontes de dados disponíveis
4. Construir regras de detecção
5. Conduzir gap analysis periódico.

Organizações que já possuem maturidade em ATT&CK — com cobertura de detecção mapeada e processos de threat-informed defense estabelecidos — estarão em posição favorável para absorver o F3 com menor esforço de adaptação.

Absorva o F3 com menor esforço de adaptação

O MITRE F3 representa uma mudança estrutural na forma como times de segurança e prevenção a fraudes podem trabalhar juntos. Para um SOC no setor financeiro, o framework oferece sete pontos concretos de integração: detection engineering, threat intelligence, incident response, threat hunting, convergência com times de fraude e AML, gap analysis de controles e métricas padronizadas para liderança.

A barreira de adoção para times que já operam com ATT&CK é baixa. A estrutura é familiar; o que muda é o escopo e, com isso, a capacidade de enxergar o ciclo completo de um ataque que antes era visível apenas em fragmentos.

O F3 está disponível gratuitamente. A matriz completa, o bundle STIX 2.1 e a documentação de design estão acessíveis. Mergulhar para entendê-lo melhor é nosso papel.

O post MITRE F3 e SOC: a conexão entre cibersegurança e prevenção a fraudes financeiras apareceu primeiro em DataRunk.