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:
- 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.
- 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.
- A rotatividade de analistas corrói a capacidade. Segurança operacional sofre com turnover alto; um provedor dilui esse risco entre vários clientes.
- 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.
- 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.