4.10 Testes de intrusão e red teaming

Visão geral e motivação

Vocês podem construir todos os controles que o seu modelo de ameaças pede e ainda assim não saber se eles funcionam. A documentação diz que o firewall bloqueia aquela porta, a revisão de código diz que a entrada é validada, a política diz que o menor privilégio é imposto. A segurança ofensiva é como vocês descobrem se algo disso é verdade quando um atacante motivado pressiona. Este capítulo trata de atacar deliberadamente os seus próprios sistemas, com autorização, para achar as fraquezas antes que um adversário de verdade as ache.

A disciplina corre ao longo de um espectro. Na ponta leve fica a varredura de vulnerabilidades: ferramentas automatizadas que sondam falhas e configurações incorretas conhecidas. No meio fica o teste de intrusão: um humano habilidoso que encadeia fraquezas para provar a explorabilidade contra um alvo definido. Na ponta distante fica o red teaming: uma campanha guiada por objetivos que emula um adversário real entre pessoas, processos e tecnologia, e que testa a sua capacidade de detectar e responder, não apenas de prevenir. Cada um responde a uma pergunta diferente, e confundi-los é o jeito mais comum de as organizações desperdiçarem dinheiro e se consolarem com uma falsa garantia.

Este capítulo fica deliberadamente à parte de seus vizinhos. O capítulo 4.4 cobre as operações de segurança: o lado defensivo, de monitoramento, que vigia as ameaças e responde a elas. Este capítulo é a contraparte ofensiva que testa se essa defesa de fato funciona. O capítulo 4.9 cobre o ciclo de vida de desenvolvimento seguro de software, em que a segurança é embutida em como o código é projetado e entregue. O teste ofensivo valida por fora o produto desse ciclo de vida. Ele também se apoia nos fundamentos e na cultura do capítulo 4.1 e nas práticas de segurança de aplicações do capítulo 4.2.

Para as grandes empresas, o teste ofensivo é ao mesmo tempo uma ferramenta de redução de risco e uma obrigação regulatória. Processadores de pagamento, bancos e provedores de saúde enfrentam exigências explícitas de testar. Para o governo, as apostas chegam à segurança nacional e à confiança pública: os adversários aqui são Estados-nação bem dotados de recursos, e os sistemas que eles visam conduzem eleições, benefícios e infraestrutura crítica. Nos dois contextos, o valor não vem do relatório, mas do que vocês corrigem e de quanto mais depressa aprendem a detectar a próxima intrusão.

Princípios fundamentais

Combinem o trabalho com a pergunta: varredura, teste de intrusão e red teaming respondem a coisas diferentes.
Obtenham autorização por escrito e regras de engajamento claras antes de alguém tocar um sistema.
Os achados não valem nada até serem remediados e retestados. Acompanhem-nos como qualquer outro trabalho.
Um red team existe para tornar o blue team melhor, não para vencer.
Emulem adversários reais e suas técnicas, não listas de verificação genéricas.
Meçam a detecção e a resposta, não apenas a contagem de vulnerabilidades achadas.
Cuidado com o teatro: um trabalho delimitado para passar parece impressionante e não prova nada.

Recomendações

Entenda o espectro da segurança ofensiva

Comecem nomeando o que estão comprando. A varredura de vulnerabilidades é ampla, automatizada e barata. Rodem-na continuamente contra o seu parque para pegar Common Vulnerabilities and Exposures (CVEs) conhecidas e configurações incorretas. Ela produz volume e falsos positivos e não consegue dizer se uma falha é de fato explorável no contexto. O teste de intrusão põe um testador habilidoso contra um alvo definido por uma janela fixa, encadeando fraquezas para demonstrar impacto real: este achado do varredor, combinado com aquela permissão fraca, rende administrador de domínio. Ele responde “esta coisa específica pode ser quebrada, e quão gravemente”.

O red teaming responde a uma pergunta maior: “se um adversário determinado nos visasse, perceberíamos, e conseguiríamos detê-lo”. É orientado por objetivos (exfiltrar este conjunto de dados, alcançar este sistema de controle), cobre toda a superfície de ataque, incluindo pessoas e acesso físico, e costuma ser conduzido sem avisar os defensores. O purple teaming derruba o muro: red e blue trabalham juntos na mesma sala, o atacante executa uma técnica e o defensor observa se suas ferramentas a pegam, ajustando as detecções em tempo real. O purple teaming muitas vezes entrega mais melhoria defensiva por dólar que um red team encoberto, porque cada ação vira um momento de ensino.

