Os necessários fazem o site funcionar. Os outros medem quais páginas ajudam e quais anúncios trazem quem precisa da DM11. Você escolhe, e pode rever pelo rodapé.
PENTEST
Pentest, ou teste de intrusão, é um ataque autorizado e combinado contra os seus sistemas, conduzido por quem faz isso profissionalmente. Ele não devolve uma lista de falhas possíveis: devolve a demonstração do que um invasor conseguiria fazer de fato, com o caminho percorrido, a evidência de cada passo e o que resistiu. É a diferença entre saber que a porta pode estar destrancada e ver alguém entrar por ela.
Nenhum teste começa sem autorização formal, escopo escrito e regras de engajamento assinadas. Isso não é formalidade: é o que separa um teste de intrusão de um acesso não autorizado, e é o que protege os dois lados quando algo sai do previsto. A DM11 conduz o trabalho com as fases do PTES declaradas em contrato, cobertura de aplicação pelo OWASP e o caminho descrito na linguagem do MITRE ATT&CK.
Quem conduz o teste
CEH, hacker ético certificado pelo EC-Council
CPTE, engenharia de teste de intrusão pela AcadiTI
SYCP e SYWP, pentest e pentest de aplicação web pela Solyd
17 anos de governança, riscos e conformidades
O QUE É
Um pentest é conduzido por uma pessoa, com ferramentas ajudando, e não por uma ferramenta com uma pessoa olhando. Essa ordem explica quase tudo o que vem depois: o preço, o prazo, o que o relatório consegue afirmar e por que duas propostas com o mesmo nome entregam trabalhos incomparáveis. O que se compra é a perícia de quem encadeia falhas pequenas até chegar a algo que importa, e não a quantidade de itens encontrados.
Uma varredura de vulnerabilidades encontra e lista falhas conhecidas, de forma ampla e automática, e é trabalho de rotina que deve acontecer o ano inteiro. Um pentest confirma o que dá para explorar de verdade e mede até onde daria para chegar depois da primeira porta. Se o relatório que você recebeu tem dezenas de páginas de achados classificados por cor e nenhuma frase sobre o que alguém conseguiu fazer com eles, você comprou pentest e recebeu varredura com outro nome. As duas coisas se completam, e a comparação inteira está na página de pentest e análise de vulnerabilidade.
Sem autorização formal do responsável pelo ativo, o mesmo conjunto de ações é acesso não autorizado. Por isso o trabalho começa por um documento que define o que está dentro do escopo, o que está fora, quem autoriza, em qual janela, com qual critério de parada e quem é acionado se algo sair do previsto. Quando há terceiros no caminho, provedor de nuvem, provedor de acesso ou empresa que opera a sua segurança, o tratamento de cada um fica escrito antes do primeiro pacote.
A DM11 usa o PTES para a estrutura de execução, das interações prévias ao relatório, o OWASP para a cobertura de aplicação, com o Top 10 e o ASVS, e o MITRE ATT&CK para nomear o caminho percorrido. Os três resolvem coisas diferentes e nenhum substitui o outro. Um efeito prático disso é que o seu time de infraestrutura consegue conferir depois se a detecção enxergaria aquele caminho, o que transforma o relatório em insumo de melhoria e não apenas em documento de auditoria.
Não existe certificado de pentest, aqui ou em lugar nenhum, e desconfie de quem oferecer um. O que existe é um relatório em duas camadas, sumário executivo para a diretoria e relatório técnico com evidência, reprodução e correção por achado, mais o registro do reteste do que foi corrigido. É esse conjunto que vai para a auditoria, para o cliente que pediu e para o regulador. Quando alguém precisa de documento emitido por terceiro credenciado, quem responde é a ISO 27001 ou o SOC 2, e este relatório entra inteiro nelas como evidência.
QUANDO FAZ SENTIDO
Em dois deles a exigência vem de fora e tem prazo. No terceiro ela vem de dentro, e costuma ser o que produz o resultado mais útil.
O PCI DSS exige metodologia documentada e teste anual de quem processa cartão. As resoluções de segurança cibernética do Banco Central exigem teste de intrusão com periodicidade mínima anual, conduzido com independência e imparcialidade por especialista contratado para essa finalidade. Cliente grande em due diligence e auditoria de certificação pedem a mesma coisa em outro formato. Nesses casos o relatório sai da sua empresa e vai ser lido por quem não participou do teste.
Aplicação nova que expõe dado de cliente, migração para nuvem, integração com um parceiro que passou a acessar o seu ambiente, fusão que juntou duas redes que ninguém conhece inteiras. Aqui o valor não está em achar muitas falhas, está em descobrir cedo qual caminho novo foi aberto por uma mudança que todo mundo aprovou olhando outra coisa.
É o motivo menos comum e o que costuma render mais. Depois de comprar proteção de estação, filtro de e-mail e monitoramento, a única forma de saber o que aquilo barra é alguém tentar passar. A conversa muda quando o relatório mostra o que a defesa bloqueou, o que ela apenas registrou e o que ela ignorou, porque aí a próxima decisão de investimento é tomada com dado em vez de folheto de fabricante.
TRADUZINDO O PEDIDO
Contar endereços não descreve esforço. Estas são as quatro formas em que o pedido costuma chegar, com o que cada uma significa e o que realmente mexe no tamanho do trabalho.
| O que pediram | O que isso quer dizer | O que muda o tamanho |
|---|---|---|
| Precisamos de um pentest da nossa infraestrutura | Teste do que está exposto e do que existe atrás, com exploração e pós-exploração. É o formato que responde a exigência regulatória e a due diligence. | Quantos serviços diferentes existem de fato, e não quantos endereços. Faixa grande com serviços repetidos anda rápido; ambiente heterogêneo, não. |
| Queremos testar a nossa aplicação | Teste de aplicação com cobertura pelo OWASP, incluindo regra de negócio e controle de acesso entre perfis, que é onde as falhas caras costumam estar. | Quantidade de perfis de usuário, complexidade da regra de negócio, integrações com terceiros e se há acesso a documentação ou ao código. |
| O cliente pediu evidência de teste anual | O que vai ser lido por terceiro é o relatório. Ele precisa trazer escopo, método, datas, qualificação de quem executou, achados com evidência e comprovação do reteste. | O escopo que o exigente aceita, que raramente é o ambiente inteiro, e se o reteste precisa estar concluído dentro do mesmo ciclo. |
| Queremos saber se a nossa defesa funciona | O foco sai da lista de falhas e vai para a cobertura de detecção: o que a defesa barrou, o que apenas registrou e o que passou sem deixar rastro. | Se haverá janela com o bloqueio ativo, janela com o testador liberado de forma controlada, ou as duas, que é o que separa notícia boa de notícia útil. |
A conversa de escopo acontece antes da proposta, e a DM11 ajuda a escrever esse requisito mesmo quando a demanda ainda vai ao mercado. Serve para comparar fornecedores por trabalho em vez de por preço.
HISTÓRIAS
Trocamos os nomes dos clientes com o mesmo sigilo que vai proteger a sua empresa depois. Os nomes mudam, o padrão dos problemas se repete. Quando o cliente autoriza, mostramos referências com nome numa conversa.
Plataforma digital
O pedido chegou como teste de uma aplicação web, com o número de telas na proposta. A aplicação tinha vários perfis de usuário, incluindo um perfil administrativo usado por parceiros externos, e nenhum teste anterior tinha olhado o que um perfil conseguia fazer com o identificador de outro. O escopo, do jeito que estava escrito, não obrigava ninguém a olhar isso.
Reescrevemos o requisito de escopo antes da proposta, trocando contagem de telas por combinação de perfis: o que cada um deveria poder ver, e o que deveria ser recusado. A cobertura seguiu o OWASP, com o requisito verificado item a item, e a exploração seguiu para a pós-exploração para medir o alcance a partir de cada perfil.
As falhas mais graves não estavam nas telas que o pedido listava, e sim na fronteira entre dois perfis, que nenhuma contagem de telas alcançaria. O escopo escrito daquela forma virou o modelo das contratações seguintes da empresa.
Varejo
Depois de mover parte do ambiente para nuvem, a empresa manteve a rotina de varredura e considerou o assunto resolvido. A migração tinha sido aprovada por arquitetura, por custo e por disponibilidade. Ninguém tinha perguntado o que ficou alcançável de fora que antes não era, porque essa pergunta não pertencia a nenhuma das três aprovações.
Combinamos nas regras de engajamento o tratamento do provedor de nuvem e a janela, que é a parte que mais atrasa esse tipo de teste. O reconhecimento partiu do que estava exposto depois da migração, e as hipóteses de ataque foram ligadas ao que o negócio não podia perder, e não ao que era mais fácil de testar.
O caminho encontrado começava num serviço que existia desde antes e que a migração passou a expor. A correção foi de configuração e saiu rápido; o que ficou foi a mudança de processo, com o teste passando a ser gatilho de migração e não item anual solto no calendário.
Serviços B2B
A exigência veio no contrato: teste de intrusão anual, com evidência. A empresa orçou o ambiente inteiro, o valor assustou, e a discussão virou desconto. Ninguém tinha perguntado ao cliente qual escopo ele aceitava, e a suposição era que ele queria tudo.
Ajudamos a escrever a pergunta que faltava e a levá-la ao cliente por escrito, junto do que o relatório traria: escopo, método, datas, qualificação de quem executa, achados com evidência e comprovação do reteste. Com a resposta, o escopo foi desenhado sobre o que o exigente de fato lia, e o reteste entrou no mesmo ciclo em vez de ficar para depois.
O trabalho ficou do tamanho da exigência real, e não do tamanho do medo. E a empresa passou a ter, no primeiro ciclo, o documento que o cliente pedia, com o reteste concluído dentro do prazo do contrato.
COMO CONDUZIMOS
Cada fase termina com alguma coisa que você consegue conferir sem depender da nossa palavra. É esse o ponto do método declarado: um relatório que outro profissional consegue auditar vale mais do que um que só quem escreveu entende.
A fase que o comprador mais ignora e a que mais protege os dois lados. Fica escrito o que está dentro e o que está fora, a abordagem, as janelas, o critério de parada imediata, o tratamento de terceiros como provedor de nuvem e provedor de acesso, e se qualquer teste que possa afetar disponibilidade está autorizado. Autorização formal e contatos de emergência são registrados antes do primeiro pacote.
Escopo escrito, com o que está dentro e o que está fora
Regras de engajamento, janelas e critério de parada
Autorização formal para testar e contatos de emergência
Tratamento acordado para nuvem, provedor de acesso e demais terceiros
Marco de entregaEscopo e autorização assinados, sem nenhum ponto de escopo em aberto.
Levantamos o que existe e o que o mundo já sabe sobre a sua empresa, e transformamos isso em hipóteses de ataque ligadas ao que o seu negócio não pode perder. Sem esta fase o teste vira busca por falha solta, e o resultado é uma lista sem prioridade que ninguém sabe usar. As hipóteses são validadas com o seu time antes de qualquer exploração.
Superfície levantada, com o que é exposto e o que é interno
Informação pública sobre a empresa, quando está no escopo
Hipóteses de ataque ligadas ao que o negócio não pode perder
Alvos priorizados e acordados com você antes da exploração
Marco de entregaHipóteses validadas com o seu time, com prioridade acordada por escrito.
Confirmamos na prática o que dá para explorar, que é a diferença entre suspeita e fato, e seguimos para medir até onde daria para chegar depois da primeira porta. A pós-exploração é a fase que mais falta nas propostas baratas e a que mais muda decisão de investimento. Em aplicação, a cobertura segue o OWASP, com o Top 10 e o ASVS. Achado crítico é comunicado no mesmo dia, sem esperar o relatório.
Confirmação por exploração, com evidência do que foi obtido
Alcance real demonstrado, com o caminho encadeado
Cobertura de aplicação pelo OWASP, com o requisito verificado por item
Comunicação imediata do achado crítico, com recomendação inicial
Marco de entregaFalha crítica comunicada no mesmo dia em que é confirmada.
O relatório sai nas duas camadas que o próprio PTES define, sumário executivo e relatório técnico, com o caminho percorrido descrito na linguagem do MITRE ATT&CK para o seu time conferir a detecção e não só a correção. Depois que a correção acontece, refazemos o teste do que foi corrigido e registramos o resultado, que é o documento que a auditoria costuma pedir junto do relatório.
Sumário executivo para a diretoria, sem jargão
Relatório técnico com evidência, reprodução e correção por achado
Caminho percorrido nomeado por tática e técnica do MITRE ATT&CK
Reteste do que foi corrigido, com o resultado registrado
Marco de entregaCada achado fechado ou aceito por escrito, com o reteste registrado.
QUANTO TEMPO LEVA
Não publicamos prazo padrão porque prazo publicado vira promessa e escopo de teste de intrusão varia muito. A primeira conversa já mostra em qual destes fatores a sua empresa está, e é ela que produz o requisito de escopo.
Uma faixa grande com serviços repetidos anda rápido. Uma única aplicação com muitos perfis de usuário, regra de negócio complexa e integração com terceiros consome muito mais. É a conversa de escopo que separa os dois casos, e ela acontece antes da proposta.
Sem informação nenhuma, boa parte do tempo vai para o reconhecimento, e o resultado se parece com o que um atacante externo enfrentaria. Com acesso a documentação ou ao código, o mesmo tempo é gasto procurando falha em vez de procurando porta. As duas escolhas são legítimas, entregam coisas diferentes, e a decisão fica registrada no escopo.
Ambiente que só pode ser testado fora do horário comercial, sistema com pico sazonal, autorização pendente de provedor de nuvem e aviso prévio ao provedor de segurança gerenciada mexem no calendário mais do que a parte técnica. Essa conversa começa cedo, porque costuma ser a mais demorada do projeto inteiro.
PERGUNTAS FREQUENTES
As dúvidas que aparecem em quase toda primeira reunião, respondidas sem rodeio.
A análise de vulnerabilidade é ampla e sobretudo automática: encontra e lista falhas conhecidas, em ordem de gravidade, e serve como rotina ao longo do ano. O pentest é fundo e sobretudo manual: um especialista tenta explorar as falhas para provar o que um atacante conseguiria fazer, e mede até onde daria para chegar depois da primeira porta. Uma responde o que pode estar errado; a outra responde o que dá para fazer de fato. As duas se completam, e várias exigências pedem as duas: o PCI DSS, por exemplo, exige varredura trimestral e teste anual.
Precisa, e sem isso não começamos. Sem autorização formal do responsável pelo ativo, o mesmo conjunto de ações deixa de ser teste e passa a ser acesso não autorizado. O documento define o que está dentro e o que está fora do escopo, quem autoriza, a janela de execução, o critério de parada imediata, se qualquer teste que afete disponibilidade está permitido, e quem é acionado se algo sair do previsto. Quando há terceiros no caminho, como provedor de nuvem, provedor de acesso ou empresa que opera a sua segurança, o tratamento de cada um também fica escrito antes.
Pode, se ninguém combinar isso antes, e é exatamente por isso que a primeira fase existe. Nas regras de engajamento fica escrito se qualquer teste que afete disponibilidade está autorizado, quais sistemas ficam fora, em que janela o trabalho acontece, quem é acionado se algo sair do previsto e qual é o critério de parada imediata. Com isso registrado, o risco de indisponibilidade deixa de ser sorte e passa a ser decisão sua, tomada com informação e antes do começo.
Não existe, nem para a sua empresa nem para o relatório, e vale desconfiar de quem oferecer um. O que existe é o relatório com método declarado, e são as pessoas que conduzem o teste que têm certificação, como CEH, CPTE e as trilhas de pentest da Solyd. Quando o seu cliente ou o seu auditor precisa de um documento emitido por terceiro credenciado, quem responde a isso é a ISO 27001 ou o SOC 2, e o relatório do teste entra inteiro nessas auditorias como evidência.
Está, e ele é entregável declarado em contrato, não cortesia. Depois que a sua equipe corrige, refazemos o teste do que foi corrigido e registramos o resultado por achado, fechado ou aceito por escrito. Esse registro costuma ser tão pedido pela auditoria quanto o relatório em si, porque é ele que mostra que a lista não ficou parada. Se o prazo de correção do seu lado for longo, isso entra no escopo desde o começo em vez de virar discussão depois.
Peça a cada fornecedor que declare, fase a fase, o que será feito. Cinco perguntas separam quase tudo: quais fases estão incluídas, se a pós-exploração faz parte ou se o trabalho termina na confirmação da falha, se há reteste e em qual prazo, quem executa e com qual qualificação, e o que exatamente o relatório vai conter. Onde a proposta diz apenas pentest de um número de endereços, não há o que comparar, e a diferença de preço vai continuar sem explicação. A DM11 ajuda a escrever esse requisito mesmo quando a sua empresa ainda vai levar a demanda ao mercado.
Depende de quem está cobrando e do que muda no seu ambiente. O PCI DSS exige teste anual de quem processa cartão, e as resoluções de segurança cibernética do Banco Central exigem periodicidade mínima anual com independência de quem executa. Fora de exigência formal, a regra prática é anual, mais um teste sempre que algo relevante mudar: aplicação nova exposta, migração de ambiente, integração que abriu acesso a um parceiro. Entre um teste e outro, quem cobre o ano é a gestão de vulnerabilidades, que é trabalho de rotina e não substitui o teste.
Sim, e é um trabalho com outro escopo, não uma extensão do teste tradicional. Um sistema de IA é atacado por caminhos que uma aplicação comum não tem: manipulação da entrada para mudar o comportamento do modelo, extração do que ele aprendeu, envenenamento do dado que o alimenta. A referência que cataloga essas técnicas é o MITRE ATLAS, e não o ATT&CK. Se o seu caso envolve modelo em produção na frente do cliente, a conversa começa por ali e costuma vir junto da governança de IA.
Uma conversa curta já produz o requisito fase a fase que a sua empresa pode levar ao mercado. Serve para comparar fornecedores com critério, e serve para contratar com a gente sabendo exatamente o que recebe em cada etapa.
Comparativos sobre este assunto
Ver os 13 comparativosPTES · versão 1.0; a edição mais recente do wiki é de dezembro de 2015 · consultado em
OWASP Foundation · edição 2025, primeira revisão desde 2021 · consultado em
OWASP Foundation · ASVS 5.0 · consultado em
The MITRE Corporation · v19.1, publicada em 28/04/2026 · consultado em
Esta página é informativa e descreve como a DM11 lê e aplica as fontes acima. Ela não reproduz o texto das normas, não substitui a leitura do documento oficial e não substitui auditoria, certificação, avaliação independente ou aconselhamento jurídico. Onde a norma exige avaliação formal, quem conduz é um organismo, auditoria ou avaliador credenciado, sempre separado de quem preparou.