SOC PME (MDR)
Sua empresa tem alerta de segurança vindo de várias ferramentas e ninguém com processo para virar caso, prazo e evidência.
O SOC PME é o console de detecção e resposta do tenant: fila de alertas, casos com máquina de estados, timeline forense e um painel de métricas operacionais. Ele não é um SIEM novo — é a camada de caso e processo em cima dos alertas que você já produz. Qualquer ferramenta com o escopo soc:alert:ingest posta um alerta em POST /api/v1/soc/alerts, com Idempotency-Key, e o alerta entra normalizado (fonte, severidade, entidade afetada, título, telemetria bruta).
Antes de gravar, a telemetria passa por um sanitizador determinístico: segredo redigido por nome de chave e por padrão de valor (JWT, sk-, AKIA, PEM, PAT, Slack), CPF/e-mail/telefone mascarados, teto de bytes no JSON e neutralização da cerca <untrusted_context>. O repouso já é limpo — o strip de PII do gateway de IA é a segunda camada, não a primeira.
O caso é a unidade de trabalho: referência legível SOC-<ano>-<sequência>, prazo de SLA derivado da prioridade (crítica 60 min, alta 4 h, média 24 h, baixa 72 h por padrão) e nunca aceito do corpo da requisição. A máquina de estados vai de novo a fechado com carimbos de reconhecimento, contenção, resolução e fechamento, exige motivo no fechamento e grava evento na timeline mais linha de auditoria a cada transição. A triagem por IA existe e é acionável, mas ela sugere: grava severidade sugerida, técnica MITRE, resumo e candidato a duplicata, e move o caso apenas de novo para triado_ia. A decisão continua do analista.
Capacidades em operação
Cada item corresponde a funcionalidade que existe no código e é alcançável por um usuário com o escopo correto.
-
Ingestão de alertas com idempotência
POST /soc/alerts com Idempotency-Key e dedup natural por (fonte, id externo). Reenvio do mesmo alerta devolve o existente em vez de duplicar.
-
Sanitização da telemetria antes do repouso
Segredos redigidos por nome de chave e por padrão de valor, PII residual mascarada, teto de bytes configurável e anti-escape da cerca de prompt. Determinístico e sem rede.
-
Casos com referência legível e SLA derivado
Referência SOC-<ano>-<seq> com retry por SAVEPOINT em caso de colisão. sla_due_at é calculado a partir da prioridade e do horário de abertura — o cliente não escolhe o prazo.
-
Máquina de estados com carimbos e auditoria
novo, triado_ia, em_analise, contido, resolvido, fechado (terminal). Cada transição grava ack_at/contained_at/resolved_at/closed_at conforme o caso, exige closure_reason no fechamento e produz evento de timeline mais audit_log.
-
Timeline forense do caso
soc_case_events registra criação, atribuição, mudança de estado, comentário do analista, nota de IA e ação de contenção executada pelo humano.
-
Vínculo alerta ↔ caso
Um alerta pode ser anexado a um caso na criação ou depois; um alerta já vinculado a outro caso é recusado com conflito explícito.
-
Triagem por IA sob demanda
POST /soc/cases/{id}/retriage roda dedup por Jaccard contra casos abertos, aplica severidade-piso (a sugestão nunca fica abaixo da máxima reportada pelos alertas) e pede ao modelo veredito, severidade, técnica MITRE e resumo. Grava em campos ai_* e move novo → triado_ia.
-
Degradação honesta da triagem
Se JC_SOC_TRIAGE_ENABLED estiver desligada, se o gateway cair ou se o turno for barrado, a triagem grava só a heurística, marca o resultado como degradado e move o caso mesmo assim. O caso nunca fica preso esperando modelo.
-
Catálogo de playbooks consultável
GET /soc/playbooks devolve 6 playbooks declarativos versionados (soc-playbooks.v1) com o predicado de aplicação, a prioridade sugerida e a lista de ações recomendadas em português.
-
Dashboard determinístico
MTTA, MTTC e MTTR como medianas em segundos, contagem de casos com SLA vencido, abertos por status e por severidade, volume de alertas por fonte, casos criados na janela e top 10 de técnicas MITRE. Tudo SQL agregado, sem IA, janela de 1 a 365 dias.
Entregáveis
- Console do SOC em /app/soc: fila de alertas, board de casos, detalhe com timeline e painel de métricas
- Console de acompanhamento no lado da operação em /staff/soc
- Caso com referência SOC-<ano>-<seq>, prazo de SLA e timeline completa como registro do atendimento
- Métricas MTTA/MTTC/MTTR, casos vencidos e top MITRE para a reunião com a diretoria
- Trilha de auditoria em audit_log e eventos de caso append-only
O que este módulo não faz
A correlação automática de alerta em caso NÃO existe. O worker soc.process_alert procura a função soc.service.correlate_alert por getattr e essa função não está definida no serviço — a task retorna {"skipped": "correlate_alert_unavailable"} e nada mais acontece. Na prática, o alerta entra na fila e o analista abre o caso (POST /soc/cases) e vincula o alerta à mão. Como a triagem por IA no worker depende do caso vindo da correlação, ela também não dispara sozinha na ingestão: só roda quando alguém chama /retriage ou cria o caso e pede a triagem. O playbook hoje é documentação consultável, não automação: a função match_playbook não tem nenhum chamador em código de produção (só o endpoint de catálogo e os testes). Não há contenção automática — nenhum host é isolado, nenhuma sessão é revogada, nenhum IP é bloqueado; ação de contenção é um evento que o humano registra depois de agir. Não existem conectores nativos para M365, EDR, firewall ou identidade: 'source' é um rótulo do alerta e quem posta é um cliente HTTP com o escopo soc:alert:ingest. Não há notificação, paging ou plantão — nenhum código do módulo dispara e-mail, push ou chamada. As rotas de alerta e de caso respondem 404 (soc.disabled) enquanto JC_SOC_ENABLED estiver false; GET /soc/playbooks e GET /soc/dashboard não passam por esse gate e seguem respondendo 200 para quem tem soc:case:read (o dashboard, zerado). A IA só chama o provedor com JC_SOC_TRIAGE_ENABLED true; ambas as flags vêm desligadas por padrão.
Declaramos o limite porque software de segurança que promete tudo não é auditável. Se o que falta aqui é o que você precisa, o serviço consultivo cobre — ou dizemos que não cobre.
Conecta com
- Gateway de IA da plataforma (task soc_triage, classe TENANT_INTERNAL, trilha em ai_usage_event/ai_egress_log)
- Outbox transacional + worker Celery (soc.alert.ingested → soc.process_alert, fila default)
- RBAC e RLS FORCE da plataforma (isolamento por tenant)
- audit_log e Idempotency-Key da fundação
- Sanitizador de prompt da fundação (neutralize_fence / wrap_untrusted)
Controle de acesso
O acesso é concedido por escopo, não por perfil genérico. Quem só precisa ler não recebe permissão de escrita, e a barreira é o banco de dados, não a interface.
- soc:alert:read
- soc:alert:ingest
- soc:case:read
- soc:case:write
Quer ver funcionando?
Demonstração com dado do seu ambiente, não com base de exemplo. É a única forma de saber se serve.