SOC e SIEM: o que é um Security Operations Center e como funciona a detecção 24x7

O que é um SOC (Security Operations Center) e o que ele faz

Um SOC (Security Operations Center, ou Centro de Operações de Segurança) é a função organizacional responsável por monitorar continuamente o ambiente de tecnologia, detectar atividade maliciosa, investigar alertas e coordenar a resposta a incidentes. Pode ser uma sala física com analistas, um time distribuído ou um serviço gerenciado por terceiros, mas o que o define não é o local: é a combinação de pessoas, processos e tecnologia operando ininterruptamente para reduzir o tempo entre o início de um ataque e sua contenção.

As responsabilidades de um SOC se organizam em níveis. O Tier 1 (triagem) recebe os alertas do SIEM e das ferramentas de detecção, descarta falsos positivos e escala o que é relevante. O Tier 2 (investigação) faz a análise aprofundada, correlaciona eventos, determina o escopo do comprometimento e inicia a contenção. O Tier 3 (threat hunting e detecção avançada) caça ameaças que passaram pelos controles automáticos, desenvolve novas regras de detecção e conduz a resposta a incidentes complexos. Acima deles, o SOC Manager governa SLAs, métricas e escalonamento.

Na prática, o SOC executa quatro funções centrais: monitoramento contínuo (24x7) de logs e telemetria; detecção e triagem de alertas; investigação e análise forense inicial; e resposta e contenção, isolando hosts, bloqueando contas ou IPs e acionando o plano de resposta a incidentes. Funções de apoio incluem gestão de vulnerabilidades, threat intelligence e o ajuste contínuo das regras de detecção (tuning), que é o que separa um SOC eficaz de um gerador de ruído.

Para fintechs, exchanges de cripto e startups que processam dados sensíveis ou movimentam valores, o SOC é o controle que torna a detecção uma operação real e não uma promessa de ferramenta. Frameworks como o NIST CSF 2.0 (funções Detect e Respond) e o MITRE ATT&CK estruturam o que o SOC precisa cobrir: mapear técnicas adversárias conhecidas e garantir que cada uma tenha cobertura de detecção. A Decripte opera um SOC 24x7 gerenciado com SLA de contenção de incidente crítico em até 1 hora.

SIEM, EDR/XDR, NDR e SOAR: o stack de detecção e resposta

O SIEM (Security Information and Event Management) é a plataforma central do SOC. Ele coleta logs e eventos de praticamente toda a infraestrutura — servidores, firewalls, identidade, nuvem, aplicações — normaliza esses dados em um formato comum e aplica regras de correlação para gerar alertas. O valor do SIEM está na correlação: eventos que isoladamente parecem benignos (um login fora do horário, seguido de elevação de privilégio e acesso a um banco de dados) viram, juntos, um indicador de comprometimento. Exemplos comuns incluem Microsoft Sentinel, Splunk, Elastic SIEM e Wazuh.

O EDR (Endpoint Detection and Response) instala um agente em endpoints — notebooks, servidores, estações — e captura telemetria de processos, comandos, conexões de rede e alterações de arquivos. Diferente do antivírus tradicional baseado em assinatura, o EDR detecta comportamento malicioso (por exemplo, um processo legítimo do Office abrindo um shell) e permite resposta no próprio host: isolar a máquina da rede, matar processos ou reverter alterações. O XDR (Extended Detection and Response) estende essa lógica para além do endpoint, unificando telemetria de e-mail, identidade, nuvem e rede em uma única plataforma de detecção e correlação cruzada.

O NDR (Network Detection and Response) analisa o tráfego de rede — incluindo metadados de fluxo e, quando possível, conteúdo — para detectar movimentação lateral, exfiltração de dados, comando-e-controle (C2) e dispositivos não gerenciados que o EDR não enxerga. É a camada que cobre o que não tem agente: IoT, dispositivos legados, contêineres efêmeros e tráfego entre máquinas.

O SOAR (Security Orchestration, Automation and Response) é a camada de automação e orquestração. Ele recebe alertas do SIEM e das demais ferramentas e executa playbooks: enriquecer um alerta com threat intelligence, abrir um ticket, bloquear um IP no firewall, desabilitar uma conta comprometida ou isolar um host — tudo de forma automatizada ou semiautomatizada. O SOAR reduz o tempo de resposta de minutos para segundos em ações repetitivas e libera os analistas para investigação. Resumindo o stack: o SIEM correlaciona e detecta, EDR/XDR e NDR fornecem visibilidade profunda em endpoint e rede, e o SOAR orquestra e automatiza a resposta.

MTTD, MTTR e por que o tempo é a métrica que importa

