Pular para o conteúdo

SOC e MDR como serviço: quando faz sentido

Quando contratar SOC e MDR como serviço em vez de montar um time interno, como comparar as opções e o que exigir de um provedor de detecção e resposta.

SOC e MDR como serviço fazem sentido quando a organização precisa de detecção e resposta 24x7 mas não tem escala para manter um time interno maduro. O provedor entrega monitoramento contínuo, triagem e contenção; a empresa mantém o contexto de negócio e a decisão final. A escolha depende de maturidade, volume e custo total.

Poucos temas de segurança operacional geram tanta confusão quanto a diferença entre montar um SOC interno, contratar um SOC gerenciado ou assinar um serviço de MDR. As três respostas resolvem o mesmo problema — enxergar e conter um ataque antes que ele vire incidente — mas partem de premissas de custo, escala e maturidade muito diferentes. Este texto separa os conceitos e mostra como decidir sem se prender a rótulos de fornecedor.

O que são SOC e MDR como serviço?

SOC (Security Operations Center) é a função de monitorar, detectar e responder a ameaças de forma contínua; MDR (Managed Detection and Response) é um serviço que entrega essa função de fora, combinando tecnologia, telemetria e analistas de plantão. Na prática, um SOC pode ser interno, terceirizado ou híbrido — o MDR é uma das formas de terceirizá-lo, focada em detecção e resposta ativa, não apenas em coletar alertas.

A distinção que mais importa não é o nome, e sim o que cada arranjo cobre:

  • SOC interno — a organização monta o time, opera as ferramentas (SIEM, EDR, análise de logs) e responde aos incidentes com pessoal próprio.
  • SOC gerenciado (MSSP clássico) — um terceiro monitora as ferramentas e encaminha alertas, mas a resposta costuma ficar do lado do cliente. Vira uma fábrica de tickets se a triagem for fraca.
  • MDR — o provedor não só detecta como conduz a resposta: isola um endpoint, bloqueia uma conta, contém a ameaça e depois entrega o contexto. É a evolução do modelo gerenciado voltada para reduzir o tempo entre o alerta e a contenção.

O ponto cego mais comum é contratar um serviço que só gera alertas e esperar dele a maturidade de um que também responde. Detecção sem resposta transfere o trabalho difícil de volta para quem não tinha equipe para fazê-lo.

Quando faz sentido contratar em vez de montar internamente?

Contratar SOC ou MDR como serviço faz sentido quando o custo e o tempo de construir a capacidade interna superam o valor de tê-la sob controle direto. Um SOC próprio maduro exige turnos 24x7, o que na prática significa contratar de seis a oito analistas só para cobrir a escala sem fadiga, mais engenharia de detecção, gestão de plataforma e retenção de talento — uma superfície de custo que poucas empresas fora do setor financeiro sustentam sozinhas.

Os sinais de que o modelo como serviço tende a compensar:

  1. A operação precisa de cobertura 24x7 e o volume não justifica um time interno completo. Ataque não respeita horário comercial; um time que só cobre o dia deixa a janela mais explorada descoberta.
  2. Falta engenharia de detecção madura. Comprar um SIEM é fácil; escrever, calibrar e manter regras de detecção úteis é o trabalho real, e é onde a maioria dos SOCs internos trava.
  3. A rotatividade de analistas corrói a capacidade. Segurança operacional sofre com turnover alto; um provedor dilui esse risco entre vários clientes.
  4. A empresa precisa subir a capacidade rápido, por exigência regulatória, contratual ou por um incidente recente, sem esperar os meses que a montagem interna leva.
  5. O custo total do interno não fecha. Somadas pessoas, plataformas, treinamento e o custo de oportunidade, o modelo como serviço frequentemente entrega mais maturidade por real investido nos estágios iniciais.

Por outro lado, montar (ou manter) o SOC interno faz sentido quando o contexto de negócio é altamente específico, quando há restrição regulatória sobre onde a telemetria pode ser processada, ou quando a organização já atingiu escala suficiente para que o time próprio saia mais barato que o serviço. Na maioria dos casos, o desenho vencedor é híbrido: o provedor sustenta o contínuo e o plantão, e um time interno enxuto mantém o contexto, decide sobre ações de maior impacto e governa o fornecedor.

SOC/MDR terceirizado ou time interno: como comparar?

A comparação honesta olha custo total, tempo de maturação, cobertura e controle — não apenas o preço da assinatura. A tabela abaixo resume as diferenças estruturais entre os dois extremos; o modelo híbrido, na prática o mais adotado, combina as colunas conforme o risco.

Critério SOC interno SOC/MDR como serviço
Tempo até operar com maturidade Meses a anos Semanas
Cobertura 24x7 Exige 6 a 8 analistas em turnos Incluída no serviço
Engenharia de detecção Depende de contratar e reter Compartilhada entre clientes
Custo inicial Alto (pessoas + plataforma) Assinatura previsível
Contexto de negócio Máximo (time é interno) Precisa ser transferido ao provedor
Controle sobre a resposta Total Definido por contrato e SLA
Onde a telemetria é processada Sob controle direto Depende do modelo do provedor
Principal risco Rotatividade e maturidade lenta Dependência e caixa-preta

Nenhuma coluna é vencedora universal. O erro é comparar só a mensalidade do serviço com o salário de um analista — a conta real inclui os turnos que garantem a escala, a plataforma, o treinamento contínuo e o tempo até a operação de fato detectar algo relevante.

O que exigir de um provedor de SOC/MDR?

