Como avaliar um SOC gerenciado: 10 critérios para comparar fornecedores

Para avaliar um SOC gerenciado, não basta comparar preço, ferramentas e cobertura 24×7. É necessário entender o que acontece depois que um alerta é gerado: quem faz a triagem, como as evidências são enriquecidas, quem investiga, quais ações de contenção podem ser executadas e como as responsabilidades são divididas entre o fornecedor e o cliente.

Um serviço que apenas encaminha notificações não oferece a mesma capacidade operacional de um SOC que valida sinais, correlaciona evidências, investiga incidentes e participa da resposta. A comparação entre fornecedores deve partir dessas atividades concretas — e não apenas das tecnologias apresentadas na proposta.

Essa distinção também aparece nas recomendações do NIST SP 800-61r3 sobre resposta a incidentes. O documento destaca que detectar é apenas uma parte do processo: uma operação preparada precisa administrar, priorizar, conter, erradicar e se recuperar dos incidentes, além de documentar responsabilidades, comunicações e autoridades para agir.

Neste artigo, mostramos 10 critérios para avaliar um SOC gerenciado, as perguntas que devem ser feitas aos fornecedores e como utilizar uma matriz RACI para evitar lacunas durante um incidente.

O que um SOC gerenciado deve fazer?

Um SOC gerenciado é uma operação contínua de segurança responsável por monitorar o ambiente, analisar sinais, investigar incidentes e apoiar ou executar ações de resposta conforme o escopo contratado.

Na prática, uma operação pode envolver:

• Monitoramento contínuo dos eventos e alertas gerados pelo SIEM.
• Triagem e validação dos alertas.
• Enriquecimento com informações sobre ativos, identidades, geolocalização e inteligência de ameaças.
• Correlação de evidências provenientes de diferentes fontes.
• Classificação da criticidade.
• Criação e documentação do incidente.
• Investigação técnica aprofundada.
• Escalonamento para especialistas.
• Execução de ações de contenção previstas em playbooks.
• Mobilização de uma sala de crise quando necessário.
• Threat hunting e evolução das detecções.
• Relatórios operacionais e executivos.

Esse fluxo evidencia uma diferença importante: monitorar é apenas uma parte da operação. O valor do SOC aparece quando o sinal é transformado em investigação, decisão e resposta.

Alertar não é o mesmo que responder

Em conversas com compradores de serviços de segurança, uma crítica recorrente é o chamado “SOC fofoqueiro”: a operação detecta algo, abre um chamado e transfere todo o trabalho para o cliente.

O problema não é comunicar o incidente. A comunicação é necessária. O problema aparece quando o fornecedor não valida o alerta, não reúne evidências, não apresenta uma hipótese investigativa e não contribui para a decisão.

Por isso, uma das primeiras perguntas ao fornecedor deve ser:

O que sua equipe faz entre o recebimento do alerta e o acionamento do nosso time?

A resposta deve apresentar atividades, responsabilidades e evidências. Expressões como “monitoramento avançado”, “inteligência artificial” ou “resposta proativa” têm pouco valor quando não vêm acompanhadas de um fluxo operacional claro.

10 critérios para avaliar um SOC gerenciado

1. Escopo e cobertura do ambiente

O primeiro critério é verificar o que realmente estará sob monitoramento. Uma cobertura 24×7 não significa, necessariamente, que todo o ambiente estará sendo observado.

O escopo deve identificar:

• Ativos, aplicações e ambientes incluídos.
• Fontes de dados integradas ao SIEM.
• Identidades e contas monitoradas.
• Endpoints, serviços em nuvem e dispositivos de rede cobertos.
• Aplicações críticas e processos de negócio contemplados.
• Ambientes, filiais ou sistemas fora do escopo.

Também é necessário verificar quem será responsável por disponibilizar as fontes, manter os dados atualizados e corrigir problemas de coleta. Sem telemetria confiável, o SOC pode operar continuamente e, ainda assim, não enxergar partes importantes do ambiente.

Pergunta ao fornecedor: quais fontes de dados são necessárias para os casos de uso previstos e quem responde por sua disponibilidade?

2. Triagem e enriquecimento dos alertas

A triagem determina se um alerta é falso positivo, atividade legítima ou possível incidente. Essa etapa deve considerar mais do que o dado original produzido pelo SIEM.

Uma triagem consistente pode enriquecer o alerta com:

• Criticidade do ativo envolvido.
• Identidade e privilégios do usuário.
• Histórico de comportamento.
• Geolocalização.
• Indicadores de comprometimento.
• Informações de inteligência de ameaças.
• Eventos relacionados em outras fontes.