Escolha deliberadamente entre caixa-preta, cinza e branca

O quanto vocês contam ao testador molda o que aprendem. O teste de caixa-preta não lhe dá nada além de um alvo, simulando um atacante externo sem conhecimento interno. É realista mas lento, e os testadores podem gastar o orçamento inteiro em reconhecimento que um adversário real levaria meses fazendo. O teste de caixa-branca entrega o código-fonte, diagramas de arquitetura e credenciais, deixando o testador ir fundo e cobrir mais terreno no tempo disponível. A caixa-cinza fica no meio: algum conhecimento, algumas credenciais, imitando um atacante que fez a lição de casa ou um interno malicioso.

Para a maioria dos testes de aplicações, a caixa-cinza ou branca dá melhor retorno, porque vocês estão pagando por profundidade de análise e não para o testador redescobrir o layout das suas sub-redes. Reservem a caixa-preta para quando o realismo da fase de descoberta é em si o que vocês querem testar, como medir quanto um estranho consegue aprender da sua pegada pública. Sejam explícitos sobre qual estão contratando, já que um relatório de caixa-preta que acha pouco pode significar que vocês são seguros ou que o testador ficou sem tempo no perímetro.

Delimite o escopo com cuidado e escreva as regras de engajamento

O escopo é onde os trabalhos têm sucesso ou fracassam. Um documento de regras de engajamento define o que está dentro dos limites e o que não está, quais técnicas são permitidas, a janela de testes, os sistemas e redes cobertos, as exigências de tratamento de dados e os contatos de emergência dos dois lados. Ele nomeia os sistemas de produção que estão fora dos limites ou exigem cuidado, define uma regra de parada se o testador achar algo ativamente perigoso e define o que acontece se ele esbarrar em atividade real de atacante ou em dados genuinamente sensíveis.

Escrevam caminhos de escalonamento e uma carta de “saída livre”: uma autorização que o testador pode apresentar se a equipe de segurança ou a polícia o questionar no meio do trabalho. Combinem de antemão como os achados são armazenados e transmitidos, já que um relatório de teste de intrusão é um mapa de como violar vocês e precisa ser protegido de acordo. Um escopo estreito produz achados profundos numa superfície pequena. Um escopo amplo produz uma cobertura rasa de uma superfície grande. Escolham de propósito e nunca deixem o escopo se expandir em silêncio durante o trabalho sem nova autorização.

Trate a autorização como a linha entre testar e cometer um crime

O único ato que separa um testador de intrusão de um criminoso é a autorização. Acessar sistemas que vocês não estão autorizados a acessar é crime sob leis como o Computer Fraud and Abuse Act nos Estados Unidos e equivalentes em outros lugares, e as boas intenções não são defesa. A autorização precisa vir por escrito de alguém com a autoridade real para concedê-la, cobrir exatamente os sistemas e técnicas no escopo e ser assinada antes de o trabalho começar.

Os sistemas de terceiros complicam isso. O seu provedor de nuvem, os seus fornecedores de software como serviço e qualquer infraestrutura compartilhada podem ter suas próprias políticas de teste, e vocês não podem autorizar um ataque a ativos que não possuem. Verifiquem as regras do provedor, peçam permissão onde exigido e mantenham os testes dentro da sua própria locação. A engenharia social dirigida a funcionários levanta questões éticas e legais sobre consentimento e dano psicológico que vocês precisam pensar de antemão. Na dúvida, envolvam o aconselhamento jurídico: o custo de uma conversa é trivial contra o de um incidente de acesso não autorizado.

Pese as equipes internas contra os testadores terceirizados

Um red team interno conhece o seu ambiente, constrói relações com os defensores e pode testar continuamente em vez de em rajadas anuais. Essa familiaridade também é um limite: eles compartilham os seus pontos cegos e suposições organizacionais, e sua independência pode ser questionada quando reportam à mesma liderança dos sistemas que testam. As empresas terceirizadas trazem olhos novos, habilidades especializadas e a independência que auditores e reguladores muitas vezes exigem, mas demoram a entrar no ritmo, custam mais por trabalho e vão embora quando o relatório é entregue.

