Antes de qualquer exigência regulatória cair sobre a mesa de um CISO, existe normalmente um movimento silencioso para entender do que se trata. Essa busca por clareza reflete gestores, times técnicos e áreas de compliance tentando dominar um conceito que, para o setor financeiro brasileiro, deixou de ser apenas uma boa prática e virou controle auditável.
Como já detalhamos em outro artigo sobre as Resoluções CMN nº 5.274/2025 e BCB nº 538/2025, o teste de intrusão anual, conduzido por profissionais independentes, é hoje um dos 14 controles mínimos de cibersegurança que o Banco Central pode cobrar de instituições financeiras, instituições de pagamento, corretoras e distribuidoras. Mas antes de discutir os detalhes da exigência, vale a pergunta fundamental: afinal, o que é um pentest?
O que é, de fato, um teste de intrusão
Um teste de intrusão, ou pentest, é uma simulação controlada e autorizada de um ataque real contra sistemas, redes ou aplicações de uma organização, com o objetivo de identificar vulnerabilidades exploráveis antes que um agente malicioso o faça. A palavra “autorizada” carrega peso técnico e jurídico: diferente de um ataque real, o pentest só ocorre dentro de um escopo formalmente definido, com regras de engajamento, janelas de execução e limites claros sobre o que pode e o que não pode ser tocado.
O objetivo não é apenas encontrar falhas, mas demonstrar o impacto real que cada uma delas teria se explorada por um invasor. É essa demonstração prática, e não apenas a listagem teórica de riscos, que diferencia um pentest de outras formas de avaliação de segurança.
Pentest não é a mesma coisa que um scan de vulnerabilidades
Um dos equívocos mais comuns, inclusive entre times técnicos, é tratar pentest e scan automatizado de vulnerabilidades como sinônimos. Não são. Um scan de vulnerabilidades é um processo automatizado que varre sistemas em busca de falhas conhecidas, comparando o ambiente a bases de dados de vulnerabilidades já catalogadas, e entrega como resultado uma lista de achados.
O pentest parte desse ponto e vai além: um profissional especializado explora ativamente as falhas encontradas, testando se e como elas podem, na prática, ser encadeadas para obter acesso não autorizado, escalar privilégios ou movimentar-se lateralmente dentro do ambiente. É a diferença entre saber que uma porta está destrancada e efetivamente verificar o que existe do outro lado dela. Por isso a exigência regulatória menciona explicitamente “profissionais independentes”: a validação de um pentest depende de julgamento humano, criatividade ofensiva e experiência técnica, elementos que uma ferramenta automatizada, isoladamente, não reproduz.
Pentest também não deve ser confundido com exercícios de Red Team. Embora ambos utilizem técnicas ofensivas, seus objetivos são distintos. O pentest busca identificar e validar vulnerabilidades exploráveis dentro de um escopo previamente definido, avaliando tecnicamente a segurança de ativos específicos. Já uma operação de Red Team simula um adversário real durante toda a cadeia de ataque, podendo envolver engenharia social, comprometimento de credenciais, evasão de controles, persistência, movimentação lateral e exfiltração de dados, com foco em medir a capacidade de detecção e resposta da organização. Em termos práticos, o pentest responde à pergunta “é possível explorar?”, enquanto o Red Team procura responder “até onde um invasor conseguiria chegar?”.
Os três modelos mais comuns de pentest
A escolha do modelo de teste depende diretamente do que a organização quer simular e de quanto conhecimento prévio do ambiente será compartilhado com o time de execução. No modelo black box, o profissional não recebe nenhuma informação privilegiada sobre a infraestrutura, replicando a perspectiva de um atacante externo que precisa mapear o ambiente do zero, exatamente como faria um adversário real na fase inicial de reconhecimento.
Já o modelo grey box parte de um conhecimento parcial, geralmente credenciais de usuário comum ou documentação básica da arquitetura, simulando cenários como o de um colaborador com acesso limitado ou um fornecedor comprometido. É o modelo mais utilizado quando o objetivo é equilibrar profundidade técnica com tempo de execução.
Por fim, o modelo white box concede acesso total ao ambiente, incluindo código-fonte, diagramas de rede e credenciais administrativas. É o teste mais profundo e demorado, indicado quando a organização precisa validar exaustivamente sistemas críticos, como os que sustentam Pix e Sistema de Transferência de Reservas (STR), justamente os ambientes que a regulação do Banco Central trata com maior rigor.
Os frameworks que sustentam um pentest tecnicamente sólido
Um teste de intrusão sério não nasce de um roteiro improvisado. Ele se apoia em metodologias reconhecidas internacionalmente, que dão consistência, comparabilidade e defensabilidade técnica ao processo. O Guia de Testes da OWASP orienta a avaliação de vulnerabilidades em aplicações web, cobrindo desde falhas de autenticação até problemas de lógica de negócio. O MITRE ATT&CK® fornece uma matriz estruturada de táticas, técnicas e procedimentos (TTPs) reais usados por adversários, permitindo que o pentest simule comportamentos de ameaças documentadas em vez de ataques genéricos.
Já o NIST SP 800-115, “Technical Guide to Information Security Testing and Assessment”, publicado pelo National Institute of Standards and Technology, estabelece a estrutura técnica para planejamento, execução, análise de achados e elaboração de estratégias de mitigação, servindo como referência metodológica amplamente adotada tanto por órgãos federais quanto pelo setor privado. É justamente a aderência a esse conjunto de referências, e não apenas a execução de um teste isolado, que a Resolução CMN nº 5.274/2025 exige ao mencionar “metodologia reconhecida” como requisito para conformidade.
Além dessas referências, muitas equipes especializadas adotam o Penetration Testing Execution Standard (PTES) como metodologia para estruturar todas as fases do teste de intrusão, desde o pré-engajamento até a entrega do relatório final. Outro framework amplamente reconhecido é o OSSTMM (Open Source Security Testing Methodology Manual), que fornece critérios objetivos para avaliação da segurança operacional de redes, aplicações, pessoas, processos e comunicações. A utilização dessas metodologias aumenta a padronização, a rastreabilidade e a repetibilidade dos testes.
O ciclo de vida de um pentest: da autorização ao relatório
Independentemente do modelo escolhido, um pentest segue uma lógica sequencial. A fase de planejamento define escopo, regras de engajamento, janelas de teste e critérios de sucesso, documentação que, sob a nova regulação, precisa ser preservada e disponibilizada ao regulador quando solicitada. Em seguida, a descoberta mapeia ativos, serviços expostos, versões de sistemas e possíveis pontos de entrada, combinando reconhecimento automatizado com investigação manual, etapa em que ativos esquecidos, como servidores de desenvolvimento não descomissionados, costumam aparecer.
A fase de ataque controlado é onde a exploração ativa acontece: o profissional tenta, dentro dos limites acordados, transformar vulnerabilidades teóricas em comprometimento real, validando o que de fato representa risco e descartando falsos positivos que ferramentas automatizadas frequentemente geram. Por fim, o relatório consolida achados classificados por criticidade, evidências técnicas do que foi explorado e recomendações de correção, associadas a um plano de ação formal com prazos e responsáveis, exatamente o documento que passa a ser objeto de fiscalização.
Não é coincidência que essa sequência, planejamento, descoberta, ataque e relatório, seja também a lógica por trás da metodologia própria que a Asper aplica em seus projetos, construída com base em frameworks consagrados no mercado, como o Guia de Testes OWASP, o MITRE ATT&CK® e o NIST SP 800-115.
De boa prática a controle auditável para o setor financeiro
Até recentemente, a decisão de contratar um pentest anual dependia essencialmente da maturidade de segurança de cada organização. Isso mudou. As Resoluções CMN nº 5.274/2025 e BCB nº 538/2025 tornaram o teste de intrusão, realizado ao menos uma vez por ano por profissionais independentes, um dos 14 controles mínimos de cibersegurança exigíveis de instituições financeiras, instituições de pagamento, corretoras e distribuidoras autorizadas a funcionar pelo Banco Central.
A norma não exige apenas a execução do teste: exige documentação do escopo, uso de metodologia reconhecida, classificação de criticidade das vulnerabilidades encontradas e um plano de ação formal com prazos e responsáveis, tudo isso preservado por até cinco anos à disposição do regulador. Como exploramos com mais profundidade no artigo sobre os 14 controles mínimos, a fiscalização já não avalia se existe uma política de segurança no papel, mas se a instituição consegue provar, tecnicamente, que o controle funciona.
A limitação natural de um pentest, e por que ela importa
Um teste de intrusão, mesmo o mais rigoroso, retrata a postura de segurança de um ambiente em um momento específico. Entre um pentest anual e o próximo, novas vulnerabilidades surgem, configurações mudam e novos ativos entram em produção, uma janela de exposição que a exigência regulatória de periodicidade anual não elimina sozinha.
É por isso que a resposta mais consistente combina a profundidade do pentest pontual com validação contínua e automatizada entre um ciclo e outro. O time de profissionais da Asper executa pentests black box, grey box e white box com metodologia própria alinhada a OWASP, MITRE ATT&CK e NIST SP 800-115, entregando não apenas a lista de vulnerabilidades, mas a evidência técnica e o plano de ação que a regulação exige. Já a plataforma Cymulate, de simulação de violações e ataques (BAS), complementa esse trabalho testando de forma automatizada e recorrente se os controles de segurança seguem eficazes nos meses entre um pentest e outro, reduzindo a distância entre a fotografia pontual e a postura de segurança real do ambiente ao longo do tempo.
É importante destacar que nenhum teste de intrusão consegue garantir a inexistência de vulnerabilidades em um ambiente. Seus resultados refletem o escopo definido, o tempo disponível para execução e a superfície de ataque analisada naquele momento. Dessa forma, o pentest deve ser entendido como um mecanismo de validação técnica da postura de segurança, e não como uma certificação de que o ambiente está completamente protegido.
Entender o conceito é o primeiro passo, não o último
Saber o que é um pentest, diferenciá-lo de um scan automatizado e reconhecer os modelos e frameworks que sustentam um teste sério é o ponto de partida para qualquer CISO, CTO ou área de compliance que precise responder, hoje, se sua instituição está pronta para comprovar esse controle específico diante do Banco Central. O próximo passo é técnico: definir escopo, escolher o modelo adequado à criticidade do ambiente e garantir que o time responsável tenha, de fato, a independência que a norma exige.
Quer entender qual modelo de pentest faz mais sentido para o seu ambiente e como estruturar essa exigência dentro da sua governança de segurança? Fale com o time de especialistas da Asper.