Esse enriquecimento ajuda a reduzir falsos positivos e evita que o cliente receba um alerta sem contexto suficiente para decidir.

Pergunta ao fornecedor: quais evidências são adicionadas ao alerta antes que o cliente seja acionado?

3. Capacidade de investigação

Quando a triagem identifica uma ameaça potencial, o SOC deve ter capacidade de aprofundar a análise. Isso exige correlação de múltiplas fontes, construção de uma linha do tempo e formulação de hipóteses investigativas.

Segundo o NIST SP 800-61r3, os responsáveis pela resposta devem verificar se o incidente ocorreu, coletar e analisar dados e evidências, priorizar as atividades e tomar medidas para limitar os danos, identificar as causas e restaurar as operações.

Uma investigação bem documentada deve mostrar:

• Como o incidente começou.
• Quais ativos e identidades foram envolvidos.
• Quais evidências confirmam ou enfraquecem a hipótese.
• Qual pode ser o impacto técnico e operacional.
• Quais ações foram realizadas.
• Quais decisões ainda dependem do cliente.

Pergunta ao fornecedor: o que será entregue além do alerta — uma notificação, uma hipótese investigativa ou um incidente documentado?

4. Escalonamento entre N1, N2 e N3

A proposta deve explicar como os diferentes níveis de atendimento participam da operação. Os nomes podem variar entre fornecedores, mas as responsabilidades precisam estar claras.

• N1: monitora, valida, enriquece e classifica os alertas, registra o incidente e executa ações previamente definidas.
• N2: realiza investigação aprofundada, correlaciona diferentes fontes, analisa causas e coordena ações de contenção.
• N3: conduz incidentes complexos ou críticos, estrutura hipóteses avançadas e atua como autoridade técnica da investigação.

O comprador também deve verificar quais níveis estão incluídos no contrato. Algumas propostas citam N2, N3, CERT ou threat hunting, mas tratam essas capacidades como serviços adicionais.

Pergunta ao fornecedor: quais critérios determinam o escalonamento e quais níveis estão efetivamente incluídos no valor contratado?

5. Resposta e contenção

Um dos pontos mais importantes da avaliação é entender o que o SOC pode fazer durante o incidente. As ações podem incluir:

• Isolar um endpoint.
• Bloquear um indicador malicioso.
• Revogar uma credencial comprometida.
• Suspender uma conta.
• Alterar uma regra de segurança.
• Acionar uma equipe de crise.
• Recomendar contenção ou erradicação.

Nem toda ação deve ser executada automaticamente. Intervenções que podem afetar a continuidade do negócio precisam de alçadas, critérios e autorizações previamente definidos.

O NIST recomenda que as políticas de resposta estabeleçam quais funções têm autoridade para desconectar, bloquear ou interromper ativos tecnológicos. Quando existe um fornecedor terceirizado, o contrato também deve determinar os limites de sua atuação e as decisões que ele pode executar em nome da organização.

Por isso, a resposta do fornecedor não deve ser apenas “sim, fazemos contenção”. A organização precisa saber em quais situações, sobre quais ativos, com qual autorização e por meio de qual playbook.

Pergunta ao fornecedor: quais ações podem ser executadas diretamente, quais exigem aprovação e quais permanecem sob responsabilidade do cliente?

6. Matriz RACI

A matriz RACI define quem executa, quem responde pelo resultado, quem deve ser consultado e quem precisa ser informado em cada atividade.

• R — Responsible: executa a atividade.
• A — Accountable: responde pelo resultado.
• C — Consulted: participa da decisão ou fornece informações.
• I — Informed: precisa ser comunicado.

Em um SOC cogerenciado, a RACI evita que fornecedor e cliente presumam que a outra parte tomará uma ação. O modelo abaixo apresenta uma divisão ilustrativa baseada em atividades reais de uma operação de SOC:

Essa matriz não deve ser tratada como um modelo universal. Ela precisa ser adaptada aos ativos, aos riscos, à estrutura interna e às exigências regulatórias de cada organização.

O NIST classifica essa relação como um modelo de responsabilidade compartilhada: parte das atividades pode ser transferida ao provedor, mas as responsabilidades, os fluxos de informação, a coordenação e a autoridade para agir devem estar claramente definidos no contrato.

Pergunta ao fornecedor: a proposta inclui uma matriz RACI por atividade ou caso de uso?

7. Playbooks, runbooks e alçadas