A maioria dos programas maduros usa os dois. As equipes internas tratam a emulação contínua de adversários, o ajuste de detecções e o profundo conhecimento do ambiente que torna produtivo o purple teaming. As empresas externas fornecem validação independente periódica, atendem às exigências de independência de padrões como o PCI DSS e sondam as áreas que as suas próprias pessoas deixaram de enxergar. Qualquer que seja a escolha, insistam em que os testadores sejam qualificados: certificações como a OSCP (Offensive Security Certified Professional) e experiência demonstrada importam mais que uma apresentação de vendas polida.

Conduza bug bounties e divulgação coordenada

Um programa de bug bounty convida pesquisadores externos a achar e relatar vulnerabilidades em troca de reconhecimento e pagamento. Ele dá testes contínuos e distribuídos, numa gama de habilidades que vocês jamais poderiam contratar de uma só vez, e vocês pagam apenas por achados reais. Não substitui os testes de intrusão estruturados, já que os pesquisadores perseguem o que paga e podem ignorar categorias inteiras, mas é um complemento poderoso que traz à tona ataques criativos.

Antes de rodar um bounty pago, vocês precisam de uma política de divulgação coordenada de vulnerabilidades: um jeito publicado e fácil de achar para qualquer pessoa relatar um problema de segurança com segurança, um compromisso de não processar judicialmente pesquisadores de boa-fé, prazos definidos de resposta e um processo interno para fazer a triagem e corrigir o que chega. Um arquivo security.txt e um endereço claro de relatos são o mínimo. As agências governamentais exigem cada vez mais políticas de divulgação de vulnerabilidades para sistemas voltados ao público, e não ter um canal não impede os pesquisadores de achar bugs: só os impede de contar a vocês com segurança.

Use a violação presumida e a emulação de adversários

O teste só de perímetro presume que o atacante começa por fora, mas as violações reais muitas vezes começam com uma credencial pescada ou um notebook comprometido já dentro. Um exercício de violação presumida começa o testador com uma brecha, como o acesso de um funcionário comum, e pergunta até onde ele consegue ir a partir dali. Isso testa diretamente a sua segmentação interna, a detecção e os controles de raio de impacto, em vez de apostar tudo num perímetro que eventualmente será cruzado. Costuma ser um uso melhor do tempo de um red team do que vê-lo se esfalfar contra uma borda endurecida.

Ancorem a campanha no comportamento real dos adversários usando o MITRE ATT&CK, uma base pública de conhecimento das táticas e técnicas que os atacantes de fato usam, organizada do acesso inicial à exfiltração. A emulação de adversários escolhe um ator de ameaça conhecido por visar o seu setor, reproduz suas técnicas documentadas e testa se vocês detectam e detêm cada passo. Isso é muito mais útil que um ataque genérico, porque mapeia as suas defesas contra os adversários específicos que vocês enfrentam e produz achados que a sua inteligência de ameaças consegue priorizar.

Devolva os achados ao blue team e à engenharia de detecção

O ponto da ofensiva é uma defesa melhor. Cada ação do red team é uma chance de perguntar: as nossas ferramentas geraram um sinal, alguém o viu e respondeu corretamente. Conduzam os trabalhos de modo que cada técnica mapeie para uma detecção que vocês têm, precisam construir ou precisam ajustar. Isso é a engenharia de detecção: transformar o comportamento do atacante em alertas confiáveis, e é onde o valor do red team se compõe. Um achado de que “não fomos detectados durante o movimento lateral” deve virar uma nova regra de detecção, testada reexecutando a técnica.

Os exercícios de mesa estendem isso à tomada de decisão. Reúnam as pessoas que responderiam a um incidente real e percorram um cenário realista no papel: quem declara o incidente, quem fala com o jurídico, quem decide tirar um sistema do ar. Os exercícios de mesa são baratos, expõem lacunas de papéis e de comunicação que os testes técnicos perdem e preparam os humanos que mais importam quando a gestão de incidentes do capítulo 9.3 entra em ação. Combinem o red teaming técnico com exercícios de mesa regulares para que tanto as ferramentas quanto as pessoas sejam exercitadas.

Acompanhe a remediação e reteste

