Conteúdo desenvolvido com base no artigo publicado na IT Insight por Tiago Rodilha, Head de SOC da NovaRed Brasil.
Seu SOC recebe um alerta. A equipe investiga, classifica, responde e encerra o caso. Esse fluxo faz parte da rotina de qualquer operação de segurança. Mas o que acontece quando o alerta não existe?
Essa é uma das perguntas que ajudam a separar uma operação predominantemente reativa de um SOC maduro. Afinal, os atacantes não precisam necessariamente executar uma ação que corresponda a uma regra de detecção já existente. Ao mesmo tempo, credenciais válidas, ferramentas legítimas e técnicas que exploram comportamentos permitidos podem permitir que um atacante avance pelo ambiente sem produzir um sinal óbvio para a equipe de segurança.
Ferramentas como SIEM, EDR e XDR ampliaram a capacidade de coletar, correlacionar e analisar dados. Ainda assim, tecnologia por si só não determina a maturidade de uma operação. Por isso, avaliar um SOC apenas pela quantidade de ferramentas instaladas ou pelo volume de alertas processados oferece uma visão limitada da sua capacidade de defesa.
Uma operação madura precisa ir além do que as ferramentas já conseguem apontar. Em outras palavras, precisa saber o que procurar, onde procurar, por que determinado comportamento é suspeito e o que fazer com aquilo que descobriu. Essa capacidade de investigar antes do alerta, transformar descobertas em novas detecções e incorporar o aprendizado à operação é o que começa a diferenciar um SOC que apenas responde de um SOC que evolui continuamente.
Um atacante não precisa criar um alerta para causar um problema.
Grande parte da lógica tradicional de monitoramento começa pelo evento que a ferramenta consegue identificar.
Um malware foi detectado; a conexão foi bloqueada, uma autenticação foi considerada suspeita ou um comportamento acionou uma regra.
A partir daí, começa a investigação.
Um atacante pode usar uma conta comprometida para acessar um sistema. Pode utilizar PowerShell ou outras ferramentas nativas. Além disso, pode realizar movimentações que, isoladamente, parecem compatíveis com a rotina de um usuário. Também pode permanecer no ambiente sem executar uma ação que corresponda exatamente a uma regra existente.
Nesse tipo de ataque, esperar o alerta significa aceitar que a primeira evidência será determinada pelo que a ferramenta já sabe reconhecer. Por essa razão, um SOC mais maduro trabalha com outra premissa: a ausência de alerta não comprova a ausência de ameaça.
O monitoramento continua sendo fundamental. Ainda assim, ele precisa ser complementado por investigação.
A pergunta muda de “o que aconteceu?” para “o que estamos deixando de enxergar?”
É aqui que entra o Threat Hunting.
Em uma investigação tradicional, a equipe recebe um sinal e procura entender sua origem, impacto e extensão. No Threat Hunting, por outro lado, a investigação começa antes do alerta.
A equipe formula uma hipótese e procura evidências que possam confirmá-la ou descartá-la.
Por exemplo:
Uma conta privilegiada pode estar sendo utilizada fora do padrão esperado?
Existem usuários acessando sistemas críticos sem uma justificativa operacional compatível?
Há movimentações laterais que não correspondem ao comportamento habitual daquele ambiente?
Alguma ferramenta legítima está sendo utilizada de uma forma que pode indicar abuso?
Essas perguntas mudam o trabalho do analista. Em vez de esperar uma regra indicar onde olhar, ele define o que precisa descobrir e quais dados podem responder à hipótese.
O próprio MITRE ATT&CK estrutura o Threat Hunting em torno de etapas como desenvolvimento de hipóteses, definição dos dados necessários, identificação de lacunas de coleta e implementação e teste de analytics.
Uma hipótese de hunting também testa a qualidade do SOC.
Imagine que a equipe formule uma hipótese sobre movimentação lateral. Antes de criar uma nova regra, ela precisa verificar se existem dados suficientes para investigar: logins, telemetria dos endpoints, relação entre identidade e dispositivo e eventos disponíveis pelo período necessário. Afinal, sem visibilidade suficiente, não há como diferenciar uma atividade legítima de uma ação suspeita.
Se esses dados não estiverem disponíveis, o hunting revela algo além da possível ameaça: uma lacuna de visibilidade. Por isso, a investigação também testa a capacidade de detecção do SOC e pode indicar ações concretas, como integrar novas fontes de dados, ajustar o logging, melhorar correlações ou ampliar a cobertura dos endpoints.
O melhor resultado de uma investigação pode ser uma detecção que ainda não existia.
Encontrar um comportamento suspeito é apenas uma parte do trabalho.
Depois disso, o que a equipe faz com a descoberta passa a ser ainda mais importante. Suponha que uma investigação identifique um padrão associado ao uso indevido de uma conta privilegiada.
Se o caso for simplesmente encerrado, o SOC encontrou uma ameaça. Por outro lado, se o padrão for documentado, transformado em uma analytics, testado contra os dados disponíveis e incorporado ao monitoramento, o SOC aumenta sua capacidade de detectar aquela ameaça novamente.
O MITRE ATT&CK mantém estratégias de detecção que organizam abordagens para identificar técnicas adversárias e relacioná-las a analytics específicos. Uma investigação não deveria desaparecer junto com o ticket.
Maturidade também aparece na qualidade das perguntas.
É comum avaliar um SOC por métricas como quantidade de alertas tratados, tempo médio de resposta ou número de incidentes encerrados.
Esses indicadores são importantes. No entanto, eles não contam toda a história.
Essas perguntas mostram algo que uma contagem de alertas não mostra: a capacidade de evolução da operação.
Um SOC pode processar milhares de alertas e repetir os mesmos erros durante meses. Da mesma forma, pode processar menos alertas, melhorar continuamente sua cobertura, reduzir falsos positivos e aumentar a capacidade de encontrar comportamentos que antes passavam despercebidos.
Portanto, quantidade de trabalho não é sinônimo de maturidade.
Tecnologia aumenta a capacidade. Contexto determina a qualidade da investigação.
A automação ajuda o SOC a lidar com volume. Além disso, a inteligência artificial pode acelerar correlações, análises e tarefas repetitivas.
Ainda assim, nenhuma dessas tecnologias elimina a necessidade de contexto.
O mesmo comportamento pode representar uma atividade legítima em uma empresa e uma ameaça em outra. Um administrador acessando um servidor crítico pode ser esperado. Em contrapartida, um usuário comum fazendo a mesma coisa pode exigir investigação.
Uma autenticação em horário incomum pode ser normal para uma equipe que trabalha em turnos. Porém, pode ser um sinal relevante quando associada a outras atividades incompatíveis com aquele perfil.
Por isso, um SOC precisa conhecer o ambiente que monitora.
Ativos críticos, identidades, privilégios, aplicações, fluxos de acesso, padrões de comportamento e fontes de telemetria fazem parte da investigação. Quanto mais contexto o SOC consegue reunir, menor é a dependência de um único evento para tomar uma decisão.
Responder rápido começa antes do incidente.
A maturidade de um SOC também aparece quando uma investigação precisa virar resposta. Não basta identificar uma ameaça: a equipe precisa saber quem acionar, quais ações executar e quais decisões dependem do negócio. Por isso, processos e responsabilidades precisam estar definidos antes da crise.
A versão atual do NIST SP 800-61, publicada em 2025, reforça a integração entre detecção, resposta e recuperação no gerenciamento de riscos. Confira o NIST SP 800-61 Rev. 3 Assim, em um SOC maduro, o incidente não termina com a contenção: o que funcionou, o que falhou e o que foi descoberto alimenta novas detecções, processos e investigações.
O tempo mostra o impacto dessa maturidade.
Existe uma razão objetiva para reduzir o tempo entre comprometimento, detecção e contenção.
Segundo o IBM Cost of a Data Breach Report 2025, o custo médio de uma violação foi de US$ 3,87 milhões para organizações que identificaram e contiveram o incidente em menos de 200 dias, contra US$ 5,01 milhões quando o ciclo ultrapassou 200 dias.
São US$ 1,14 milhão de diferença.
O tempo de resposta, portanto, não é apenas uma métrica operacional do SOC. Ele também pode representar impacto financeiro para a organização.
Quanto mais tempo uma ameaça permanece sem ser identificada, maior pode ser sua capacidade de acessar sistemas, obter privilégios, movimentar-se pelo ambiente e comprometer dados.
Por isso, maturidade precisa aparecer na capacidade de reduzir essa janela. Mas reduzir tempo não significa simplesmente trabalhar mais rápido. Significa encontrar melhor.
E encontrar melhor depende de cobertura de telemetria, qualidade das detecções, investigação, Threat Hunting, inteligência e processos de resposta.
Então, o que torna um SOC verdadeiramente maduro?
A maturidade de um SOC não está na quantidade de ferramentas nem no volume de alertas processados. Tampouco está em responder apenas quando uma ferramenta aponta que algo aconteceu.
Um SOC verdadeiramente maduro consegue fazer perguntas que ainda não foram respondidas, investigar comportamentos que ainda não geraram alertas e transformar cada descoberta em uma melhoria permanente para a operação.
Mais do que responder ao que já aconteceu, ele desenvolve a capacidade de procurar o que ainda não foi identificado. Quando encontra uma lacuna, transforma essa descoberta em uma nova capacidade de defesa.
Ele sabe onde enxerga e reconhece onde ainda não consegue enxergar. Além disso, sabe o que precisa investigar e como transformar o resultado dessa investigação em melhoria.
No fim, essa capacidade de aprender continuamente faz um SOC deixar de ser apenas uma estrutura de monitoramento e se tornar uma capacidade de defesa.
Na NovaRed, essa abordagem combina monitoramento, investigação, Threat Hunting, inteligência e resposta a incidentes para ampliar a capacidade de detecção e reduzir o tempo entre uma ameaça e a ação necessária.
Quer avaliar o nível de maturidade do SOC da sua organização? Fale com a NovaRed.
