Um teste de intrusão (pentest) é um ataque autorizado e simulado a um sistema, feito como um atacante real o faria, para encontrar e confirmar fraquezas antes de alguém mal-intencionado. A palavra-chave é «confirmar»: um pentest prova que o problema é explorável, em vez de apenas o assinalar como possível.
A distinção fundamental, definida no NIST SP 800-115, é que um teste de intrusão explora ativamente uma fraqueza para confirmar que existe, em vez de apenas reportar que uma vulnerabilidade pode estar presente. É por isso que um bom pentest filtra os falsos positivos dos scanners: cada achado vem com prova. O reverso é que se trata de um exercício pontual e limitado no tempo, que reflete o sistema tal como foi testado na janela acordada.
A maioria dos projetos segue um processo reconhecido, como o Penetration Testing Execution Standard (PTES) ou as quatro fases do NIST SP 800-115: planeamento, descoberta, ataque e relatório. A fase de ataque regressa à descoberta sempre que um novo acesso abre novos caminhos. O projeto começa com a definição do âmbito e das regras de atuação (na Vexaro, também com um NDA antes de qualquer acesso) e termina com um relatório priorizado e, connosco, um reteste gratuito das correções dentro do prazo fixado no SoW.
Os pentests são delimitados a um alvo: uma aplicação web (segundo o OWASP Web Security Testing Guide), uma API (o OWASP API Security Top 10), uma aplicação móvel (OWASP MASVS/MASTG), uma rede interna ou externa, ou a configuração da cloud. Alvos diferentes exigem métodos diferentes (aplicar uma checklist de web a uma API deixa escapar a maior parte do risco real), e é por isso que os serviços estão divididos por alvo.
O testador pode trabalhar sem conhecimento prévio (black-box), com conhecimento parcial, como credenciais e uma especificação (grey-box), ou com conhecimento total, incluindo código-fonte e arquitetura (white-box). Em regra, mais informação significa uma cobertura mais profunda no mesmo tempo, pelo que a escolha deve depender do seu objetivo de garantia, e não da opção que soa mais exigente. O grey-box é a norma com melhor relação custo-benefício para a maioria dos trabalhos de aplicação e de API.
É um ataque simulado e autorizado, feito como um atacante real o faria, para confirmar fraquezas exploráveis em vez de apenas assinalar fraquezas possíveis. Segundo o NIST SP 800-115, explora ativamente uma fraqueza para provar que existe. É um exercício pontual e limitado no tempo, que reflete o sistema tal como foi testado na janela acordada.
A maioria dos projetos segue um processo reconhecido, como o PTES ou as quatro fases do NIST SP 800-115: planeamento, descoberta, ataque e relatório. Começa com a definição do âmbito e das regras de atuação (na Vexaro, com um NDA antes de qualquer acesso) e termina com um relatório priorizado e, connosco, um reteste gratuito das correções dentro do prazo fixado no SoW.
Os testes de intrusão são delimitados a um alvo (uma aplicação web, uma API, uma aplicação móvel, uma rede ou uma configuração cloud), porque alvos diferentes exigem métodos diferentes. O testador pode começar sem qualquer conhecimento (black-box), com conhecimento parcial, como credenciais e uma especificação (grey-box), ou com o código-fonte e a arquitetura completos (white-box). A escolha depende do objetivo de garantia, e não do que parece mais exigente.