A detecção de ameaças em um SOC depende menos da pilha de ferramentas e mais de três decisões operacionais: manter linhas de base do ambiente, afinar alertas para separar ruído de comportamento adversário e dar aos analistas autoridade real para conter incidentes. A prova mais recente veio da CISA: em avaliações simultâneas de red team contra organizações de infraestrutura crítica, um SOC não conseguiu detectar o comprometimento completo do domínio enquanto o outro identificou e colocou em quarentena o acesso inicial do adversário com o mesmo tipo de tradecraft. Este guia traduz esse contraste em práticas verificáveis para equipes técnicas que operam monitoramento, triagem e resposta a incidentes no dia a dia.
O que separa SOCs eficazes
O advisory A Tale of Two SOCs, publicado pela CISA em agosto de 2026, documenta duas avaliações conduzidas com técnicas semelhantes de phishing, escalada de privilégios e movimento lateral. Em uma das organizações, o red team obteve acesso inicial a estações de trabalho, elevou privilégios sobre o domínio e alcançou sistemas de negócio sensíveis e recursos de nuvem sem ser contido. Na outra, os defensores detectaram o comprometimento inicial rapidamente, isolaram os sistemas afetados e forçaram o red team a mudar para um modelo de assume breach, no qual parte da atividade posterior também foi detectada e colocada em quarentena.
| Aspecto | SOC que falhou | SOC que detectou |
|---|---|---|
| Detecção inicial | Não identificou a atividade como maliciosa | Identificou o comprometimento inicial |
| Volume de alertas | Volume incontrolável, sem afinação | Alertas afinados com baseline estabelecido |
| Resposta | Sem contenção; equipe sem procedimento de escalada | Isolamento rápido dos sistemas afetados |
| Desfecho | Comprometimento completo do domínio | Adversário forçado ao modelo assume breach |
A leitura operacional é direta: a tecnologia de detecção era comparável, mas o SOC que mantinha baseline e filtragem de alertas enxergou as anomalias que o outro SOC perdeu no ruído.
Baseline e afinação de alertas
O erro central identificado pela CISA não foi falta de ferramenta, foi falta de afinação. Segundo o advisory, sem linhas de base bem definidas e sem filtragem de alertas, falsos positivos e alertas rotineiros sobrecarregam os defensores e escondem as ameaças reais. A atividade do red team que disparou alerta e ação em uma organização simplesmente não gerou resposta na outra, porque a equipe não conseguiu distinguir comportamento malicioso em meio ao volume esmagador de notificações.
Para corrigir isso, a operação deve começar por três passos: documentar o comportamento normal de contas, tráfego de rede e ferramentas instaladas; configurar alertas que diferenciem ações administrativas típicas de comportamento de ameaça; e revisar continuamente essas regras conforme o ambiente muda. Alertas não afinados não são um incômodo cosmético — são a causa direta de ameaças reais perdidas na triagem.
Mapeando detecções com ATT&CK
Para transformar visibilidade em cobertura mensurável, a CISA recomenda mapear detecções contra o MITRE ATT&CK, descrito pela própria MITRE como uma base de conhecimento publicamente acessível de táticas e técnicas de adversários baseada em observações do mundo real. O advisory usa a matriz Enterprise do framework e lista passo a passo como testar controles: selecionar uma técnica descrita no relatório, alinhar as tecnologias de segurança contra ela, testar, analisar o desempenho de detecção e prevenção e repetir o processo para obter dados abrangentes de performance.
Esse ciclo fecha a lacuna entre o que o SOC acha que detecta e o que realmente detecta. Equipes que já operam detecção de movimento lateral podem aplicar o mesmo raciocínio em cenários como detecção de pass-the-hash no SOC, mapeando cada regra à técnica correspondente da matriz e medindo cobertura real em vez de cobertura presumida.
Monitoramento contínuo segundo o NIST
O alicerce conceitual dessa disciplina vem do NIST, que define monitoramento contínuo de segurança da informação como manutenção de consciência permanente sobre segurança da informação, vulnerabilidades e ameaças para apoiar as decisões de gestão de risco organizacional. A publicação SP 800-137 estabelece que frequência de avaliação dos controles deve ser suficiente para sustentar decisões de segurança baseadas em risco — ou seja, monitorar de vez em quando não é monitoramento contínuo.
Na prática, isso significa que o SOC precisa de visibilidade sobre ativos, consciência de ameaças e vulnerabilidades e medição da eficácia dos controles implantados. Falhas de cobertura em identidade são o exemplo mais comum: técnicas recentes de ransomware que burlam MFA e exigem detecção específica no SOC mostram por que a superfície monitorada precisa ser reavaliada sempre que o comportamento dos adversários muda.
Checklist de operação do SOC
Um checklist enxuto, derivado diretamente das recomendações da CISA, para auditoriar a maturidade da detecção:
- Estabelecer e manter continuamente baseline de ferramentas instaladas, comportamento de contas e tráfego de rede.
- Reduzir ruído refinando mecanismos de alerta para diferenciar ação administrativa típica de comportamento de ameaça.
- Quebrar silos entre TI, segurança e negócio com exercícios conjuntos, ferramentas compartilhadas e times multifuncionais.
- Definir papéis, autoridades e caminhos de escalada claros, garantindo poder de isolamento sem aprovações excessivas.
- Mapear cada regra de detecção a uma técnica ATT&CK e testar o desempenho contra ela em ambiente de produção.
- Implementar políticas de acesso condicional para identidades de carga de trabalho e monitorar permissões excessivas ou não usadas.
- Estabelecer procedimentos revisados para detectar, remediar e revogar tokens de acesso e refresh após comprometimento de nuvem.
- Habilitar MFA resistente a phishing para todas as contas de usuário, administrativas e privilegiadas.
Cada item desse checklist liga uma falha observada em campo a uma ação concreta. A mensagem central da CISA é que resultados dependem de gente, processo e procedimento tanto quanto da ferramenta — e que medir cobertura contra um framework externo é o único jeito de saber se o investimento em detecção está funcionando.