Duas métricas governam a eficácia de um SOC: o MTTD (Mean Time To Detect — tempo médio para detectar) e o MTTR (Mean Time To Respond, ou To Remediate — tempo médio para responder ou remediar). O MTTD mede quanto tempo se passa entre o início da atividade maliciosa e o momento em que o SOC a identifica. O MTTR mede o tempo entre a detecção e a contenção ou erradicação efetiva da ameaça. Juntos, eles definem por quanto tempo um atacante permanece livre dentro do ambiente — o chamado dwell time (tempo de permanência).

O tempo importa porque ataques modernos são rápidos. Após o acesso inicial, operadores de ransomware e grupos de intrusão frequentemente realizam movimentação lateral e escalada de privilégios em horas. O 'breakout time' — o intervalo entre o comprometimento inicial e a primeira movimentação lateral — pode ser de menos de uma hora em campanhas mais ágeis. Isso significa que um MTTD medido em dias ou semanas, comum em ambientes sem monitoramento 24x7, praticamente garante que o atacante atingirá seus objetivos antes de qualquer reação.

Reduzir o MTTD depende de cobertura de detecção (mapear técnicas do MITRE ATT&CK para regras ativas), qualidade da telemetria e monitoramento contínuo — não adianta detectar às 3h da manhã se ninguém está de plantão. Reduzir o MTTR depende de playbooks claros, automação via SOAR e autoridade para agir (isolar hosts, bloquear contas) sem esperar aprovações que custam horas. Um SOC maduro mede e melhora ambas as métricas continuamente.

É por isso que a Decripte trabalha com SLA de contenção de incidente crítico em até 1 hora: o compromisso não é apenas 'avisar', e sim conter. Para fintechs e exchanges, cada minuto de dwell time se traduz diretamente em risco financeiro, vazamento de dados de clientes e exposição regulatória perante o Banco Central e a LGPD.

SOC próprio vs terceirizado (MSSP/MDR): custo, escala e SLA

Montar um SOC interno (in-house) exige cobertura 24x7, o que na prática significa um mínimo de oito a doze analistas para garantir turnos, folgas e níveis de senioridade — além de licenças de SIEM, EDR e threat intelligence, e de engenheiros de detecção para manter as regras. Para a maioria das fintechs e startups, o custo anual chega facilmente a milhões de reais antes de o primeiro alerta ser investigado. O SOC próprio faz sentido quando há escala, requisitos regulatórios que exigem operação interna ou necessidade de conhecimento profundo e exclusivo do negócio.

O modelo terceirizado se divide em dois conceitos que costumam ser confundidos. Um MSSP (Managed Security Service Provider) gerencia e monitora ferramentas de segurança, normalmente focado em manter o SIEM operante e repassar alertas — o cliente ainda costuma ser responsável por investigar e responder. Um MDR (Managed Detection and Response) vai além: entrega detecção, investigação e resposta ativa como serviço, com analistas que efetivamente contêm a ameaça em nome do cliente, incluindo ações como isolar hosts e bloquear contas.

Os trade-offs centrais são custo, escala e velocidade de implantação. O modelo gerenciado (MDR) entrega operação 24x7 madura em semanas, com custo previsível e acesso imediato a analistas experientes e threat intelligence compartilhada entre clientes — algo difícil de replicar internamente. O SOC próprio oferece controle total e conhecimento contextual máximo, ao preço de tempo de maturação (12 a 24 meses) e despesa fixa elevada. Muitas organizações adotam um modelo híbrido: time interno reduzido para contexto de negócio, apoiado por um MDR para cobertura 24x7 e resposta.

Ao avaliar um provedor, o critério decisivo é o SLA de resposta — não o de notificação. 'Avisar em 15 minutos' não significa nada se a contenção leva dias. Verifique se o contrato cobre detecção, investigação E resposta ativa, qual o SLA de contenção para incidentes críticos, e se o provedor age no ambiente ou apenas reporta. A Decripte opera um SOC 24x7 gerenciado em modelo MDR, com SLA de contenção de incidente crítico em até 1 hora.

Threat hunting proativo e use cases de detecção

Threat hunting é a busca proativa e baseada em hipóteses por ameaças que escaparam dos controles automáticos de detecção. Em vez de esperar um alerta, o caçador (hunter) parte de uma hipótese — por exemplo, 'um atacante pode estar usando ferramentas nativas do sistema (living-off-the-land) para movimentação lateral' — e investiga a telemetria à procura de evidências. É a resposta ao fato de que nenhuma regra cobre 100% das técnicas, e adversários sofisticados desenham seus ataques justamente para não disparar alertas.

