Adversarial Security

Todo ambiente de tecnologia tem uma hipótese sobre si mesmo: que as regras de acesso serão respeitadas, que a segmentação de rede contém o movimento lateral, que o registro de eventos mostrará o que aconteceu, que ninguém vai encadear dois controles isolados para contornar um terceiro.

O trabalho adversarial existe para transformar essa hipótese em constatação — ou em lista de correções. É uma tentativa deliberada, autorizada e limitada de atravessar os controles existentes, feita dentro de um escopo escrito, para descobrir o que um controle resiste antes que alguém o descubra sem autorização.

O objetivo é a decisão de engenharia que vem depois. Não o resultado espetacular durante.

A composição depende do escopo acordado. Estes são os eixos mais comuns, e cada um pode ser contratado isoladamente.

• Superfície externa — serviços expostos, interfaces de API, aplicações web e fluxos públicos de autenticação.
• Autenticação e sessão — credenciais, ciclo de vida de sessão, recuperação de conta, autenticação multifator e delegação de identidade.
• Autorização — limites entre contas, papéis e organizações; acesso a recursos que não pertencem ao solicitante.
• Lógica de negócio — sequências legítimas que produzem resultado indevido: repetição, reordenação, ausência de estado intermediário, saldo e valor.
• Controles de infraestrutura — segmentação, exposição de serviços internos, configuração de borda e postura de rede.
• Integração entre componentes — onde a confiança é transferida de um sistema para outro sem ser revalidada.
• Visibilidade defensiva — se os controles de detecção efetivamente observaram a atividade executada dentro do escopo.

A avaliação defensiva de código e configuração é tratada em segurança de aplicações e APIs; o que envolve modelos, agentes e dados de treinamento fica em segurança de IA.

Esta é a parte do serviço que não é negociável. Sem ela, não há trabalho.

• Autorização formal do responsável legal ou técnico pelo sistema, com identificação do autorizante.
• Lista explícita de alvos autorizados e de alvos excluídos — inclusive ambientes de terceiros que compartilham a mesma infraestrutura.
• Janela de execução combinada, com possibilidade de suspensão imediata por qualquer uma das partes.
• Definição prévia do que fazer diante de um achado crítico: quem é avisado, em quanto tempo, por qual canal.
• Sem acesso a dados de terceiros, sem interrupção de serviço de produção e sem persistência além do necessário para demonstrar o achado.
• Confidencialidade do relatório e dos achados, com prazo de sigilo combinado antes de qualquer menção pública.

• Relatório técnico — um achado por seção, com condição necessária, evidência observada, impacto descrito e recomendação de correção.
• Prioridade — o que precisa ser corrigido antes de qualquer outra coisa, e o que pode esperar.
• Registro de método — o que foi testado, o que foi testado e resistiu, e o que ficou fora do escopo.
• Resumo executivo — uma página para quem precisa tomar decisão de orçamento e prazo, sem leitura técnica.
• Sessão de apresentação — discussão dos achados com as pessoas que vão corrigir.
• Revalidação — quando contratada, confirmação documentada de que a correção funciona.

O relatório aponta com clareza onde não houve verificação. Ausência de achado em uma área não avaliada não é ausência de problema.

• Antes de expor um sistema novo, ou uma mudança relevante de arquitetura, a usuários reais.
• Antes de uma auditoria formal, de um processo de due diligence ou de uma exigência contratual de segurança.
• Depois de um incidente, para verificar se a correção encerrou o caminho usado e se existem caminhos equivalentes.
• Quando a organização precisa de evidência independente sobre a eficácia de controles que já possui.
• Quando existe a percepção interna de que a documentação de segurança e o comportamento real do sistema divergiram.

Se a necessidade for corrigir o que já se sabe estar errado, o caminho mais direto é engenharia de segurança.