SOC as a Service: o que é e como funciona o SOC terceirizado

Segurança tem um problema de horário. O ataque não respeita expediente — e os dados de resposta a incidentes mostram, ano após ano, uma concentração deliberada em madrugadas, fins de semana e feriados, exatamente porque é quando o time de TI está dormindo. A defesa, no entanto, quase sempre é montada em horário comercial.

O SOC (Security Operations Center) é a resposta estrutural a esse descompasso: uma função que observa, interpreta e reage a eventos de segurança de forma contínua. O SOC as a Service é a decisão de alugar essa função em vez de construí-la — e, para a maioria das empresas fora do topo, é a única forma de ter cobertura 24/7 sem quebrar o orçamento.

A tese em uma frase: quase nenhuma empresa fora do topo consegue manter um SOC interno, porque o custo não é da ferramenta, é da escala de plantão — e a pergunta que decide a compra não é "monitorar ou não", é "o provedor contém ou só avisa?".

O que um SOC realmente faz

A imagem de telão com mapa-múndi e linhas piscando é marketing. O trabalho real de um SOC tem quatro funções, e nenhuma delas é bonita:

• Coletar telemetria. Logs e eventos de endpoint, rede, nuvem, identidade, e-mail e aplicações, normalizados num lugar só. Sem isso, o resto não existe — e é aqui que a maioria dos projetos morre, porque metade dos sistemas não gera log e a outra metade gera log que ninguém guarda.
• Detectar. Regras de correlação, comportamento anômalo, indicadores de comprometimento e caça ativa (threat hunting), que é procurar sinal de invasor mesmo sem alerta disparado. A referência que o mercado inteiro usa para catalogar técnicas de ataque é o MITRE ATT&CK — vale perguntar ao fornecedor qual cobertura da matriz ele tem.
• Triar. Alguém precisa olhar o alerta e decidir se é ruído ou incidente. Essa é a etapa que consome mais gente e a primeira que a automação está engolindo.
• Responder. Isolar a máquina, derrubar a sessão, bloquear a conta, revogar o token, acionar quem precisa acordar. É o que transforma detecção em defesa.

Se você quer entender a camada de ferramenta por trás disso, o SIEM é onde a telemetria é correlacionada, e o XDR é a evolução que unifica endpoint, rede, e-mail, nuvem e identidade numa visão só. O SOC é quem opera essas ferramentas — a distinção importa, porque ninguém compra segurança comprando painel.

A conta que explica o mercado

Aqui está o número que vende SOC as a Service melhor do que qualquer argumento técnico.

Uma semana tem 168 horas. Uma jornada de trabalho tem cerca de 40. Só para manter uma única pessoa de plantão o tempo todo, você precisa de 4,2 equivalentes em tempo integral — e isso ignorando férias, atestado, treinamento e rotatividade. Some que um analista sozinho não conduz um incidente sério, e o número realista para cobertura contínua com dupla em turnos críticos fica entre 6 e 8 pessoas.

Agora acrescente o resto: salários de um perfil escasso e disputado, ferramentas, licenças, treinamento contínuo e o custo silencioso de manter alguém acordado às 4h de domingo esperando um alerta que talvez não venha. Para uma empresa de 200 funcionários, esse é um centro de custo maior do que todo o resto da TI.

Foi essa conta que criou o mercado. No Market Guide for Managed Detection and Response, a Gartner projetou que metade das organizações estaria usando MDR até 2025 para monitoramento, detecção e contenção 24/7 — e o número de provedores passou de 600. A pergunta deixou de ser "terceirizar ou não" e virou "como escolher entre 600".

SOC próprio, SOC as a Service e MDR

A fronteira entre as duas colunas da direita é comercial, não técnica, e cada fornecedor desenha a sua. Não gaste energia na taxonomia — gaste no contrato.

O critério que separa serviço real de painel bonito

Este é o parágrafo mais útil do post.

A definição de MDR da Gartner exige contenção e mitigação remotas, não apenas alerta, além de engajamento diário com os dados do cliente e achados ligados a risco de negócio. É uma régua alta, e boa parte do que se vende no Brasil sob esse nome não a alcança: é SIEM gerenciado com SLA de e-mail.

A diferença aparece no pior momento possível. Às 3h da manhã de um domingo, uma credencial de administrador é usada de um país onde você não tem operação. No serviço que só alerta, um e-mail entra na caixa de alguém que está dormindo, e o invasor tem seis horas livres. No serviço com contenção, a sessão é derrubada e a conta é bloqueada em minutos, e o e-mail que você lê de manhã conta o que já foi resolvido.

As seis perguntas para fazer ao fornecedor