O playbook descreve como responder a um cenário específico. Ele pode definir as etapas de triagem, os dados que precisam ser consultados, as pessoas que devem ser acionadas e as ações permitidas.

Exemplos incluem:

• Comprometimento de credenciais.
• Execução de malware.
• Movimentação lateral.
• Exfiltração de dados.
• Phishing.
• Ransomware.
• Comportamento anômalo de usuário privilegiado.

Os playbooks transformam uma intenção genérica de resposta em passos operacionais. O NIST os define como procedimentos com tarefas acionáveis para orientar as pessoas diante de situações específicas.

A CISA também disponibiliza playbooks de resposta que organizam procedimentos para identificar, coordenar, remediar, recuperar e acompanhar as medidas adotadas durante um incidente.

Antes da contratação, verifique:

• Quem cria e atualiza os playbooks.
• Quem aprova cada ação.
• Como os playbooks são testados.
• Como as exceções são tratadas.
• Como os achados de incidentes atualizam os procedimentos.
• Quem fica com a documentação ao término do contrato.

Pergunta ao fornecedor: podemos analisar um exemplo anonimizado de playbook e entender como ele é aprovado, testado e atualizado?

8. SLAs que medem etapas diferentes

O contrato deve diferenciar reconhecimento, resposta e resolução. Colocar todas essas etapas sob a sigla “MTTR” gera ambiguidade e dificulta a cobrança.

O tempo de resolução nem sempre está totalmente sob controle do SOC. Ele pode depender da disponibilidade do cliente, de acesso ao ativo, de uma janela de mudança, de um terceiro responsável ou de uma autorização executiva.

Por isso, o contrato deve informar:

• Qual evento inicia a contagem.
• Qual evento encerra a contagem.
• Quais severidades possuem metas diferentes.
• Quando o relógio pode ser suspenso.
• Quais dependências ficam sob responsabilidade do cliente.
• Como os resultados serão demonstrados.

Pergunta ao fornecedor: o MTTR da proposta representa o início da resposta ou a resolução completa do incidente?

9. Engenharia de detecção, automação e threat hunting

Operar alertas existentes não é a mesma coisa que criar e evoluir detecções. A proposta deve esclarecer se estão incluídas atividades como:

• Criação de novos casos de uso.
• Ajuste de thresholds.
• Redução de falsos positivos.
• Mapeamento de cobertura com o MITRE ATT&CK.
• Construção de playbooks de automação.
• Integração com APIs e outras ferramentas.
• Campanhas de threat hunting.
• Conversão dos achados de hunting em novas regras.

O MITRE ATT&CK pode apoiar o desenvolvimento de análises, a avaliação da capacidade de detecção e decisões de engenharia. Porém, a própria MITRE alerta que o framework não deve ser tratado como um checklist de cobertura total: cada organização deve priorizar as técnicas mais relevantes para seu perfil de ameaça.

Também é importante verificar se engenharia de detecção, automação e hunting fazem parte da mensalidade ou se são contratados como serviços especializados separados.

Pergunta ao fornecedor: quem cria e melhora as detecções quando o ambiente, as ameaças ou o perfil de risco mudam?

10. Transparência operacional e governança

O cliente precisa ter visibilidade do que o SOC está fazendo. Isso não significa acompanhar cada alerta em tempo real, mas deve ser possível acessar informações suficientes para avaliar a qualidade da operação.

Procure por entregas como:

• Fila de casos e incidentes.
• Histórico das ações executadas.
• Linha do tempo dos incidentes.
• Indicadores de reconhecimento e resposta.
• Taxa de falsos positivos.
• Incidentes por criticidade.
• Casos de uso ajustados ou criados.
• Campanhas de threat hunting realizadas.
• Relatório mensal de indicadores.
• Revisão executiva periódica.

Também é necessário diferenciar indicadores de volume de indicadores de resultado. Muitos alertas tratados não significam, por si só, que o ambiente está mais protegido.

O NIST recomenda avaliar periodicamente o desempenho do programa de resposta, identificar deficiências e utilizar os aprendizados obtidos em incidentes, testes e exercícios para melhorar processos, políticas e controles.

Pergunta ao fornecedor: quais evidências mostram que a operação está evoluindo e não apenas processando alertas?

Case anonimizado: quando a evolução do SOC amplia a visibilidade do negócio

O caso a seguir apresenta dados internos de um projeto conduzido pela DataRunk para uma instituição financeira brasileira. O nome da organização, as pessoas envolvidas, a plataforma utilizada e detalhes que permitiriam sua identificação foram omitidos.