Exija transparência operacional, resposta contratada e propriedade dos seus dados — sem esses três pilares, o serviço vira uma caixa-preta que você não consegue auditar nem levar embora. A qualidade de um provedor está menos no marketing e mais no que ele aceita colocar por escrito. O checklist mínimo antes de assinar:

  • SLA de detecção e de resposta, não só de disponibilidade. Pergunte o tempo médio até a triagem e até a contenção, e o que acontece quando ele estoura. "Uptime da plataforma" não protege ninguém.
  • Cobertura de técnicas mapeada em MITRE ATT&CK. Um provedor sério mostra quais táticas e técnicas ele detecta e onde estão as lacunas, em vez de prometer detectar "tudo".
  • Resposta ativa definida. Deixe claro o que o provedor pode fazer sozinho (isolar endpoint, bloquear conta) e o que exige aprovação. Ambiguidade aqui custa minutos preciosos durante um incidente.
  • Threat intelligence acionável e regionalizada. Inteligência genérica gera ruído; a que importa é contextualizada para o seu setor e para o cenário de ameaças que de fato atinge operações no Brasil e na América Latina.
  • Modelo co-gerenciado e sem aprisionamento. Você deve manter acesso aos dados brutos, às regras de detecção e ao histórico. Se sair do contrato significar perder tudo, o custo de troca vira uma jaula.
  • Propriedade e residência dos dados. Defina por contrato onde a telemetria é armazenada e processada e quem pode acessá-la — ponto crítico para LGPD e para dados sob regulação setorial.
  • Relatórios que sustentam decisão, não vaidade. Métricas de tempo de resposta, incidentes contidos e evolução de cobertura valem mais que contagem de alertas.
  • Integração com o seu processo de resposta. O provedor precisa se encaixar no seu plano de resposta a incidentes e nos seus canais, não impor um fluxo isolado que ninguém internamente acompanha.

Como o SOC/MDR se conecta a compliance e regulação?

Detecção e resposta contínuas são, cada vez mais, requisito regulatório — não apenas boa prática. Instituições sob supervisão do setor financeiro precisam demonstrar capacidade de monitoramento e resposta a incidentes cibernéticos; as resoluções do BACEN/CMN sobre segurança cibernética, incluindo a 4.893, estabelecem exigências de política, detecção e comunicação de incidentes que um SOC/MDR ajuda a sustentar. O mesmo vale para operações de pagamento e para quem processa dados sob a LGPD, onde o tempo de detecção influencia diretamente a capacidade de conter o vazamento e de comunicar dentro do prazo.

Um serviço de detecção bem desenhado alimenta o restante do programa de segurança. Ele fornece evidência de monitoramento para auditorias de adequação à ISO 27001, sustenta os requisitos de resposta a incidentes exigidos por PCI DSS, e reforça a governança de dados pessoais no trabalho de adequação à LGPD. Para organizações com exposição europeia, os mesmos controles conversam com as obrigações de reporte de incidentes da diretiva NIS2. O SOC não é uma ilha operacional — é a camada que gera a evidência viva de que os controles das normas realmente funcionam no dia a dia.

Como a Berghem executa

A Berghem trata detecção e resposta como uma capacidade que precisa ser inteligente, não apenas contínua. O ponto de partida do nosso serviço de threat intelligence e detecção não é o volume de alertas, e sim o modelo de ameaça de cada cliente: quais adversários têm motivo para atacar aquela operação, quais técnicas eles usam e onde uma falha teria o maior impacto no negócio. A partir daí, a engenharia de detecção é calibrada para o que importa — porque um painel que grita a cada evento é um painel que a equipe aprende a ignorar.

O trabalho se apoia em três princípios. O primeiro é a inteligência regionalizada: mapeamos as técnicas em MITRE ATT&CK e priorizamos as ameaças que de fato atingem operações no Brasil e na América Latina, em vez de importar cenários genéricos. O segundo é a integração com o resto do programa de segurança — a detecção conversa com os exercícios de Red Team que validam se os controles realmente disparam, com o pentest de rede e o pentest de cloud que reduzem a superfície monitorada, e com a esteira de compliance quando há norma em jogo. O terceiro é a transparência: você mantém acesso ao contexto, às regras e às evidências, sem caixa-preta.

Somos uma empresa de segurança da informação em São Paulo, e o serviço se conecta ao portfólio conforme o risco justifica, do pentest de API à segurança em Open Finance. Cada entrega prioriza impacto ao negócio sobre contagem de alertas, com metodologia reconhecida sustentando cada etapa.

A Berghem é uma empresa de pentest brasileira, sediada em São Paulo, que executa testes de invasão manuais orientados por objetivo adversarial.

Perguntas frequentes

Qual a diferença entre SOC gerenciado e MDR?

Um SOC gerenciado clássico monitora suas ferramentas e encaminha alertas, deixando a resposta com você; o MDR vai além e conduz a contenção — isola um endpoint, bloqueia uma conta, contém a ameaça — antes de entregar o contexto. A diferença prática está no tempo entre o alerta e a ação.

SOC como serviço substitui o time interno de segurança?

Não substitui, complementa. O provedor sustenta o plantão 24x7 e a engenharia de detecção que exigem escala, mas o contexto de negócio, a decisão sobre ações de maior impacto e a governança do próprio fornecedor precisam ficar do lado da organização. O desenho mais eficaz costuma ser híbrido.

Como evitar aprisionamento (lock-in) a um provedor de MDR?

Defina em contrato, antes de assinar, que você mantém acesso aos dados brutos, às regras de detecção e ao histórico de incidentes, além de residência de dados compatível com a LGPD. Exija que a telemetria e as detecções sejam exportáveis. Se encerrar o contrato significar perder tudo, o custo de troca vira uma jaula.


Para desenhar detecção e resposta calibradas ao seu modelo de ameaça, conheça o serviço de threat intelligence e detecção da Berghem.

Voltar para Insights