Um relatório de vulnerabilidades em que ninguém age é um passivo, já que agora vocês rodam conscientemente uma falha que um auditor pode citar. Alimentem cada achado no seu sistema normal de acompanhamento de trabalho, com um dono, uma gravidade e um prazo ligado ao risco. Os achados críticos recebem tratamento emergencial. Os menores entram no backlog com prioridade honesta. A métrica que importa é o tempo de remediação, não o tempo de relato.

O reteste fecha o ciclo. Depois que uma correção é entregue, o testador (ou uma verificação automatizada) confirma que a vulnerabilidade de fato sumiu e que a correção não abriu um buraco novo. Sem reteste, “remediado” é uma esperança e não um fato, e muitos achados reaparecem porque uma correção foi incompleta ou uma regressão os reintroduziu. Padrões como o PCI DSS exigem explicitamente esse ciclo. Embutam o reteste no contrato do trabalho para que não seja uma reflexão tardia esquecida.

Compromissos: prós e contras

Abordagem	Melhor para	Prós	Contras
Varredura de vulnerabilidades	Cobertura contínua de falhas conhecidas	Barata, ampla, automatizada, frequente	Ruidosa. Não consegue provar explorabilidade
Teste de intrusão	Provar o impacto num alvo definido	Profundo, discernimento humano. Cadeias reais de exploração	Pontual no tempo. Escopo estreito. Caro
Red teaming	Testar a detecção e a resposta	Realista. Exercita pessoas e processos	Caro. Lento. Exige um blue team maduro
Purple teaming	Melhorar as detecções depressa	Alto aprendizado por dólar. Colaborativo	Menos realista. Exige as duas equipes disponíveis
Bug bounty	Descoberta contínua distribuída	Paga-se por achado. Habilidades diversas	Cobertura desigual. Ônus de triagem. Exige processo

A tensão central é entre realismo e velocidade de aprendizado. Um red team encoberto é o teste mais realista que vocês podem rodar, mas suas lições chegam devagar e só depois de uma campanha completa, e um blue team imaturo aprende pouco sendo derrotado em silêncio. O purple teaming sacrifica a surpresa para maximizar a rapidez com que os defensores melhoram. Uma segunda tensão é amplitude versus profundidade: a varredura cobre tudo de forma rasa, enquanto um teste de intrusão cobre uma fatia a fundo. Os programas maduros sobrepõem essas abordagens em vez de escolher uma, rodando varredura contínua por baixo de testes profundos periódicos e campanhas ocasionais de red team de escopo completo. O movimento errado é comprar um único teste de intrusão anual, arquivar o relatório e dar o problema por resolvido.

Perguntas para discutir com sua equipe