Em um período de aproximadamente sete meses, a instituição evoluiu uma operação inicialmente concentrada em SOC e monitoramento antifraude para uma estrutura mais integrada, capaz de combinar dados de cibersegurança, aplicações e processos de negócio.

O ponto de partida era uma cobertura limitada, com cinco detecções de antifraude. Ao final do período analisado, a operação possuía mais de 50 detecções, playbooks e processos de gerenciamento associados ao ambiente.

“Saímos de cinco detecções de antifraude para mais de 50, somando os playbooks e os processos de gerenciamento construídos ao longo do projeto”, relata o tech lead da DataRunk responsável pela operação.

Segundo os registros internos do projeto, essa evolução também gerou:

• Redução superior a 10% nos falsos positivos.
• Ampliação relevante do número de detecções.
• Expansão superior a quatro vezes na área de cobertura monitorada.

Os resultados não vieram apenas da ativação de novas regras. O trabalho envolveu evolução dos casos de uso, revisão de processos, construção de playbooks e integração entre equipes que anteriormente consumiam os dados de forma separada.

Com o amadurecimento da operação, o ambiente passou a ser utilizado não apenas pelas equipes de cibersegurança e antifraude, mas também por profissionais de observabilidade e aplicações. Dezenas de usuários passaram a consumir visões operacionais e gerenciais construídas sobre a mesma base de dados.

Essa integração aproximou informações técnicas do contexto do negócio. Um evento deixou de ser analisado apenas como um comportamento anômalo de infraestrutura e passou a ser correlacionado com identidades, aplicações e possíveis impactos sobre serviços financeiros.

O projeto também avançou em direção a uma visão de Cyber Fusion Center: não como uma nova ferramenta, mas como uma forma de conectar equipes, dados e decisões que normalmente operam em silos.

Na prática, isso permitiu que as áreas técnicas tivessem uma visão mais ampla sobre a saúde do ambiente digital, enquanto a gestão passou a receber métricas capazes de apoiar decisões sobre continuidade, prioridades de segurança e novos investimentos.

O aprendizado do case é que a maturidade de um SOC não cresce apenas com o número de alertas monitorados. Ela cresce quando novas detecções são acompanhadas por responsabilidades claras, playbooks, redução de falsos positivos, integração entre áreas e indicadores que façam sentido para a operação e para o negócio.

Como comparar propostas de SOC na mesma base

Antes de comparar preços, normalize o escopo das propostas. Uma pode incluir investigação N2, resposta avançada e threat hunting; outra pode cobrir apenas triagem e escalonamento.

Essa normalização evita comparar uma operação completa de investigação e resposta com um serviço limitado ao monitoramento e encaminhamento de alertas.

Como validar a operação antes da contratação

Documentos e apresentações ajudam, mas não mostram sozinhos como o fornecedor atuará sob pressão. Uma forma mais realista de avaliação é conduzir um workshop com um cenário controlado.

1. Escolha um cenário relevante

O cenário deve representar um risco real para a organização, como comprometimento de uma conta privilegiada, malware em endpoint crítico, comportamento anômalo de identidade ou acesso suspeito a uma aplicação sensível.

2. Apresente as evidências iniciais

Forneça um conjunto fictício ou anonimizado de alertas, eventos e informações sobre os ativos. Evite antecipar toda a resposta esperada.

3. Peça ao fornecedor que conduza o fluxo

Durante o exercício, avalie se a equipe consegue:

• Classificar o alerta.
• Solicitar as informações corretas.
• Correlacionar diferentes evidências.
• Construir e revisar hipóteses.
• Determinar a criticidade.
• Escolher o momento do escalonamento.
• Recomendar ou executar contenção.
• Comunicar a situação ao time técnico e à gestão.
• Registrar as decisões tomadas.

4. Analise o entregável

Ao final, solicite um registro com:

• Linha do tempo.
• Evidências correlacionadas.
• Hipótese investigativa.
• Classificação do incidente.
• Ações recomendadas ou executadas.
• Responsáveis pelas próximas etapas.
• Oportunidades de melhoria da detecção.

A CISA recomenda exercícios de mesa baseados em cenários para testar os papéis das pessoas, os fluxos de comunicação e a capacidade de resposta antes de um incidente real. O exercício também deve gerar uma retrospectiva e atualizações dos processos identificados como insuficientes.

Checklist de perguntas para fornecedores

