Segurançaחוֹמָה
DevSecOps com IA: com uma mão se constrói, com a outra se guarda
A esteira de segurança que todo repositório meu recebe, como decidir o que bloqueia o merge, onde a IA explica e corrige achado e como proteger a cadeia de suprimentos.
צֹפֶה נְתַתִּיךָ
tzofeh netaticha · eu te pus por vigia · Yechezkel 33:7
Blog/Artigos · Segurança
Cibersegurança com IA: o vigia que vê precisa tocar o shofar
Detecção, triagem e resposta com IA num SOC que opera 24x7, e como medir se o vigia está acordado.
Em Yechezkel 33 o vigia tem uma única obrigação: ver a espada chegando e soprar o shofar. Se ele vê e fica quieto, a responsabilidade é dele. Todo SOC que eu conheci tinha telemetria suficiente para ver quase tudo. O que faltava era o sinal chegar a quem age, a tempo e com contexto. É exatamente nesse trecho da cadeia que a IA muda o jogo, desde que ela seja medida como qualquer outro detector.
O vigia que vê e não toca o shofar
Quase todo incidente sério que eu analisei tinha deixado rastro antes de virar incidente. O log estava lá, o EDR tinha registrado o processo, a identidade tinha feito login de um lugar improvável. O problema era de roteamento: o evento virou alerta, o alerta entrou numa fila com outros quatrocentos, e a fila foi lida por gente cansada no fim do turno.
Por isso eu desenho detecção como cadeia, com dono em cada elo. Telemetria que não é normalizada não correlaciona. Detecção sem triagem vira ruído. Triagem sem resposta pré-aprovada vira reunião. E resposta que não volta como aprendizado condena o time a ver o mesmo ataque duas vezes.
Figura 1A cadeia de detecção e resposta, com os elos em que a IA atua
- 01Telemetrialogs, EDR, identidade, cloud e rede no mesmo lugar
- 02Normalizaçãoesquema comum, horário em UTC, identidade resolvida
- 03Detecçãoregra determinística e modelo de anomalia lado a lado
- 04IATriagemresumo do caso, contexto do ativo e prioridade sugerida
- 05IARespostaplaybook com ação reversível já aprovada
- 06Aprendizadopostmortem vira regra, teste e caso de regressão
o que escapou em produção volta como caso de teste da própria detecção.
Triagem assistida: priorizar sem esconder
O risco da IA na triagem é silencioso. Um modelo que rebaixa prioridade com confiança reduz a fila, e fila menor parece sucesso. Se a regra de rebaixamento estiver errada, o SOC passa a ignorar exatamente o ataque que não se parece com os anteriores.
A regra que eu aplico é simples de enunciar: a IA pode ordenar a fila, e só uma pessoa pode fechar um caso. Todo resumo cita a fonte de cada afirmação, e toda sugestão de severidade traz a justificativa em texto, para que o analista discorde com argumento. A taxa de ajuste humano sobre a sugestão vira métrica semanal, porque ela mostra se o modelo está ajudando ou só concordando com o viés do dia.
Figura 2Divisão de trabalho entre modelo e analista na triagem
| Tarefa | O que a IA faz | O que fica com o analista | Controle que eu exijo |
|---|---|---|---|
| Enriquecer o alerta | Junta dono do ativo, criticidade, histórico e reputação do indicador | Decidir se o contexto muda a prioridade | Toda fonte citada no resumo |
| Agrupar alertas | Correlaciona eventos do mesmo ator, host ou identidade num caso só | Confirmar ou separar o agrupamento | Regra de agrupamento versionada |
| Sugerir severidade | Propõe a severidade com justificativa escrita | Aceitar, ajustar e registrar o motivo | Taxa de ajuste humano medida por semana |
| Redigir o relato | Escreve a linha do tempo e a hipótese inicial | Revisar e assinar | Relato marcado como gerado até a revisão |
| Conter | Prepara a ação do playbook, como isolar host ou revogar sessão | Aprovar a execução | Ação reversível, registrada e com dono |
O atacante também tem modelo
Do outro lado a IA barateou duas coisas: personalização e volume. Phishing com o tom exato do fornecedor, reconhecimento automatizado de superfície exposta e variação de payload para escapar de assinatura já são rotina. A consequência prática é que detecção baseada só em assinatura perde valor mais rápido, e detecção baseada em comportamento de identidade ganha.
Existe uma segunda frente, menos discutida: a aplicação com LLM que a própria empresa colocou no ar. Assistente interno com acesso a documento, agente com ferramenta de escrita, chatbot de atendimento. Cada um é superfície nova, e a lista da OWASP para aplicações com LLM é o melhor ponto de partida que eu conheço para modelar ameaça nesse tipo de sistema.
Figura 3OWASP Top 10 para aplicações com LLM, edição 2025
- LLM01Prompt injectionentrada que altera a instrução do modelo, digitada ou vinda de um documento lido
- LLM02Vazamento de informação sensívelo modelo devolve dado que aquele usuário não poderia ver
- LLM03Cadeia de suprimentosmodelo, dataset ou plugin de origem não verificada
- LLM04Envenenamento de dado e modelotreino ou base de RAG adulterados para mudar o comportamento
- LLM05Saída sem tratamentotexto do modelo usado como comando, SQL ou HTML sem validação
- LLM06Agência excessivaferramenta com permissão maior que a tarefa exige
- LLM07Vazamento de system promptinstrução interna exposta, às vezes com segredo dentro
- LLM08Fraqueza em vetores e embeddingsbusca vetorial sem controle de acesso por documento
- LLM09Desinformaçãoresposta confiante e errada tratada como fato
- LLM10Consumo sem limitecusto e latência sem teto, porta aberta para negação de serviço
Medir o vigia: precisão, recall e tempo
Detector sem medição é opinião. Para medir é preciso saber a verdade de antemão, e em segurança isso quase nunca vem de graça. O que eu faço é plantar o problema: gero dado sintético com o ataque injetado em posição conhecida, rodo a detecção e conto o que passou e o que escapou. É o mesmo método que está nos meus projetos, e é o que permite afirmar um número de recall sem inventar.
Junto da matriz de confusão entram dois tempos. MTTD, o tempo até detectar, mede o vigia. MTTR, o tempo até restaurar, mede o time inteiro. Um modelo de IA na triagem deveria reduzir o intervalo entre os dois sem piorar o recall, e é essa a comparação que decide se ele fica.
Figura 4Matriz de confusão de um detector, lida como responsabilidade do vigia
O que o detector disse
O que aconteceu de fato
Verdadeiro positivoalertou e era ataque. É o quadrante que justifica o plantão.
Falso positivoalertou e era benigno. Custa atenção e ensina o time a ignorar alerta.
Falso negativoficou quieto e era ataque. É o vigia que viu e não tocou o shofar.
Verdadeiro negativoficou quieto e era benigno. Invisível, e por isso raramente medido.
Governar a IA que defende
O NIST CSF 2.0 colocou Governar no centro das outras cinco funções, e isso descreve bem o que muda quando a IA entra no SOC. O modelo passa a ser ativo: tem dono, versão, dado de treino ou de contexto, métrica de desempenho e plano de retirada. Sem esse registro ninguém consegue explicar para uma auditoria por que um alerta foi rebaixado numa madrugada de sábado.
Para a parte específica de IA eu uso o NIST AI RMF, com as funções mapear, medir, gerenciar e governar. Na prática ele pede o mesmo que o resto deste artigo: saber onde o modelo atua, medir contra verdade conhecida, limitar o que ele pode fazer sozinho e registrar cada decisão.
Figura 5As funções do NIST CSF 2.0, com Governar no centro
- Identificar inventário de ativo, de identidade e de modelo de IA em uso, com dono.
- Proteger menor privilégio, segredo fora do código e guardrail no agente.
- Detectar regra explicável e modelo lado a lado, os dois medidos.
- Responder playbook com ação reversível e aprovação humana registrada.
- Recuperar restauração ensaiada e postmortem que vira caso de teste.
Para levar
A IA não substitui o vigia. Ela encurta a distância entre ver e soprar o shofar. Para isso funcionar em produção, a detecção precisa de base explicável, a triagem precisa de fonte citada, a resposta precisa de ação reversível e o modelo precisa de medição contra verdade conhecida. Com esses quatro elementos a IA reduz o tempo de resposta e o time continua capaz de explicar cada decisão.
Quem escreve: Juliano Vince de Campos
Gerente de Operações, Tecnologia e Infraestrutura (SRE) numa central de registros. Trabalho com tecnologia desde 2009 e com cibersegurança em tempo integral desde 2015, em infraestrutura crítica, fintech e banking. Escrevo sobre o que eu opero: confiabilidade, segurança, governança e IA que passa por gate antes de chegar em produção.