Quando contratamos testes ofensivos, estamos claros sobre qual pergunta de fato estamos fazendo, e o trabalho corresponde a ela? Muitas organizações compram um “teste de intrusão” e recebem uma varredura de vulnerabilidades com um resumo escrito por humano, depois acreditam ter testado suas defesas quando só checaram falhas conhecidas. Outras contratam um red team quando sua capacidade de detecção é tão imatura que o exercício só prova o que todos já sabiam. Levem os escopos dos últimos três trabalhos e os relatórios resultantes e perguntem se cada um respondeu à pergunta que vocês precisavam ver respondida: cobertura de vulnerabilidades conhecidas, explorabilidade de um alvo específico ou capacidade de detectar e responder a uma intrusão. A resposta deve moldar uma mistura deliberada de varredura, testes de intrusão e red ou purple teaming, ajustada à sua maturidade.
O que acontece com um achado depois que o relatório chega, e como provaríamos que foi corrigido? O valor da segurança ofensiva está inteiramente na remediação, e ainda assim muitos programas medem o sucesso pelo tamanho do relatório e não pelo encolhimento do risco. Rastreiem um achado real do último trabalho: quem era o dono, como foi priorizado contra o trabalho de funcionalidades, quando foi corrigido e se alguém confirmou que a correção realmente funcionou. Se vocês não conseguem produzir essa trilha, o seu teste está gerando conhecimento sobre o qual vocês não agem, o que é pior que não saber, porque agora vocês estão conscientemente expostos. O produto desta discussão deve ser um fluxo acompanhado de remediação com donos, prazos baseados em risco e reteste obrigatório embutido em todo contrato.
O nosso red team está tornando o nosso blue team melhor, ou apenas marcando pontos? Um red team que celebra vitórias não detectadas e acumula suas técnicas é divertido e inútil. A relação deve ser colaborativa por baixo da superfície adversarial: toda técnica que passa sem ser detectada deve virar uma nova regra de detecção, todo caminho bem-sucedido deve informar a segmentação e as duas equipes devem fazer a retrospectiva juntas. Perguntem aos seus defensores o que aprenderam com o último trabalho do red team e se alguma detecção ou controle concreto mudou em consequência. Se a resposta honesta é nada, vocês estão pagando por teatro e devem se deslocar rumo ao purple teaming e à emulação de adversários explicitamente ligados à engenharia de detecção.
Antes do nosso próximo trabalho, temos autorização por escrito para todo ativo no escopo, inclusive os que não possuímos? A autorização é a linha entre um teste de intrusão e um incidente de crime de informática, e numa grande organização os sistemas que um testador tocará raramente ficam dentro de uma única fronteira de propriedade: abrangem locações de nuvem, plataformas de software como serviço, redes gerenciadas e infraestrutura compartilhada que um parceiro ou fornecedor controla. A pressão concorrente é a velocidade, porque correr atrás de permissão assinada e de políticas de teste do provedor é lento e tentador de pular quando um prazo se aproxima. Levem o rascunho das regras de engajamento, o inventário de ativos com um dono nomeado contra cada sistema, as políticas relevantes de teste de nuvem e de fornecedores e a carta assinada de autorização que o testador pode apresentar se questionado no meio do trabalho. Para o trabalho corporativo e governamental a exposição é aguda: uma sondagem não autorizada contra uma plataforma compartilhada pode violar contratos, disparar um relato regulatório ou, para uma agência pública, virar manchete sobre o governo atacando sistemas que não tinha o direito de tocar, então o aconselhamento jurídico deve aprovar antes de qualquer um começar.
Estamos investindo num red team interno, em empresas externas ou nos dois, e essa divisão corresponde ao que de fato precisamos? Esta é uma decisão de construir versus comprar com dinheiro real e consequências de vários anos: uma equipe interna custa salários e ferramentas e entrega emulação contínua de adversários e profundo conhecimento do ambiente, enquanto as empresas externas custam mais por trabalho mas trazem olhos novos, habilidades especializadas e a independência que auditores e reguladores exigem. A tensão é que cada uma cobre o ponto cego da outra, então tratá-las como substitutas e não como complementares costuma deixar uma lacuna. Levem o gasto atual em cada uma, as certificações e o histórico comprovado das pessoas que fazem o trabalho, a cadência dos trabalhos e as exigências de independência que seus padrões impõem. Numa empresa regulada, o PCI DSS e regimes semelhantes podem forçar testes externos independentes, não importa quão boa seja a equipe interna. No governo, as regras de contratação e a necessidade de mostrar uma avaliação a distância antes de uma autorização para operar muitas vezes tornam obrigatório, e não opcional, um terceiro credenciado.
Temos um canal seguro para pesquisadores externos relatarem vulnerabilidades, e estamos prontos para tratar o que chega? Uma grande organização voltada ao público já está sendo sondada por pesquisadores, quer os convide ou não, e a única pergunta é se eles conseguem contar a vocês com segurança ou são forçados a publicar ou vender o que acham. A consideração concorrente é a prontidão: abrir uma política de divulgação coordenada ou um bug bounty pago gera relatos de entrada e um ônus de triagem, e um programa que paga por achados que nunca corrige é pior que nenhum. Levem o arquivo security.txt atual e o endereço de relatos, se houver, o processo de recebimento e de triagem, os prazos de resposta que vocês podem honestamente prometer e a capacidade do backlog para remediar o que chega. Para as agências governamentais, uma política de divulgação de vulnerabilidades em sistemas públicos é cada vez mais uma diretiva e não uma cortesia, e para as empresas um bounty bem conduzido é tanto uma fonte de achados criativos quanto evidência de maturidade na diligência prévia dos clientes, então a decisão é menos se ter um canal do que se vocês têm gente para honrá-lo.

Perspectiva por setor

Startup. Vocês não podem bancar um red team interno, então sobreponham cobertura barata. Liguem a varredura de vulnerabilidades ao pipeline de implantação para pegar falhas conhecidas de dependências a cada build, publiquem um arquivo security.txt e uma simples política de divulgação coordenada para que os pesquisadores consigam alcançá-los e contratem um único teste de intrusão de caixa-cinza de uma empresa respeitável antes do primeiro negócio corporativo, acompanhando cada achado até uma correção confirmada. A velocidade importa mais que um programa amplo: escolham o único teste que destrava uma venda ou fecha o seu maior risco e pulem o resto até crescerem.

