Um SOC de verdade não se limita a avisar que algo suspeito aconteceu. Ele analisa o alerta, investiga as evidências, avalia o risco, conduz as ações sob sua responsabilidade e registra o que precisa acontecer em seguida.
A diferença aparece na rotina. Se o fornecedor abre um chamado com a mensagem “detectamos uma atividade suspeita, favor verificar”, a investigação continua nas mãos da sua equipe. Você recebeu um alerta, não necessariamente uma resposta.
Para avaliar a operação, não comece pela ferramenta ou pelo dashboard. Faça uma pergunta mais direta:
Quando uma ameaça é detectada, quem investiga, quem decide e quem age?
A resposta mostra se existe uma operação capaz de transformar sinais em decisões ou apenas uma camada de encaminhamento de notificações.
Alerta não é investigação
Um alerta é um sinal produzido por uma regra, ferramenta ou análise. Ele indica algo que merece atenção, mas ainda não explica necessariamente o que aconteceu, qual é o risco ou o que deve ser feito.
A investigação começa depois desse sinal. O analista reúne contexto, correlaciona evidências e verifica se há uma ameaça que exige resposta.
Um caso investigado deve responder:
- O que gerou o alerta?
- Quais evidências foram analisadas?
- Quais usuários, ativos ou aplicações estão envolvidos?
- A atividade é esperada, suspeita ou maliciosa?
- Qual é o possível impacto?
- Qual ação foi executada ou recomendada?
- Quem ficou responsável pelo próximo passo?
- O que permite considerar o caso encerrado?
Um chamado que apenas copia o alerta original transfere essas perguntas para o cliente. Um SOC demonstra valor quando reduz a incerteza e conduz o caso até uma decisão.
O SOC precisa conhecer o que protege
Não existe detecção relevante sem contexto. Um comportamento comum em um ambiente de testes pode representar um risco crítico quando ocorre em um sistema que processa dados sensíveis ou sustenta uma operação essencial.
Por isso, o SOC precisa compreender:
- quais ativos sustentam processos críticos;
- quais identidades possuem acessos privilegiados;
- quais sistemas concentram dados sensíveis;
- quais aplicações não podem ficar indisponíveis;
- quais ameaças são mais relevantes para o setor;
- quais obrigações afetam a operação;
- quais ações de resposta podem causar impacto no negócio.
Esse entendimento muda a forma como os casos são priorizados. A severidade apresentada pela ferramenta é uma informação técnica; a prioridade operacional também depende do ativo, do contexto e do possível impacto.
Um SOC que trata todos os alertas da mesma maneira pode gastar tempo com ruído enquanto um sinal realmente importante permanece na fila.
Ferramenta não é operação
SIEM, EDR, XDR e SOAR podem coletar dados, correlacionar eventos, enriquecer alertas e automatizar ações. Essas tecnologias apoiam a operação, mas não substituem prioridades, responsabilidades e critérios de decisão.
O SIEM, por exemplo, centraliza e analisa dados de diferentes fontes para apoiar detecções e investigações. Antes de escolher a plataforma, a empresa precisa definir o escopo e os casos de uso que pretende atender, como detalhamos no artigo Como escolher um SIEM.
Ter um SIEM, portanto, não significa ter um SOC. Da mesma forma, instalar um EDR não comprova que os alertas dos endpoints sejam investigados ou que exista autorização para conter uma ameaça.
Antes de contratar uma operação, não pergunte apenas quais ferramentas serão utilizadas. Pergunte o que a equipe consegue fazer com elas.
O que o SOC deve entregar
As entregas variam conforme o ambiente e as responsabilidades definidas, mas uma operação precisa explicar o que faz, como comprova o trabalho e onde termina sua atuação.
| Entrega | Como comprovar | Sinal de atenção |
|---|---|---|
| Triagem | Registro da classificação, prioridade e justificativa | Todos os alertas são encaminhados ao cliente |
| Investigação | Evidências correlacionadas, contexto, hipótese e conclusão | O chamado apenas reproduz a notificação da ferramenta |
| Resposta coordenada | Ação executada ou orientação clara, com responsável definido | Ninguém sabe quem deve agir |
| Playbooks | Procedimentos documentados para os casos cobertos | O tratamento depende da memória do analista |
| Escalonamento | Critérios para envolver especialistas e responsáveis | O caso muda de equipe sem contexto |
| Visibilidade | Acesso aos casos, decisões, pendências e responsáveis | O cliente recebe apenas um total mensal de alertas |
| Melhoria contínua | Histórico de ajustes em detecções e procedimentos | O mesmo falso positivo reaparece indefinidamente |
| Continuidade | Documentação e condições claras para uma transição | Regras e conhecimento ficam presos ao fornecedor |
Nenhuma dessas entregas deve existir apenas na apresentação institucional. O fornecedor precisa mostrar como elas aparecem nos atendimentos, nos registros e no acompanhamento da operação.
Para entender como esse modelo funciona quando parte das atividades fica com um parceiro especializado, veja também Managed SOC: benefícios para a operação de segurança.
Como um caso deve ser tratado
O fluxo pode variar conforme o ambiente, mas um caso de segurança normalmente percorre seis etapas.
Detecção
Uma regra, um comportamento ou uma análise identifica uma atividade que merece atenção. O SOC registra a origem do sinal e os dados disponíveis.
Triagem
O analista verifica o contexto inicial, estima a prioridade e decide se o alerta pode ser encerrado, se exige investigação ou se precisa de escalonamento imediato.
Investigação
A equipe correlaciona informações de diferentes fontes para entender o que ocorreu, quais ativos estão envolvidos e qual pode ser o alcance da ameaça.
Decisão
Com base nas evidências, o SOC define a ação prevista no procedimento. Quando a decisão está fora de sua alçada, aciona o responsável com o contexto necessário.
Resposta
A operação executa ou coordena medidas como revogar uma sessão, bloquear uma conta, isolar um equipamento ou aplicar outra forma de contenção autorizada.
Fechamento e melhoria
O caso é encerrado com evidências, decisões, ações e pendências documentadas. O aprendizado deve alimentar melhorias nas detecções, nos procedimentos e na cobertura.
Seu SOC investiga ou encaminha?
Se sua empresa já possui um SOC, o ponto principal é descobrir o que acontece entre o alerta ser identificado e o seu time ser acionado.
O Diagnóstico de SOC da DataRunk ajuda a avaliar cobertura, tratamento de alertas, investigação, resposta, responsabilidades, SLAs e visibilidade. A leitura pode ser usada antes de renovar uma operação, comparar fornecedores ou definir os próximos passos de evolução.
Peça um caso do início ao fim
Uma forma prática de avaliar o fornecedor é pedir um caso anonimizado ou uma demonstração representativa do atendimento.
O material deve mostrar:
- O que gerou o alerta.
- Quais fontes foram consultadas.
- Quais evidências sustentaram a conclusão.
- Como a prioridade foi definida.
- Qual ação foi executada ou recomendada.
- Quem participou da decisão.
- O que permitiu encerrar o caso.
- O que foi melhorado depois.
Restrições de confidencialidade podem impedir a apresentação de um incidente real. Nesse caso, peça uma demonstração fictícia e confirme como você terá acesso aos registros da sua própria operação.
Exemplo de caso documentado
O exemplo abaixo é ilustrativo. Ele não representa um cliente, incidente ou resultado real.
| Campo | Exemplo |
|---|---|
| Detecção | Acesso incomum a uma conta corporativa |
| Contexto | Autenticação originada de dispositivo e localização não reconhecidos |
| Investigação | Correlação entre autenticações, sessões abertas e atividades posteriores |
| Conclusão | Indícios consistentes de comprometimento da conta |
| Decisão | Aplicação do playbook aprovado para comprometimento de identidade |
| Contenção | Revogação das sessões e bloqueio temporário conforme as alçadas |
| Responsabilidade do cliente | Validação do impacto e condução das etapas internas de recuperação |
| Fechamento | Registro das evidências, ações, validações e pendências |
| Melhoria | Revisão da regra e avaliação da necessidade de dados adicionais |
O valor desse registro está na rastreabilidade. Outra pessoa precisa conseguir entender o que aconteceu, por que uma decisão foi tomada e o que ainda precisa ser feito.
Quem investiga, decide e age
Um SOC terceirizado não precisa executar sozinho todas as ações. A operação pode dividir responsabilidades com a equipe de segurança, infraestrutura, identidades, aplicações e gestores do negócio.
O problema não é compartilhar responsabilidades. O problema é descobrir quem deveria agir somente depois que o incidente começou.
Para cada ação relevante, defina:
- quem investiga;
- quem pode decidir;
- quem executa;
- quando é necessária aprovação;
- quem será acionado fora do horário comercial;
- o que acontece se o responsável não responder;
- como a decisão será documentada.
Isolar o computador de um colaborador e interromper um servidor crítico têm impactos diferentes. As alçadas precisam considerar o risco da ameaça e o risco causado pela própria contenção.
Também é importante separar contenção de recuperação. Interromper uma atividade maliciosa não significa que o sistema foi restaurado, que a causa foi eliminada ou que todas as consequências já foram avaliadas.
N1, N2 e N3 não bastam
Muitos SOCs dividem a equipe em N1, N2 e N3. Em geral, o N1 realiza a triagem, o N2 conduz investigações mais aprofundadas e o N3 atua em situações complexas ou especializadas.
Essa organização varia entre operações. Um Managed SOC, por exemplo, pode distribuir monitoramento, investigação, resposta avançada e acompanhamento entre diferentes níveis e funções.
Em vez de perguntar apenas se existem N1, N2 e N3, confirme:
- quais atividades cada função executa;
- quais casos são escalados;
- quando um especialista é acionado;
- qual é o prazo de acionamento;
- quais competências estão disponíveis em cada horário;
- como ocorre a transferência de contexto entre os níveis.
Os nomes dos níveis não comprovam, sozinhos, a capacidade da operação.
O que significa SOC 24×7
Cobertura 24×7 pode assumir significados diferentes. Em uma operação, pode indicar monitoramento contínuo; em outra, pode incluir investigação e resposta durante todo o período.
Antes de contratar ou renovar, verifique:
- há analistas trabalhando continuamente ou apenas um plantonista?
- os alertas são analisados antes do acionamento do cliente?
- quais competências estão disponíveis 24×7?
- em quanto tempo um especialista pode ser acionado?
- quais ações podem ser executadas fora do horário comercial?
- quem precisa responder pelo lado do cliente?
- o que acontece quando ninguém do cliente está disponível?
Uma ligação automática para o plantonista pode fazer parte do fluxo, mas não substitui a análise. O ponto é descobrir o que aconteceu entre o alerta ser gerado e o telefone tocar.
Playbook não é só documento
O playbook descreve como determinada situação deve ser tratada. Ele orienta as evidências a consultar, as decisões possíveis, os responsáveis e as ações autorizadas.
Um playbook útil define:
- o que inicia o fluxo;
- quais dados devem ser consultados;
- como avaliar a prioridade;
- quais ações estão disponíveis;
- quem pode aprová-las;
- quando o caso deve ser escalado;
- quais condições permitem o fechamento;
- quais informações precisam ser documentadas.
Parte desse fluxo pode ser automatizada. O SOAR pode enriquecer alertas, coletar contexto e executar tarefas previsíveis.
Automatizar um processo mal definido, porém, apenas acelera a inconsistência. Primeiro vêm as decisões, os limites e as responsabilidades; depois, a automação.
Quais métricas importam
O número de alertas indica volume, mas não comprova a qualidade da investigação. Um SOC também precisa demonstrar se detecta ameaças relevantes, responde no prazo e melhora a operação.
| Métrica | O que precisa ser esclarecido |
|---|---|
| MTTD | Qual ocorrência inicia a contagem até a detecção |
| MTTA | Se a contagem termina na atribuição ou no início da análise |
| MTTR | Se significa resposta, contenção, resolução ou recuperação |
| Falsos positivos | Como são classificados e quais melhorias resultam da análise |
| Cobertura | Quais ativos, fontes, técnicas ou riscos estão contemplados |
| Escalonamento | Quanto tempo leva para envolver o especialista necessário |
| Automação | Quais tarefas são automatizadas e qual resultado produzem |
Não aceite uma sigla sem definição. “MTTR”, por exemplo, pode representar tempo médio de resposta ou de resolução. A resolução pode depender de decisões e equipes que estão fora do controle do SOC.
Também é importante diferenciar:
- Indicador: medida usada para acompanhar o desempenho.
- Objetivo: resultado que a operação pretende alcançar.
- SLA: compromisso de serviço formalizado entre as partes.
Uma média operacional não equivale automaticamente a um prazo para cada incidente.
Como saber se o SOC evolui
Um SOC consistente não repete indefinidamente os mesmos problemas. Ele utiliza o que aprende nos atendimentos para melhorar a cobertura e tornar a resposta mais eficiente.
Na reunião de acompanhamento, pergunte:
- Quais alertas estão gerando mais ruído?
- Quais falsos positivos foram reduzidos?
- Quais fontes críticas continuam sem cobertura?
- Quais casos ficaram sem conclusão por falta de dados?
- Quais ações foram atrasadas por falta de autorização?
- Quais playbooks foram revisados?
- Quais detecções foram ajustadas?
- Quais lacunas continuam abertas?
- Quem é responsável por cada melhoria?
Reduzir o número de alertas não é, isoladamente, sinal de evolução. Essa redução precisa vir acompanhada de relevância, cobertura e capacidade de resposta.
Se o problema for mais amplo do que o tratamento dos alertas, vale avaliar também a maturidade do SOC, considerando a relação entre negócio, pessoas, processos, tecnologia e serviços.
O que precisa estar claro
O nome “SOC” não esclarece automaticamente todas as capacidades da operação. Por isso, a empresa precisa confirmar o que será realizado e quais equipes participarão de cada etapa.
Verifique a cobertura de:
- monitoramento e triagem;
- investigação;
- contenção;
- resposta avançada;
- threat hunting;
- inteligência de ameaças;
- engenharia de detecção;
- criação e revisão de casos de uso;
- integrações com novas fontes;
- recuperação de sistemas;
- produção de evidências para auditoria.
Operar uma detecção existente, ajustar seu comportamento e desenvolver uma nova integração são trabalhos diferentes. Essa separação precisa estar clara para que não existam lacunas durante um incidente.
Como comparar operações
Duas ofertas chamadas “SOC 24×7” podem entregar capacidades distintas. A comparação precisa considerar os mesmos critérios operacionais.
| Dimensão | O que verificar |
|---|---|
| Ambiente | Ativos, aplicações, identidades e processos críticos |
| Fontes | Logs, endpoints, nuvem, rede, aplicações e integrações |
| Cobertura | Horários de monitoramento, investigação e resposta |
| Pessoas | Competências disponíveis e acionamento de especialistas |
| Processos | Playbooks, escalonamentos e responsabilidades |
| Tecnologia | Plataformas, integrações, acessos e limitações |
| Dados | Retenção, consulta e disponibilidade do histórico |
| Evolução | Ajustes, novas detecções e melhoria contínua |
| Continuidade | Documentação, direitos de uso e transição |
A comparação deve partir do que a operação consegue detectar, investigar, responder e melhorar — não apenas da ferramenta apresentada.
Como evitar dependência
A operação deve prever o que acontece se a empresa mudar de parceiro ou internalizar parte das atividades.
Antes de iniciar, esclareça:
- quem poderá utilizar as regras desenvolvidas;
- onde os playbooks serão documentados;
- como os registros poderão ser consultados;
- quais dados poderão ser exportados;
- quem terá os acessos necessários;
- como ocorrerá a transferência de conhecimento;
- quais dependências técnicas precisam ser consideradas.
Receber arquivos não garante uma transição simples. Regras, integrações e automações podem depender da arquitetura da plataforma utilizada.
O objetivo não é apenas obter documentos. É preservar conhecimento e reduzir o risco de interrupção da operação.
Caso a mudança também envolva a plataforma, consulte o Guia da migração de SIEM para entender os cuidados de planejamento, dados e continuidade.
Quando preparar o ambiente
A ausência de SIEM não impede automaticamente a implantação de uma operação de SOC. Diferentes tecnologias e fontes podem fornecer a telemetria necessária.
O ponto central é saber se há visibilidade suficiente sobre os riscos prioritários e se existe um caminho viável de resposta.
Pode ser necessário preparar o ambiente antes — ou incluir essa preparação no projeto — quando:
- os ativos críticos ainda não foram identificados;
- não há fontes suficientes para investigar os principais riscos;
- ninguém está autorizado a executar ações;
- os responsáveis internos não estão definidos;
- as tecnologias existentes não estão configuradas;
- as prioridades de segurança ainda não estão claras.
Nesse cenário, o diagnóstico deve produzir prioridades e um plano de evolução, não apenas recomendar outra ferramenta.
Checklist para avaliar seu SOC
Verifique se a sua operação responde claramente:
- Quais riscos e ativos orientam as prioridades?
- Quais fontes estão realmente cobertas?
- O que acontece depois que um alerta é gerado?
- Quem realiza a investigação?
- Quais evidências são entregues?
- Quais ações o SOC pode executar?
- Quais ações precisam de autorização?
- Quem responde pelo lado da empresa?
- O que está disponível 24×7?
- Quando os especialistas são acionados?
- Quais métricas são acompanhadas?
- Como as detecções são melhoradas?
- Como as responsabilidades ficam registradas?
- Como o conhecimento da operação é preservado?
Se as respostas forem vagas, a operação também tende a ser.
Perguntas frequentes
Um serviço que só repassa alertas pode ser considerado SOC?
O nome comercial não comprova a capacidade da operação. Se o fornecedor encaminha o alerta original sem contexto, análise ou condução do próximo passo, ainda falta esclarecer quem fará a investigação e a resposta.
Todo alerta precisa virar incidente?
Não. A triagem existe para avaliar o sinal e decidir se ele pode ser encerrado, se exige investigação ou se representa um incidente que precisa de resposta.
Um SOC precisa executar a contenção?
Depende das responsabilidades e alçadas definidas. O SOC pode executar ações previamente autorizadas ou coordenar a resposta com as equipes responsáveis.
Todo SOC precisa funcionar 24×7?
A cobertura deve corresponder aos riscos e às necessidades da empresa. Quando a operação é apresentada como 24×7, confirme quais atividades e competências estão disponíveis continuamente.
Ter um SIEM significa ter um SOC?
Não. O SIEM organiza e analisa dados para apoiar detecção e investigação. O SOC inclui equipe, processos, responsabilidades e capacidade de transformar sinais em decisões.
Como demonstrar o valor do SOC?
Apresente casos relevantes, riscos identificados, ações executadas, cobertura alcançada, compromissos cumpridos e melhorias realizadas. O número total de alertas, sozinho, não demonstra redução de risco.
Descubra o que acontece depois do alerta
O verdadeiro teste de um SOC não está na quantidade de telas, siglas ou notificações. Está na capacidade de compreender o ambiente, investigar os sinais relevantes e conduzir uma resposta compatível com o risco.
Se você quer identificar o que está claro, o que ainda depende da sua equipe e o que precisa ser validado com o fornecedor, faça o diagnóstico da sua operação.
O diagnóstico oferece uma leitura inicial sobre cobertura, investigação, resposta, responsabilidades e transparência. O resultado não substitui uma avaliação técnica, contratual, jurídica ou regulatória.