1. O que acontece entre a criação do alerta e o acionamento do cliente?
2. Quais evidências são adicionadas durante a triagem?
3. O fornecedor entrega uma hipótese investigativa?
4. Quais atividades são realizadas por N1, N2 e N3?
5. Quando a equipe de crise é mobilizada?
6. Quais ações de contenção podem ser executadas diretamente?
7. Quais ações exigem autorização?
8. A proposta inclui uma matriz RACI?
9. Existem playbooks aprovados para os principais cenários?
10. Como são definidos os SLAs de reconhecimento e resposta?
11. O tempo de resolução considera dependências do cliente?
12. Engenharia de detecção está incluída?
13. Threat hunting está incluído? Com qual frequência?
14. Como os falsos positivos são identificados e reduzidos?
15. Quais dashboards e relatórios serão entregues?
16. Como a operação apoia auditorias e conformidade?
17. Quem é responsável pela disponibilidade das fontes de dados?
18. Quem fica com regras, casos de uso e playbooks?
19. Como ocorre a transição para outro fornecedor?
20. Quais atividades importantes estão fora do escopo?

O principal critério: transformar alerta em ação

A escolha de um SOC gerenciado não deve ser orientada pela quantidade de tecnologias apresentadas nem pelo volume de alertas que o fornecedor afirma processar.

O critério central é a capacidade de transformar um sinal em uma resposta operacional: validar, enriquecer, investigar, decidir, conter, documentar e aprender com o incidente.

Isso exige mais do que uma plataforma. Exige pessoas com responsabilidades claras, processos testados, playbooks atualizados, integrações confiáveis e uma relação transparente entre fornecedor e cliente.

O DataRunk SOC Gerenciado pode ser estruturado para operar em conjunto com o time interno, com atividades e responsabilidades definidas conforme o ambiente, os casos de uso e as alçadas de resposta. A operação reúne monitoramento, triagem, investigação e resposta, enquanto capacidades como engenharia de detecção, automação e threat hunting são dimensionadas de acordo com o estágio de maturidade e as necessidades da organização.

Quando a empresa ainda não possui clareza sobre essas necessidades, o ponto de partida pode ser um diagnóstico de maturidade de SOC. Esse processo ajuda a identificar lacunas de pessoas, processos e tecnologia antes da contratação ou evolução da operação.

Quer comparar fornecedores usando critérios operacionais? Conheça o DataRunk SOC Gerenciado e converse com um especialista sobre escopo, responsabilidades, investigação, resposta e evolução da cobertura.

Conhecer o DataRunk SOC Gerenciado

Perguntas frequentes

Como saber se um SOC apenas encaminha alertas?

Verifique o que o fornecedor entrega antes de acionar o cliente. Um serviço limitado tende a repassar a notificação original. Um SOC com capacidade investigativa valida o sinal, reúne contexto, correlaciona evidências, classifica o incidente e indica as próximas ações.

Um SOC gerenciado pode bloquear usuários ou máquinas?

Pode, desde que essa responsabilidade esteja prevista no escopo, na matriz RACI e nos playbooks aprovados. Ações com impacto operacional devem ter critérios, alçadas e autorizações definidos antes do incidente.

Threat hunting está incluído em todo SOC?

Não necessariamente. Alguns fornecedores incluem campanhas periódicas no serviço; outros tratam threat hunting como escopo adicional. A proposta deve informar frequência, fontes utilizadas, método e entregáveis.

Engenharia de detecção faz parte do SOC?

Nem sempre. Operação de SOC e engenharia de detecção são capacidades diferentes. A primeira trata alertas e incidentes; a segunda cria, testa, ajusta e documenta regras e casos de uso. O contrato deve indicar se ambas estão incluídas.

Qual é a função da matriz RACI em um SOC?

A matriz RACI esclarece quem executa, quem responde pelo resultado, quem é consultado e quem deve ser informado. Ela reduz dúvidas durante o incidente e evita que uma ação deixe de ser realizada porque fornecedor e cliente esperavam que a outra parte assumisse a responsabilidade.

Quais SLAs devem ser cobrados?

Os SLAs devem separar, pelo menos, o tempo de reconhecimento, o início da resposta e o escalonamento. Quando houver uma meta de resolução, o contrato precisa explicitar quais dependências do cliente ou de terceiros afetam o prazo.

Quem deve ficar com os playbooks e casos de uso?

A propriedade e a portabilidade devem estar definidas no contrato. O cliente deve conseguir acessar e exportar regras, playbooks, documentação, histórico e lógica de detecção, reduzindo sua dependência operacional do fornecedor.