Pequena empresa. Sem especialista em segurança na equipe e com orçamento apertado, comprem em vez de construir. Usem um serviço gerenciado de varredura e contratem uma empresa externa de testes de intrusão numa cadência modesta em vez de montar qualquer capacidade interna e garantam que o contrato inclua um reteste para que “corrigido” seja provado e não presumido. O seu movimento de maior valor e menor custo é um jeito publicado de qualquer pessoa relatar uma falha mais a disciplina de corrigir depressa, já que a maior parte do comprometimento real de um negócio do seu tamanho vem de fraquezas conhecidas e sem correção.

Grande empresa. Em escala o desafio é a governança entre muitas equipes. Conduzam varredura contínua sob testes externos independentes periódicos que satisfaçam padrões como o PCI DSS, mantenham um red team interno para emulação contínua de adversários e purple teaming e gerenciem a remediação como um portfólio acompanhado, com donos, prazos baseados em risco e reteste obrigatório. Devolvam toda técnica não detectada à engenharia de detecção e produzam a evidência de auditoria, cobertura, prazos e taxas de fechamento que a conformidade e o seu conselho esperam.

Governo. As regras de contratação, a transparência e a responsabilização pública moldam todo o programa. Mantenham uma política de divulgação de vulnerabilidades nos sistemas voltados ao público, como as diretivas exigem cada vez mais, usem avaliadores independentes credenciados para os testes de intrusão que condicionam a autorização para operar de um sistema e modelem a emulação de adversários nos atores específicos de Estados-nação que seus parceiros de inteligência sinalizam. Tratem a autorização, o escopo e o tratamento de dados com rigor extra porque os sistemas conduzem eleições, benefícios e infraestrutura crítica, e façam do reteste uma pré-condição para manter qualquer sistema no ar.

Exemplos

Startup. Uma fintech de vinte pessoas não pode bancar um red team interno, então sobrepõe o que consegue. A varredura automatizada de vulnerabilidades roda em cada implantação pelo pipeline, pegando cedo as falhas conhecidas de dependências. Ela publica um arquivo security.txt e uma simples política de divulgação coordenada e depois abre um modesto bug bounty numa plataforma pública quando o produto se estabiliza, pagando pesquisadores reais por bugs reais. Antes de assinar o primeiro cliente corporativo, contrata um teste de intrusão de caixa-cinza da aplicação de uma empresa respeitável, acompanha cada achado até o fechamento no rastreador de problemas normal e paga um reteste para confirmar as correções. Essa abordagem em camadas dá uma cobertura de segurança crível a um custo que a startup consegue sustentar, e o relatório do teste de intrusão vira evidência que ela pode compartilhar na diligência prévia dos clientes.

Grande empresa. Uma varejista multinacional que processa pagamentos com cartão precisa atender ao PCI DSS, que exige testes de intrusão internos e externos ao menos uma vez por ano e depois de mudanças significativas, além de testes de segmentação para provar que o ambiente dos portadores de cartão está isolado. Ela roda varredura contínua em milhares de ativos, contrata testes externos independentes de intrusão para satisfazer o padrão e mantém um red team interno que conduz exercícios de violação presumida ancorados no MITRE ATT&CK contra atores de ameaça conhecidos por visar o varejo. O red team trabalha de perto com a função de operações de segurança do capítulo 4.4: toda técnica não detectada vira um chamado de engenharia de detecção, e sessões trimestrais de purple team ajustam os alertas. A remediação é acompanhada com prazos baseados em risco, e todo o programa produz a evidência de auditoria que a conformidade do capítulo 4.6 exige.

Governo. Uma agência nacional que opera sistemas de benefícios aos cidadãos enfrenta adversários de Estados-nação e um mandato público de proteger dados pessoais sensíveis. Ela mantém uma política de divulgação de vulnerabilidades em todos os sistemas voltados ao público, como as diretivas governamentais exigem cada vez mais, dando aos pesquisadores um canal seguro para relatar falhas. Avaliadores independentes terceirizados conduzem testes de intrusão como parte do processo de autorização antes de qualquer sistema entrar no ar, e o monitoramento contínuo inclui varredura contínua. A agência conduz emulação de adversários modelada nos grupos de ameaça específicos que seus parceiros de inteligência sinalizam, e exercícios de mesa regulares ensaiam a resposta a incidentes e a coordenação jurídica que uma violação real demandaria. Os achados alimentam um programa formal de remediação com prazos obrigatórios, e o reteste é pré-condição para manter a autorização para operar de um sistema.