Leve estas seis para a reunião comercial. Elas desmontam proposta ruim mais rápido do que qualquer prova de conceito:

1. Vocês contêm ou só notificam? Peça a lista de ações que o provedor está autorizado a executar sem aprovação prévia — isolar host, desabilitar conta, bloquear IP, revogar sessão. Se a resposta for "abrimos um chamado", é notificação.
2. Qual o tempo médio até a contenção, não até o alerta? Todo fornecedor tem um número bonito de tempo de detecção. Poucos têm o de contenção, que é o que importa.
3. Quem olha o meu ambiente — uma pessoa ou uma fila? Serviço bom tem alguém que conhece o seu ambiente e sabe que aquele script estranho às 2h é o backup. Serviço ruim trata você como ticket anônimo, e o resultado é falso positivo em série.
4. O que acontece quando eu sair? Os dados de log são meus? Em que formato? As regras de detecção escritas para mim são portáveis? Se a resposta for vaga, você está assinando dependência.
5. Qual o escopo real de cobertura? Endpoint só, ou também nuvem, identidade, e-mail e OT? A superfície que não é coberta é a que vai ser usada.
6. Como vocês lidam com exposição, não só com ataque? Essa distingue quem está à frente: a Gartner projeta que, até 2028, 50% dos achados de provedores de MDR incluirão detalhe sobre exposição a ameaças, contra cerca de 20% hoje. Um bom serviço não só avisa que você foi atacado — avisa por onde você seria atacado.

E um alerta sobre métrica: desconfie de relatório que celebra "4 milhões de eventos monitorados". Volume é fácil e não significa nada. Os três números que importam são tempo até detecção, tempo até contenção e taxa de falso positivo — e o que interessa neles é a tendência, não o valor de um mês.

Onde os agentes de IA entram nessa conta

Não dá para escrever sobre SOC em 2026 sem falar do que está mudando a economia do serviço por dentro.

A triagem de nível 1 — o trabalho de olhar alerta e decidir se é ruído — é repetitivo, volumoso e bem documentado. É o candidato perfeito para automação, e o mercado inteiro se moveu nessa direção: 81% dos times de segurança já passaram de piloto para operação com agentes, e a Swimlane projetou que a IA resolveria ou escalaria mais de 90% dos alertas de Tier-1 em 2026.

Isso corta o principal custo do provedor, o que deveria empurrar preço para baixo. Mas cria uma tensão que vale conhecer antes de assinar: a própria Gartner registra que gestores de SOC ficam frustrados quando a única opção é falar com um chatbot em vez de um engenheiro de segurança — e que o avanço dos agentes de IA está criando competição interna contra o MDR tradicional. Em outras palavras, o mesmo fornecedor que te vende MDR está vendendo o agente que torna parte do MDR dispensável.

A pergunta prática para a reunião: quando eu tiver um incidente sério às 3h, eu falo com uma pessoa? Se a resposta envolver "nosso assistente", entenda o que você está comprando. Se o assunto de agentes autônomos é novo para você, o post sobre agentes de IA explica o conceito pelo ângulo de negócio.

O que fazer antes de contratar

Contratar SOC com a base malfeita é caro e frustrante — o serviço vai passar os primeiros meses reportando o óbvio que você já sabia. Três pré-requisitos, em ordem:

1. A higiene básica. MFA em todos os acessos, backup testado, EDR nos endpoints, atualizações em dia e treinamento contra phishing. O roteiro completo está no guia de cibersegurança para PMEs.

2. Telemetria existindo. Verifique se os seus sistemas realmente geram log e se alguém os retém. Não adianta contratar quem vai olhar se não há o que ver. Esse levantamento costuma revelar surpresas — servidores sem log, aplicações sem auditoria, nuvem com trilha desligada por economia.

3. Definir o que é inaceitável. Antes de negociar SLA, responda: quanto tempo o meu negócio sobrevive com o sistema X fora do ar? Sem isso você compra um SLA pelo preço, não pela necessidade — e SLA de segurança mal dimensionado é dinheiro jogado fora nos dois sentidos.

Vale também ter clareza sobre a diferença entre SLA, SLO e OLA antes de sentar na mesa: o compromisso que o fornecedor assume com você e o que ele assume internamente raramente são a mesma coisa.

O ponto que fica

SOC as a Service resolve um problema real e específico: cobertura contínua por gente qualificada, a um custo que não exige montar um time de oito pessoas. Não resolve arquitetura ruim, não substitui Zero Trust e não conserta a falta de backup.

Se você tirar uma coisa só deste post, que seja a pergunta: contém ou avisa? Ela vale mais do que a sigla no contrato, mais do que o número de eventos no relatório e mais do que o tamanho do telão na foto da proposta.