Política de PenTesting Ofensivo
1. Objetivo
Esta política define os requisitos para a execução de testes de penetração (PenTesting) ofensivos como componente do programa de validação de segurança da organização.
A automação é fundamental para uma postura de segurança sustentável - SAST, DAST, SCA e fuzzing fornecem cobertura contínua e escalável. No entanto, ferramentas automáticas apenas detectam o que foram programadas para detectar: vulnerabilidades isoladas, padrões conhecidos, heurísticas de código. Um penetration tester experiente simula o raciocínio de um atacante - encadeia vulnerabilidades aparentemente menores em caminhos de exploração que nenhum scanner individual consegue identificar, explora lógica de negócio, abusa de configurações correctas mas inseguras em conjunto, e valida empiricamente a exploitabilidade. PenTesting não substitui automação - complementa-a ao validar os controlos onde a automação tem limites inerentes.
O objetivo desta política é garantir que:
- O PenTesting é realizado com âmbito definido, autorização formal e regras de engajamento documentadas
- Os resultados produzem evidência técnica reproduzível e rastreável
- Os findings são tratados pelo mesmo processo centralizado que os restantes testes de segurança
- O retest de findings críticos e altos é realizado após remediação
- A cadência de PenTesting é proporcional ao nível de risco da aplicação
2. Âmbito e obrigatoriedade
| Nível | Obrigatoriedade |
|---|---|
| L1 | Não aplicável na generalidade; pode ser realizado pontualmente por decisão do Tech Lead |
| L2 | Recomendado; obrigatório após alterações de arquitectura significativas ou introdução de superfície de ataque relevante |
| L3 | Obrigatório; pelo menos uma vez por ano; obrigatório antes da primeira colocação em produção de aplicações novas |
3. Modalidades de teste
| Modalidade | Descrição | Aplicabilidade |
|---|---|---|
| Black Box | O tester não recebe informação prévia sobre a aplicação. Simula atacante externo sem conhecimento interno. | L2 pontual; L3 como complemento |
| Grey Box | O tester recebe contexto técnico parcial: endpoints, credenciais de teste, documentação de API, findings anteriores de SAST/DAST. Permite exploração dirigida com maior eficácia. | L2/L3 - modalidade recomendada por defecto |
| White Box | O tester tem acesso total: código fonte, arquitectura, credenciais, configuração de infraestrutura. Máxima cobertura. | L3 para aplicações de alto risco ou em preparação para certificação |
A selecção da modalidade deve ser justificada no documento de âmbito e aprovada pelo AppSec Engineer antes do início do teste.
4. Autorização e regras de engajamento
Nenhum teste de penetração pode ser iniciado sem autorização formal e regras de engajamento documentadas.
4.1 Documento de âmbito e autorização
O documento de âmbito deve ser assinado pelo Tech Lead ou equivalente com autoridade sobre os sistemas em teste, e deve incluir:
| Campo | Descrição |
|---|---|
| Sistemas em âmbito | Lista explícita de aplicações, endpoints, ambientes e infraestrutura incluídos |
| Sistemas fora de âmbito | Lista explícita do que está excluído (ex: sistemas de terceiros, produção se apenas staging) |
| Ambiente de teste | Staging (preferido) ou produção (com mitigações adicionais e janela definida) |
| Modalidade de teste | Black Box / Grey Box / White Box |
| Período de execução | Datas de início e fim; janela horária permitida |
| Ponto de contacto | Responsável técnico disponível durante o teste para esclarecimentos e emergências |
| Dados fornecidos ao tester | Credenciais de teste, documentação, findings anteriores (Grey/White Box) |
| Procedimento de emergência | Protocolo de paragem imediata se o teste causar impacto inesperado |
4.2 Regras de engajamento
| Regra | Descrição |
|---|---|
| Ambiente de teste prioritário | PenTesting deve ser realizado em staging, salvo justificação aprovada. Testes em produção requerem aprovação adicional do CISO ou equivalente. |
| Proibição de dados reais | O tester não deve aceder, exfiltrar, modificar ou reter dados reais de utilizadores ou dados regulados, mesmo que tecnicamente acessíveis durante o teste |
| Sem destruição ou persistência | O tester não deve eliminar dados, instalar backdoors persistentes, ou modificar configurações sem reversão documentada |
| Comunicação de descobertas críticas | Findings de criticidade Critical devem ser comunicados imediatamente ao ponto de contacto, sem aguardar o relatório final |
| Confidencialidade | Os resultados são confidenciais; o relatório só pode ser partilhado com destinatários autorizados |
| Tester qualificado | O PenTesting deve ser realizado por profissional qualificado - interno (com certificação OSCP, CEH, GPEN ou equivalente) ou externo (empresa especializada com NDA e cláusulas contratuais de segurança) |
A realização de testes ofensivos em sistemas sem autorização formal, mesmo que internos à organização, é considerada uma violação de política e pode ter implicações legais e disciplinares. A autorização explícita é um requisito não negociável.
5. Áreas de teste obrigatórias
O âmbito do teste deve, proporcionalmente ao nível de risco, cobrir as seguintes áreas:
| Área | Exemplos de vectores a testar | L2 | L3 |
|---|---|---|---|
| Autenticação e autorização | Bypass de autenticação, escalada de privilégios, IDOR, broken access control | Obrigatório | Obrigatório |
| Gestão de sessão | Session fixation, token predictability, CSRF | Recomendado | Obrigatório |
| Injecção | SQL injection, SSTI, command injection, XXE | Obrigatório | Obrigatório |
| Validação de input | XSS, path traversal, upload malicioso | Recomendado | Obrigatório |
| Lógica de negócio | Abuso de fluxos transaccionais, bypass de limites, manipulação de estados | Recomendado | Obrigatório |
| Configuração e exposição | Headers de segurança, TLS, CORS, informação exposta, endpoints não documentados | Obrigatório | Obrigatório |
| APIs e integrações | Autenticação de API, autorização por endpoint, rate limiting, exposição de dados | Recomendado | Obrigatório |
| Infraestrutura (se no âmbito) | Rede, serviços expostos, configuração de cloud | Não aplicável | Recomendado |
6. Relatório de PenTesting
O relatório é o artefacto primário do PenTesting. Deve ser entregue no prazo acordado após a conclusão dos testes e satisfazer os seguintes requisitos mínimos:
6.1 Estrutura mínima do relatório
| Secção | Conteúdo |
|---|---|
| Sumário executivo | Visão geral do teste, âmbito, metodologia e conclusão sobre postura de segurança - acessível a não-técnicos |
| Metodologia | Abordagem utilizada (ex: OWASP Testing Guide, PTES, OWASP WSTG), ferramentas utilizadas, período de execução |
| Inventário de findings | Lista completa de findings com ID único, título, severidade (Critical/High/Medium/Low/Informational), CVSS score quando aplicável |
| Detalhe por finding | Para cada finding: descrição técnica, evidência (screenshot, payload, resposta), exploitabilidade demonstrada, impacto potencial, recomendação de remediação |
| Prova de conceito (PoC) | Para findings Critical e High: PoC reproduzível com passos detalhados suficientes para validação pela equipa de desenvolvimento |
| Mapeamento | Referências a CWE, CVE (quando aplicável), OWASP Top 10 |
| Conclusão e risco residual | Avaliação global do risco residual; áreas que não foi possível testar |
6.2 Severidade e classificação
A severidade dos findings deve ser atribuída com base em exploitabilidade real demonstrada, não apenas em scoring teórico:
| Severidade | Critério |
|---|---|
| Critical | Exploitável remotamente sem autenticação, com impacto directo em confidencialidade, integridade ou disponibilidade de dados ou sistemas |
| High | Exploitável com autenticação mínima ou com passos adicionais, com impacto significativo |
| Medium | Requer condições específicas ou combinação com outro finding; impacto moderado |
| Low | Exposição de informação, má configuração sem exploitabilidade imediata, boas práticas não seguidas |
| Informational | Observações sem impacto de segurança directo; melhoria recomendada |
7. Integração com o processo de findings
Os findings do PenTesting são tratados pelo mesmo processo centralizado que os findings de SAST, DAST e SCA:
- Findings importados ou registados na plataforma centralizada de gestão de findings (ex: DefectDojo)
- Findings classificados e triados por AppSec Engineer
- Cada finding associado a owner, estado (Aberto/Em curso/Resolvido/Aceite/Diferido) e prazo
- Findings Critical e High bloqueiam promoção a produção se não remediados (salvo excepção aprovada)
- Decisões de aceitação ou diferimento documentadas com justificação e aprovação proporcional à severidade
Os SLAs de remediação aplicáveis são os definidos na Política de Estratégia de Testes:
| Severidade | SLA de remediação |
|---|---|
| Critical | ≤ 7 dias |
| High | ≤ 30 dias |
| Medium | ≤ 90 dias |
| Low | Próximo ciclo de manutenção |
8. Retest
Após remediação de findings Critical e High, deve ser realizado um retest para confirmar que a vulnerabilidade foi efectivamente corrigida:
- Retest realizado preferencialmente pelo mesmo tester ou por tester com acesso ao PoC original
- Retest documentado com resultado (Remediado / Parcialmente remediado / Não remediado)
- Se o finding não for confirmado como remediado, o ciclo de remediação recomeça com prazo redefinido
- Resultado do retest arquivado como evidência de conformidade
O retest não é opcional para findings Critical e High. A remediação declarada sem validação empírica não é considerada evidência auditável - o finding permanece aberto até retest positivo.
9. Cadência de PenTesting
| Nível | Cadência mínima | Gatilhos adicionais |
|---|---|---|
| L1 | Não aplicável | - |
| L2 | Anual (se não existirem outros gatilhos) | Alteração de arquitectura significativa; nova superfície de exposição; incidente de segurança relevante |
| L3 | Anual | Primeira colocação em produção; alteração de arquitectura significativa; incidente de segurança; alteração regulatória que alargue o âmbito de conformidade |
Para aplicações L3 que entram em produção pela primeira vez, o PenTesting deve ser concluído e os findings Critical/High remediados antes da colocação em produção.
10. Responsabilidades
| Role | Responsabilidade |
|---|---|
| AppSec Engineer | Definir âmbito e modalidade; aprovar regras de engajamento; coordenar com o tester; triagem e gestão dos findings; validar retest |
| Tech Lead | Assinar autorização formal; garantir que a equipa prioriza remediação dentro dos SLAs; participar no retest se necessário |
| DevOps / SRE | Fornecer acesso ao ambiente de staging; configurar credenciais de teste; apoiar eventual reversão de configurações durante o teste |
| GRC / Compliance | Gerir contratos com empresas externas de PenTesting; verificar qualificações do tester; arquivar relatórios; auditar cadência |
| CISO / Gestão | Aprovar PenTesting em produção; analisar sumários executivos; tomar decisões de risco residual |
11. Revisão e auditoria desta política
Esta política deve ser revista anualmente ou após qualquer um dos seguintes eventos:
- Alteração significativa do tipo de aplicações ou da superfície de ataque do portfólio
- Incidente de segurança causado por uma vulnerabilidade que deveria ter sido detectada em PenTesting
- Alteração regulatória que imponha novos requisitos de testes ofensivos
12. Referências normativas e técnicas
| Referência | Relevância |
|---|---|
| SbD-ToE Cap. 10 - Testes de Segurança | US-08: PenTesting ofensivo baseado em risco |
Política de Estratégia de Testes (19_policy-estrategia-testes.md) | SLAs de remediação; gestão centralizada de findings |
Política de Release Seguro (20_policy-release-seguro.md) | Gate de PenTesting pré-produção |
| OWASP Testing Guide (WSTG) | Metodologia de referência para web application pentesting |
| PTES - Penetration Testing Execution Standard | Framework de referência para execução de PenTesting |
| OWASP ASVS | Application Security Verification Standard - áreas de teste |
| NIST SP 800-115 | Technical Guide to Information Security Testing and Assessment |
| CVSS v3.1 | Common Vulnerability Scoring System - base para classificação de severidade |
| CWE | Common Weakness Enumeration - classificação de vulnerabilidades |