Justificativa de negócio: motivações, ROI e TCO

O retorno da segurança ofensiva é a violação que vocês não sofreram. Uma violação grave de dados custa milhões em resposta direta, multas regulatórias, responsabilidade jurídica, evasão de clientes e dano de reputação, e o fator isolado mais caro é por quanto tempo uma intrusão passa sem ser detectada. O red teaming e o purple teaming atacam esse número diretamente, encolhendo a distância entre o comprometimento e a detecção. Um teste de intrusão que acha um caminho explorável até o seu banco de dados de clientes, corrigido antes que um atacante o ache, paga o programa inteiro muitas vezes numa única violação evitada.

Há também motivadores duros. O PCI DSS exige testes de intrusão de quem trata dados de cartões. Os frameworks e os regimes de autorização governamentais exigem avaliação independente antes e durante a operação. Os clientes corporativos exigem relatórios recentes de testes de intrusão como condição de contratos. Nesses casos o teste não é opcional, e a pergunta é só se vocês extraem valor real de segurança de um dinheiro que precisam gastar de qualquer modo.

O custo total de propriedade inclui mais que a taxa do trabalho. Orcem as ferramentas e o pessoal de uma equipe interna, se vocês a constroem, o ônus de triagem de um bug bounty e, acima de tudo, o trabalho de remediação que os achados geram, que é onde cai o gasto real. Um programa que contrata testes mas subfinancia a correção é o pior dos dois mundos: paga pelas más notícias e depois paga de novo quando o achado ignorado é explorado. Para defender o caso junto à liderança, liguem o teste às métricas que ela acompanha: o tempo médio de detecção, o tempo médio de remediação, os achados de auditoria fechados e a redução de risco nos seus ativos mais críticos.

Antipadrões e armadilhas

Varrer e rebatizar: vender uma varredura de vulnerabilidades como teste de intrusão, entregando a saída de uma ferramenta sem validação humana nem encadeamento de explorações.
Relatar e esquecer: tratar o produto entregue como o objetivo, arquivar os achados e nunca acompanhar a remediação nem o reteste.
Escopo para passar: estreitar o trabalho para que os sistemas com maior probabilidade de falhar estejam convenientemente fora dos limites, produzindo um relatório limpo que não significa nada.
Red team como placar: uma equipe adversarial que acumula técnicas e celebra vitórias em vez de tornar os defensores melhores.
Testar às escondidas um blue team imaturo: rodar um red team furtivo antes de ter qualquer capacidade de detecção, de modo que o exercício prova apenas o que vocês já sabiam.
Sem autorização ou com escopo vago: começar o trabalho sem permissão por escrito ou deixar o escopo escorregar para sistemas que vocês não possuem, flertando com um desastre jurídico.
Obsessão pelo perímetro: testar apenas a borda externa e ignorar a realidade da violação presumida, de que os atacantes começam por dentro.
Ignorar o canal de divulgação: não ter jeito seguro para pesquisadores externos relatarem bugs, de modo que eles publicam em público ou vendem.
Métricas de teatro: contar as vulnerabilidades achadas em vez do risco reduzido, da detecção melhorada e do tempo de remediação encurtado.

Modelo de maturidade

