Por que comparar metodologias de Pentest
Toda metodologia de Pentest existe para dar forma ao teste. Ela organiza etapas, critérios, profundidade, documentação e análise dos achados. Adotar uma metodologia reconhecida tem três efeitos práticos para a empresa: define o que será testado, em que profundidade e com qual critério o resultado pode ser comparado entre engajamentos.
Na prática, isso evita três problemas comuns:
- Testes conduzidos sem padrão.
- Relatórios difíceis de comparar entre ciclos.
- Achados técnicos desconectados do risco real para o negócio.
Quando a empresa adota uma metodologia consistente, o Pentest deixa de ser uma fotografia isolada do ambiente. Ele passa a integrar uma jornada de cibersegurança, com histórico, evolução, indicadores e evidências.
Conformidade regulatória
Empresas reguladas precisam comprovar que testam, documentam e tratam vulnerabilidades com método. A metodologia ajuda a transformar o teste em evidência auditável.
Comparabilidade entre ciclos
Com um padrão consistente, a empresa consegue comparar evolução, recorrência de falhas, tempo de correção, maturidade dos controles e redução da exposição ao longo do tempo.
Maturidade do programa de segurança
Empresas em estágio inicial podem começar com abordagens mais objetivas, como OWASP para aplicações web e APIs. Ambientes mais complexos e regulados tendem a combinar PTES, OWASP, NIST, MITRE ATT&CK e CVSS em ciclos coordenados.
O ponto central é simples: metodologia não é burocracia. É o que transforma teste técnico em gestão de risco.
PTES — Penetration Testing Execution Standard
O Penetration Testing Execution Standard (PTES) é uma proposta de padronização das fases de execução de um Pentest, desenvolvida pela comunidade de Pentesters profissionais. O objetivo é estabelecer uma estrutura comum que possa ser adaptada a qualquer escopo, em qualquer setor.
O PTES organiza o engajamento em sete fases formais:
Pré-engajamento
É a fase de definição do teste. Nela são estabelecidos escopo, regras de engajamento, ativos incluídos e excluídos, janela de execução, contatos de emergência, limites técnicos, confidencialidade e autorização formal. Essa etapa é decisiva.
Coleta de inteligência
Nesta fase, o time reúne informações sobre o alvo. Isso pode incluir domínios, subdomínios, IPs, tecnologias utilizadas, serviços expostos, pessoas vinculadas à organização, registros públicos e outros sinais úteis para mapear a superfície de ataque.
Modelagem de ameaças
Com as informações coletadas, o time avalia quais ativos são mais críticos, quais vetores fazem sentido e quais perfis de adversário são mais prováveis. Essa etapa aproxima o Pentest de um cenário real.
Análise de vulnerabilidades
Aqui são identificadas falhas técnicas, configurações inseguras, permissões indevidas, exposição de serviços, problemas de autenticação, vulnerabilidades em aplicações e outras fragilidades.
Exploração
A exploração diferencia o Pentest de uma análise comum de vulnerabilidades. Nesta fase, o Pentester valida se uma falha pode ser explorada de forma prática, controlada e segura.
Pós-exploração
Depois de obter algum nível de acesso, o time avalia o que seria possível fazer a partir dali: escalar privilégios, acessar dados, movimentar-se lateralmente, alcançar sistemas críticos ou simular exfiltração.
Relatório
O relatório consolida achados, evidências, criticidade, impactos e recomendações de correção. Um bom relatório precisa falar a linguagem técnica e a linguagem executiva.
Quando usar PTES?
O PTES é uma metodologia agnóstica de alvo. É indicado como estrutura base para praticamente qualquer Pentest. Funciona como espinha dorsal de qualquer engajamento, do Pentest de rede ao Pentest de aplicações em nuvem ou sistemas com IA. Pode ser aplicado a redes, aplicações, APIs, nuvem, ambientes híbridos e sistemas críticos.
Sua principal força está na organização do engajamento. Por outro lado, ele não substitui guias especializados. Em aplicações web, costuma ser combinado com OWASP. Em infraestrutura, pode ser complementado por NIST. Em relatórios mais maduros, é comum integrar MITRE ATT&CK e CVSS.
Limitações: o padrão define o que cada fase entrega, mas não prescreve ferramentas ou técnicas específicas. Empresas que adotam o PTES costumam combiná-lo com OWASP (camada de aplicação), NIST (camada técnica) e MITRE ATT&CK (catalogação das técnicas observadas).
NIST — SP 800-115 e CSF 2.0
O Instituto Nacional de Padrões e Tecnologia dos Estados Unidos (NIST) mantém dois artefatos relevantes para Pentest, com escopos distintos.
NIST SP 800-115 — guia técnico de testes
A Special Publication 800-115 (Technical Guide to Information Security Testing and Assessment) é o guia técnico de execução de testes de segurança publicado pelo NIST. Cobre planejamento, execução e análise dos resultados em três grandes categorias de avaliação: revisão (análise documental e de configuração), identificação de alvo e análise de vulnerabilidade, e validação por exploração.
O documento foi publicado em 2008 e permanece em uso como referência técnica nos Estados Unidos e em normas equivalentes ao redor do mundo. Frameworks de conformidade como HIPAA, FISMA e FedRAMP referenciam o SP 800-115 como base de execução.
Onde se aplica: testes de infraestrutura de rede, sistemas e endpoints, especialmente em organizações sujeitas a normas que exigem aderência ao padrão NIST.
NIST CSF 2.0 — framework de governança
O NIST Cybersecurity Framework (CSF) atingiu a versão 2.0 em 2024 e não trata especificamente de execução de Pentest, mas estabelece o contexto de governança em que o Pentest se insere. A versão 2.0 organiza cibersegurança em seis funções core:
- Govern: governança e gestão do programa de cibersegurança.
- Identify: identificação de ativos, riscos e dependências.
- Protect: implementação de controles preventivos.
- Detect: monitoramento e identificação de incidentes.
- Respond: resposta a incidentes.
- Recover: recuperação após incidente.
O Pentest aparece como atividade dentro de Identify (mapeamento de vulnerabilidades) e Protect (validação dos controles em operação).
OWASP — família completa de recursos
A Open Web Application Security Project (OWASP) é a referência mundial para segurança em aplicações web, APIs e mobile. Mais relevante do que tratá-la como uma metodologia única é entender a família de recursos que ela mantém.
OWASP Top 10:2025
A versão de 2025 do OWASP Top 10 traz duas mudanças relevantes: A03 — Software Supply Chain Failures e A10 — Mishandling of Exceptional Conditions. Security Misconfiguration subiu para a segunda posição.
OWASP Web Security Testing Guide (WSTG)
Manual técnico com procedimentos detalhados para testar aplicações web. Funciona como complemento ao Top 10: enquanto o Top 10 lista os riscos, o WSTG descreve como testar cada categoria.
OWASP Mobile Application Security Testing Guide (MASTG)
Equivalente do WSTG para aplicações Android e iOS. Cobre análise estática, dinâmica, reverse engineering e testes de segurança de comunicação com backend.
OWASP API Security Top 10
Documento dedicado às vulnerabilidades específicas de APIs (REST, GraphQL, SOAP). Inclui BOLA, BFLA e Unrestricted Resource Consumption, entre outras categorias.
OWASP ASVS
Padrão de verificação de segurança em três níveis de exigência (L1, L2, L3). É um checklist auditável usado em contratos, certificações e auditorias regulatórias.
Onde se aplica: qualquer Pentest em camada de aplicação. O OWASP Top 10 é a porta de entrada; o WSTG, MASTG e API Top 10 estruturam a execução; o ASVS dá o critério de validação.
OSSTMM — Open Source Security Testing Methodology Manual
O OSSTMM é o manual mantido pelo Institute for Security and Open Methodologies (ISECOM). É reconhecido pela abordagem rigorosa e quantitativa: define métricas de segurança (Risk Assessment Values) calculadas a partir do que o teste observa, em vez de scores genéricos.
A versão 3 do manual, atualmente em uso, cobre cinco canais de teste:
- Segurança humana: engenharia social, phishing, processos de atendimento.
- Segurança física: controle de acesso, perímetro físico.
- Segurança em telecomunicações: voz, vídeo, dispositivos móveis.
- Segurança de redes de dados: infraestrutura de rede.
- Segurança wireless: Wi-Fi, Bluetooth, RFID, IoT.
Onde se aplica: auditorias de segurança que precisam de rigor metodológico documental e métrica de risco quantificável. Comum em ambientes governamentais e industriais, e em projetos de pesquisa acadêmica.
Limitações: documento denso, com curva de aprendizado elevada. Menos popular no mercado brasileiro de Pentest comercial, onde OWASP e PTES dominam.
ISSAF — framework legado
O Information Systems Security Assessment Framework (ISSAF) foi mantido pelo Open Information Systems Security Group (OISSG). O framework propunha uma estrutura ampla de avaliação dividida em quatro fases: planejamento e preparação, avaliação, relatório e limpeza. Cada fase era detalhada em centenas de páginas de procedimentos.
O OISSG perdeu atividade pública por volta da metade da década de 2010 e o ISSAF deixou de receber atualizações sistemáticas. O documento ainda é citado em auditorias antigas, comparativos acadêmicos e bibliografia técnica, mas raramente é adotado isoladamente em engajamentos atuais.
Onde aparece em 2026: referências históricas, comparativos de metodologias, auditorias que mantêm artefatos antigos.
MITRE ATT&CK e CVSS — frameworks transversais
ATT&CK e CVSS são padrões transversais que se acoplam a qualquer metodologia de Pentest. Aplicam-se durante e depois do teste, em qualquer metodologia escolhida, complementando o resultado com taxonomia de técnicas e classificação de risco.
MITRE ATT&CK
Base de conhecimento da MITRE Corporation que cataloga táticas, técnicas e procedimentos (TTPs) usados por adversários reais em incidentes documentados. Em Pentest, o ATT&CK é usado para mapear as técnicas observadas no engajamento contra TTPs conhecidos.
CVSS
Padrão aberto mantido pelo FIRST para classificar a criticidade de vulnerabilidades em escala de 0 a 10. Em Pentest, o CVSS é o padrão de fato para classificar risco de cada vulnerabilidade encontrada.
Como escolher a metodologia certa
A escolha da metodologia é em função de quatro variáveis práticas.
| Critério | O que considerar |
|---|---|
| Tipo de ativo | Aplicações web, APIs e mobile → OWASP. Infraestrutura, rede e endpoints → NIST SP 800-115 e PTES. Multicanal (física, humana, rede) → OSSTMM. |
| Exigência regulatória | Setor financeiro brasileiro (BCB 538/2025) → metodologia documentada, em geral PTES e OWASP. Conformidade com normas internacionais (PCI DSS, FedRAMP) → NIST como referência. |
| Maturidade da operação | Programa inicial → OWASP em aplicações com PTES como estrutura. Programa maduro → combinação de PTES, OWASP, NIST e ASVS em ciclos coordenados. |
| Comparabilidade entre ciclos | Manter a mesma metodologia ao longo do tempo. Mudar de framework a cada engajamento elimina a possibilidade de medir evolução. |
Na prática, equipes profissionais combinam mais de uma metodologia: PTES define a estrutura do engajamento, OWASP cobre a camada de aplicação, NIST sustenta a documentação técnica, MITRE ATT&CK mapeia as técnicas e CVSS classifica o risco.
Para programas em modelo Pentest as a Service, os critérios práticos de escolha de provedor estão detalhados em Pentest as a Service: como avaliar provedor.
Metodologia e exigências regulatórias em 2026
A entrada do Pentest no campo da conformidade regulatória trouxe expectativas explícitas sobre como o teste é conduzido e como o resultado é entregue.
Setor financeiro
A Resolução BCB nº 538/2025, em conjunto com a Resolução CMN nº 5.274/2025, exige testes de intrusão periódicos em instituições financeiras supervisionadas pelo Banco Central a partir de março de 2026, com documentação dos resultados, planos de correção formalizados e supervisão equivalente sobre fornecedores.
A norma não prescreve uma metodologia específica, mas a expectativa de auditoria é que o teste siga padrão reconhecido (PTES, OWASP, NIST), classifique vulnerabilidades em CVSS e produza relatório auditável. O escopo prático da adequação está detalhado em Pentest para o setor financeiro: o que muda com a exigência do Banco Central, e o conjunto maior de controles exigidos pelo BC está consolidado em Novas regras de cibersegurança para o setor financeiro. O passo seguinte ao teste, o plano de remediação, está detalhado em Relatório, evidências e plano de ação após o Pentest.
Setor saúde
A Resolução CFM nº 2.454/2026 estabelece controles de cibersegurança e governança de dados para hospitais, clínicas e healthtechs, com prazo de adequação em agosto de 2026 e atenção especial ao uso de inteligência artificial em decisão médica. A leitura institucional da norma está em IA e cibersegurança na saúde.
A conformidade depende de dois requisitos práticos. O primeiro é uma base de segurança da informação consolidada, com criptografia, controle de acesso baseado em perfis, monitoramento contínuo e testes de intrusão periódicos. O segundo é uma infraestrutura de TI preparada para sustentar rastreabilidade, controle granular de acessos e registros auditáveis. O Pentest entra como o controle técnico que valida se essas duas camadas funcionam diante de uma tentativa real de exploração.
Em termos de metodologia, OWASP (camada de aplicação e API) e NIST SP 800-115 (infraestrutura) são as referências mais utilizadas, complementadas por mapeamento em MITRE ATT&CK quando o ambiente inclui sistemas com IA.
Pentest as a Service estruturado em OWASP, PTES, NIST e MITRE ATT&CK
Em modelos de Pentest as a Service, a metodologia se torna ainda mais relevante.
Como os testes deixam de ser eventos isolados e passam a compor uma jornada contínua de validação, é preciso garantir que cada ciclo seja comparável, rastreável e tecnicamente consistente.
Isso exige:
- Escopo bem definido.
- Critérios de teste claros.
- Evidências organizadas.
- Classificação padronizada de risco.
- Retestes documentados.
- Relatórios técnicos e executivos.
- Histórico de evolução entre ciclos.
Outro ponto relevante é a independência do teste. Quando conduzido por especialistas externos à empresa, o Pentest funciona como uma validação independente da postura de segurança. Na prática, aproxima-se da lógica de uma auditoria externa: um terceiro qualificado avalia o ambiente, documenta evidências e aponta riscos que podem não estar visíveis para quem opera a infraestrutura todos os dias.
Para empresas reguladas, essa independência tem valor adicional. Ela reforça imparcialidade, fortalece a credibilidade do relatório e apoia a comprovação de diligência perante auditorias, conselhos e órgãos reguladores.
A Prolinx é provedora de Pentest as a Service para empresas reguladas e organizações com superfície de ataque distribuída, com unidades em Belo Horizonte (MG) e São Paulo (SP) e cobertura nacional em engajamentos remotos e híbridos.
Equipe certificada, metodologias OWASP, PTES e NIST, classificação CVSS, mapeamento MITRE ATT&CK, attestation letter auditável e suporte para conformidade com BCB 538/2025, CFM 2.454/2026, LGPD, ISO/IEC 27001, PCI DSS e SOC 2. A operação é certificada ISO/IEC 27001.
Conhecer o serviço de Pentest as a Service · Falar com a equipe Prolinx
Perguntas frequentes sobre metodologias de Pentest (FAQ)
Qual a melhor metodologia de Pentest?
Não existe uma única melhor. A escolha depende do tipo de ativo, da exigência regulatória, da maturidade da operação e da necessidade de comparabilidade entre ciclos. Para aplicações web e APIs, OWASP é a referência principal. Para infraestrutura e rede, NIST SP 800-115. Como estrutura de engajamento, PTES é a mais usada. Em programas maduros, várias metodologias são combinadas.
Qual a diferença entre NIST SP 800-115 e NIST CSF 2.0?
O SP 800-115 é um guia técnico de execução de testes de segurança, publicado em 2008 e ainda em uso. O CSF 2.0, de 2024, é um framework de governança de cibersegurança organizado em seis funções: Govern, Identify, Protect, Detect, Respond e Recover. O Pentest aparece como atividade dentro das funções Identify e Protect do CSF.
O ISSAF ainda é usado em 2026?
Raramente como metodologia principal. O OISSG, organização que mantinha o ISSAF, perdeu atividade pública por volta da metade da década de 2010. O framework ainda é citado em referências históricas e comparativos acadêmicos, mas não recebe atualizações sistemáticas e é considerado legado no mercado atual.
O que mudou no OWASP Top 10:2025?
Duas mudanças principais. A03, Software Supply Chain Failures, expande a antiga categoria de componentes vulneráveis para cobrir o ecossistema completo de software, incluindo dependências, build e distribuição. A10, Mishandling of Exceptional Conditions, é uma categoria nova sobre tratamento seguro de erros e resiliência. Security Misconfiguration subiu para a segunda posição.
MITRE ATT&CK é uma metodologia de Pentest?
Não. ATT&CK é uma base de conhecimento de táticas e técnicas usadas por adversários reais, mantida pela MITRE Corporation. É usada em conjunto com qualquer metodologia para mapear as técnicas observadas no engajamento, aproximando o teste de um cenário real de ameaça.
CVSS substitui a análise de risco do Pentester?
Não. O CVSS classifica a criticidade técnica de cada vulnerabilidade em escala de 0 a 10, com base em vetor de ataque, complexidade, impacto e outros fatores. A análise de risco completa do Pentester considera também contexto de negócio, exploração encadeada e impacto operacional, que vão além do score isolado.
É possível combinar mais de uma metodologia em um mesmo Pentest?
Sim, é o padrão em engajamentos profissionais. PTES costuma definir a estrutura do engajamento, OWASP cobre a camada de aplicação, NIST sustenta a documentação técnica, MITRE ATT&CK mapeia as técnicas observadas e CVSS classifica o risco. A combinação produz relatórios mais completos e adequados a auditorias regulatórias.
Pentest as a Service com a Prolinx
Se a sua empresa precisa validar controles, estruturar evidências e comparar a evolução da postura de segurança entre ciclos, conheça o Pentest as a Service da Prolinx.