Estudos apontam lacunas na cobertura de detecção e mostram por que a integração de dados, a engenharia de detecção e a investigação proativa são fundamentais para a eficácia dos Centros de Operações de Segurança
Por Tiago Rodilha
Uma empresa pode ampliar o número de ferramentas de segurança, centralizar milhões de registros de atividades e, ainda assim, não identificar uma ameaça cujos sinais estão presentes em seu próprio ambiente.
Esse é um dos principais desafios dos Centros de Operações de Segurança (SOCs). A capacidade de coletar informações avançou, mas a de relacioná-las para identificar e reconhecer comportamentos como suspeitos nem sempre acompanhou essa evolução.
O problema aparece no 2026 SANS SOC Survey Insights. Segundo a pesquisa, 24% dos líderes de cibersegurança apontam a falta de visibilidade em toda a organização como a principal barreira para aproveitar plenamente as capacidades do SOC, à frente de limitações de equipe ou automação.
Os profissionais que atuam diretamente na operação identificam dificuldades relacionadas ao mesmo cenário, como excesso de alertas em diferentes ferramentas sem correlação, pouco integradas e falta de contexto para priorizar incidentes.
É importante distinguir visibilidade de centralização. Os sistemas de gerenciamento de informações e eventos de segurança, conhecidos como SIEMs, já reúnem registros de diferentes fontes e permitem automatizar a correlação de eventos e soluções. Entretanto, concentrar esses dados não garante que a operação consiga reconhecer as relações que caracterizam uma ameaça. A eficácia depende das informações disponíveis, das regras implementadas, casos de uso e da capacidade de interpretar os eventos em conjunto.
Considere uma situação em que as credenciais corporativas de um funcionário foram expostas em um vazamento. Caso consiga superar os controles de autenticação, um cibercriminoso pode utilizar essas credenciais para acessar sistemas corporativos sem necessariamente acionar um alerta de segurança. Mesmo quando registrado pelos sistemas de autenticação, esse acesso pode não ser imediatamente identificado como suspeito, para efeito de autenticação é um acesso legítimo.
Essa avaliação muda quando o SOC consegue relacionar o acesso a informações de Threat Intelligence que indiquem a exposição das credenciais, além de identificar outros comportamentos atípicos, como a utilização de um dispositivo desconhecido ou a tentativa de acessar sistemas que não fazem parte da rotina daquele funcionário.
Correlacionar este evento pode ser ainda melhor se este SOC possuir uma equipe de Threat Hunting, que vai analisar o comportamento de forma isolada desse usuário, uma vez que se percebe uma ação fora do comum, pode significar um comprometimento e cabe uma análise mais completa da sequência de ações do usuário.
Nenhum desses eventos, isoladamente, comprova uma invasão. A correlação, porém, permite formular uma hipótese de comprometimento mais consistente e direcionar a investigação. Se o acesso envolver um sistema crítico para as operações da empresa, essa informação também deverá influenciar a prioridade da resposta.
O exemplo demonstra que a visibilidade de um SOC não depende apenas dos registros coletados pelo SIEM, mas também da capacidade de enriquecê-los com informações sobre exposição de credenciais, vulnerabilidades, identidades e criticidade dos ativos.
Esses dados podem estar integrados à plataforma ou disponíveis em outras fontes. Sem incorporá-los à análise, o SOC pode reconhecer a ocorrência de determinado evento, mas não compreender seu significado para a segurança do negócio.
Essa distância entre disponibilidade de dados e capacidade de detecção foi dimensionada pelo State of SIEM Detection Risk 2025, da CardinalOps. Os ambientes SIEM empresariais analisados na edição de 2025 possuíam, em média, regras de detecção para apenas 22% das técnicas catalogadas no MITRE ATT&CK, embora já recebessem telemetria suficiente para potencialmente cobrir 90% delas.
Os resultados evidenciam que ampliar a coleta não produz, automaticamente, uma expansão equivalente da cobertura de detecção. A disponibilidade de registros precisa ser acompanhada pela engenharia de detecção, responsável por desenvolver, ajustar e validar as regras que permitem identificar atividades potencialmente maliciosas.
Mas a existência dessas regras também não garante que uma ameaça será reconhecida. Um estudo publicado em setembro de 2026 pelo Center for Threat-Informed Defense, da MITRE, demonstrou, a partir da avaliação de regras de detecção Sigma baseadas em eventos de segurança do Windows, que associar uma regra a determinada técnica do MITRE ATT&CK não significa necessariamente conseguir detectar suas diferentes formas de execução.
Uma regra pode, por exemplo, reconhecer um executável específico utilizado em um ataque, mas deixar de identificar um comportamento equivalente quando o adversário utiliza outra ferramenta. Nesse caso, a técnica aparece como coberta no mapeamento, embora a detecção esteja limitada a uma implementação particular.
Isso acrescenta uma dimensão importante ao desafio da correlação. Não basta relacionar eventos de diferentes fontes. É necessário desenvolver e validar lógicas de detecção capazes de reconhecer comportamentos maliciosos, inclusive quando os atacantes modificam as ferramentas ou os procedimentos utilizados. Caso contrário, a operação pode apresentar indicadores de cobertura que não correspondem integralmente à sua capacidade efetiva de detecção.
Para CIOs e CISOs, essas limitações exigem uma análise mais criteriosa das prioridades de investimento. Uma lacuna causada pela ausência de telemetria pode exigir ajustes na coleta, integração de novas fontes ou, quando necessário, a aquisição de outra solução.
Já uma dificuldade de correlacionar registros disponíveis pode demandar melhorias nas regras de detecção e no enriquecimento dos dados. Quando as regras existentes não conseguem reconhecer diferentes formas de execução de uma ameaça, a prioridade pode estar na validação e no aperfeiçoamento dessas detecções.
São problemas distintos, que não deveriam receber automaticamente a mesma resposta orçamentária. Antes de ampliar a infraestrutura, é necessário identificar se a limitação está na disponibilidade dos dados, na capacidade de correlacioná-los ou na eficácia das regras implementadas.
Essa distinção também deve orientar a avaliação da maturidade do SOC. A quantidade de fontes monitoradas ou de técnicas mapeadas não demonstra, por si só, a capacidade de identificar um ataque. É necessário compreender quais comportamentos a operação consegue detectar nos ambientes mais críticos, quais dependências de informação ainda existem e como essa capacidade é verificada na prática.
Nesse processo, Threat Intelligence e Threat Hunting cumprem funções complementares. A inteligência sobre ameaças ajuda a contextualizar eventos e orientar a construção de hipóteses. Já a investigação proativa permite procurar comportamentos suspeitos que ainda não acionaram alertas e utilizar os resultados para aperfeiçoar as detecções existentes. O objetivo é transformar o conhecimento produzido pela operação em melhorias verificáveis na capacidade de identificar ameaças.
Essa evolução também depende de governança e de profissionais capazes de traduzir o conhecimento sobre ameaças em regras, processos de investigação e decisões de resposta. Sem esse trabalho contínuo, mesmo uma arquitetura tecnológica avançada pode operar abaixo de seu potencial.
Para a liderança de Tecnologia, a discussão sobre maturidade precisa considerar o que a organização realmente consegue identificar e responder nos sistemas que sustentam seus processos mais críticos. Um SOC pode demonstrar quantos milhões de eventos processa diariamente e, ainda assim, não conseguir responder quais comportamentos maliciosos identificaria caso um desses sistemas fosse comprometido.
A evolução de um SOC não pode ser confundida com a ampliação de sua infraestrutura tecnológica. Ela precisa ser demonstrada pela capacidade de utilizar os recursos disponíveis para reconhecer ameaças, orientar investigações e sustentar decisões de segurança alinhadas aos riscos do negócio.
Antes de decidir quais dados ou ferramentas acrescentar à operação, precisamos ser capazes de demonstrar o que o SOC efetivamente consegue detectar com os recursos que já possui.
Agradecimento
O Crypto ID agradece a Tiago Rodilha, Head de Security Operations Center (SOC) da NovaRed Brasil, pela contribuição e pela análise sobre os desafios da correlação de dados e da detecção de ameaças nas operações de cibersegurança. Sua participação contribui para ampliar o debate sobre a evolução dos SOCs e a importância de aprimorar continuamente as estratégias de proteção das organizações.
Imperva Threat Research analisa falhas críticas do PHP2Shell que permitem execução remota de código
Caso de Peter Williams: Funcionário autorizado, acesso legítimo e um roubo de US$ 35 milhões
ID Talk | Qubic retoma operações após ataque e Marco Zanini analisa falha criptográfica
IA na engenharia reversa de games ameaça segredos e propriedade intelectual
Conheça a coluna Cibersegurança.
Conselheiro de administração ou CISO? Leia também: Orçamento 2027: guia da NACD ensina CISOs a falar a língua do conselho.