Nível 1, Iniciar: O teste é ocasional e reativo, muitas vezes um único teste de intrusão anual feito para marcar uma caixa, ou disparado apenas depois de um incidente. Os relatórios são arquivados com pouco acompanhamento, a remediação não é acompanhada, não há canal de divulgação e a detecção de uma intrusão real não é testada e provavelmente ausente.
Nível 2, Desenvolver: Existem varredura de vulnerabilidades e testes de intrusão, mas são inconsistentes entre as equipes, com alguns grupos varrendo continuamente e outros nem um pouco. Os achados são capturados em algum lugar, embora donos e prazos sejam irregulares, o reteste seja ad hoc e um canal de divulgação coordenada possa existir para alguns sistemas mas não para o parque inteiro.
Nível 3, Padronizar: O teste ofensivo é um programa documentado e imposto em toda a organização, não um evento. A varredura roda continuamente sob testes de intrusão agendados, contratados numa cadência definida e depois de grandes mudanças, as regras de engajamento e a autorização são prática padrão, todo achado é acompanhado até o fechamento com um dono e um prazo baseado em risco, o reteste é obrigatório e uma política de divulgação coordenada cobre todos os sistemas voltados ao público.
Nível 4, Gerenciar: O programa é medido e controlado em relação a linhas de base. Vocês acompanham o tempo médio de detecção e o tempo médio de remediação, a porcentagem de técnicas do red team que produziram um sinal, a cobertura de detecção contra as técnicas do MITRE ATT&CK relevantes ao seu setor, as taxas de reincidência de achados e os tempos de resposta da divulgação, e cada métrica é mantida contra uma meta e age-se quando ela deriva. Os exercícios de violação presumida e a emulação de adversários são rotina, um red team opera continuamente, os achados alimentam a engenharia de detecção e as decisões de seguir ou não repousam em evidências e não em opinião.
Nível 5, Orquestrar: O red teaming e o purple teaming são integrados em toda a organização e adaptativos. Cada técnica mapeia para uma detecção testada, a emulação de adversários acompanha os atores de ameaça específicos que visam o seu setor no momento, à medida que a inteligência muda, e o programa refina continuamente seu escopo, técnicas e métricas à medida que aprende. O teste ofensivo, as operações de segurança, a engenharia de detecção e a resposta a incidentes operam como um único ciclo que encolhe mensuravelmente com o tempo a distância entre o comprometimento e a detecção.

Ideias para discussão

Se um atacante real conseguisse uma brecha como funcionário comum hoje, até onde ele poderia chegar antes de alguém notar, e como vocês sabem?
Quais dos seus últimos trabalhos foram genuinamente realistas, e quais foram delimitados para que as prováveis falhas ficassem convenientemente fora dos limites?
Quantos achados do teste anterior ainda estão em aberto, e o que isso diz sobre se o teste ou a remediação é o seu gargalo real?
Os pesquisadores externos têm um jeito seguro e óbvio de relatar uma vulnerabilidade a vocês, e o que acontece quando um relato chega?
Quando os seus respondentes de incidentes ensaiaram uma violação no papel pela última vez, e o exercício de mesa expôs lacunas que os testes técnicos perderam?
Vocês estão medindo as vulnerabilidades achadas, ou estão medindo a detecção melhorada e o risco reduzido?

Principais conclusões

A segurança ofensiva é um espectro: a varredura acha falhas conhecidas, o teste de intrusão prova a explorabilidade e o red teaming testa a detecção e a resposta. Combinem o trabalho com a pergunta.
A autorização por escrito e as regras claras de engajamento são a linha entre o teste de segurança e o crime. Nunca as pulem, especialmente em sistemas que vocês não possuem por completo.
O valor está na remediação e no reteste, não no relatório. Acompanhem cada achado com um dono, um prazo baseado em risco e uma correção confirmada.
Um red team existe para tornar o blue team melhor. Devolvam os achados à engenharia de detecção, favoreçam o purple teaming e os exercícios de violação presumida e ancorem as campanhas em técnicas reais de adversários por meio do MITRE ATT&CK.
Meçam a detecção e a resposta, não apenas as contagens de vulnerabilidades, e cuidado com trabalhos delimitados para passar, que produzem conforto sem segurança.

Referências e leitura complementar

Georgia Weidman, Penetration Testing: A Hands-On Introduction to Hacking
Peter Kim, The Hacker Playbook 3: Practical Guide to Penetration Testing
Jim O’Gorman, Devon Kearns, and Mati Aharoni, Metasploit: The Penetration Tester’s Guide
Joe Vest and James Tubberville, Red Team Development and Operations: A Practical Guide
MITRE, MITRE ATT&CK framework and knowledge base
Payment Card Industry Security Standards Council, PCI DSS Requirements and Testing Procedures and Penetration Testing Guidance
National Institute of Standards and Technology, NIST SP 800-115: Technical Guide to Information Security Testing and Assessment
Dafydd Stuttard and Marcus Pinto, The Web Application Hacker’s Handbook