Hunts eficazes são estruturados em torno do MITRE ATT&CK, que cataloga táticas e técnicas adversárias reais. O hunter seleciona técnicas relevantes para o perfil de ameaça da organização (por exemplo, T1003 — dumping de credenciais, ou T1071 — C2 sobre protocolos de aplicação) e verifica se há cobertura de detecção e se há sinais de uso. Quando um hunt encontra uma lacuna, ela vira uma nova regra de detecção — o threat hunting alimenta e melhora continuamente a detecção automatizada.

Use cases concretos de detecção que um SOC mantém ativos incluem: autenticação anômala (logins de geolocalização impossível, força bruta, MFA fatigue); execução suspeita em endpoints (PowerShell ofuscado, processos do Office gerando shells, persistência via tarefas agendadas); movimentação lateral (uso anômalo de PsExec, RDP entre estações, abuso de credenciais); exfiltração (volumes anômalos de saída de dados, uploads para destinos não corporativos); e comportamento de identidade na nuvem (criação de chaves de acesso, alteração de políticas IAM, acesso a buckets sensíveis).

Para fintechs e exchanges, detecções específicas do negócio são tão importantes quanto as genéricas: padrões de transação fora do esperado, acesso anômalo a sistemas de custódia ou a carteiras, e alterações em controles antifraude. Um SOC que conhece o domínio do cliente constrói detecções sob medida — exatamente o tipo de cobertura que um monitoramento genérico baseado só em regras de fábrica não entrega.

Falsos positivos e por que o tuning define o valor do SOC

Um falso positivo é um alerta que aponta atividade maliciosa onde não há nenhuma. Eles são o maior inimigo operacional de um SOC: quando a maioria dos alertas é ruído, os analistas desenvolvem fadiga de alertas (alert fatigue) e passam a tratar tudo com menos rigor — aumentando o risco de que o alerta verdadeiro, perdido no meio do ruído, não seja investigado. Em muitos SOCs imaturos, a esmagadora maioria dos alertas é descartada como falso positivo, o que torna a operação cara e perigosamente desatenta.

Tuning é o processo contínuo de ajustar regras, limiares e listas de exceção para que o SIEM e as ferramentas de detecção gerem alertas de alta fidelidade. Isso inclui suprimir comportamentos legítimos conhecidos (um scanner de vulnerabilidades autorizado não deve gerar alerta de varredura), ajustar limiares (quantas falhas de login configuram força bruta naquele ambiente), enriquecer alertas com contexto (esse IP é de um parceiro conhecido?) e aposentar regras que só geram ruído. Tuning não é tarefa única de implantação: é trabalho permanente de engenharia de detecção.

É por isso que a tecnologia, sozinha, não entrega segurança. Dois clientes podem comprar o mesmo SIEM e o mesmo EDR e ter resultados opostos — a diferença está na operação: na qualidade do tuning, na cobertura de detecção mapeada contra o MITRE ATT&CK, nos playbooks de resposta e na competência dos analistas. O valor de um SOC mede-se pela relação sinal-ruído dos seus alertas e pela velocidade com que age sobre os verdadeiros.

Na Decripte, o tuning é tratado como disciplina de engenharia contínua: cada falso positivo recorrente é uma oportunidade de refinar uma regra, e cada incidente real vira aprendizado que melhora a detecção futura. É essa operação ajustada — não a marca da ferramenta — que sustenta o SLA de contenção de incidente crítico em até 1 hora.

Passo a passo

1. Defina o escopo e os ativos críticos: mapeie sistemas, dados sensíveis e superfícies de risco (custódia, antifraude, identidade, nuvem) e priorize a cobertura de detecção a partir do que mais importa para o negócio.
2. Centralize a coleta de logs e telemetria: implante um SIEM e integre fontes essenciais — identidade, firewalls, servidores, nuvem, aplicações e endpoints — normalizando os dados para correlação.
3. Instale visibilidade profunda: distribua EDR/XDR nos endpoints e servidores e adicione NDR para cobrir tráfego de rede, dispositivos sem agente e movimentação lateral.
4. Mapeie detecções contra o MITRE ATT&CK: identifique as técnicas relevantes ao seu perfil de ameaça e garanta que cada uma tenha uma regra de detecção ativa, fechando lacunas de cobertura.
5. Escreva playbooks de resposta e automatize com SOAR: defina ações claras para cada tipo de incidente (isolar host, bloquear conta, conter IP) e automatize as repetitivas para reduzir o MTTR.
6. Estabeleça monitoramento 24x7 e SLAs: garanta cobertura ininterrupta — interna, MDR ou híbrida — com SLA de contenção para incidentes críticos, não apenas de notificação.
7. Ajuste continuamente (tuning) e cace ameaças: refine regras para eliminar falsos positivos, conduza threat hunting proativo baseado em hipóteses e transforme cada incidente em melhoria da detecção futura.

Perguntas frequentes