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 | Anual (secção 9); obrigatório após alterações de arquitectura significativas ou introdução de superfície de ataque relevante; para entidades financeiras (DORA), obrigatório pelo menos uma vez por ano nos sistemas e aplicações que apoiem funções críticas ou importantes (art. 24.º, n.º 6) |
| 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 (L2) | SLA de remediação (L3) |
|---|---|---|
| Critical | ≤ 7 dias | ≤ 3 dias |
| High | ≤ 30 dias | ≤ 15 dias |
| Medium | ≤ 90 dias | ≤ 45 dias |
| Low | ≤ 180 dias | ≤ 90 dias |
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; release major; alteração de arquitectura significativa; incidente de segurança; alteração regulatória que alargue o âmbito de conformidade |
Estas cadências são o mínimo recomendado pelo Manual (escolha do Manual). Prevalece o mais exigente: para entidades financeiras, «testes adequados, pelo menos uma vez por ano, a todos os sistemas e aplicações que apoiem funções importantes ou críticas» (DORA, art. 24.º, n.º 6) e, para as entidades identificadas pela autoridade, TLPT «pelo menos de três em três anos» (art. 26.º, n.º 1); as orientações do supervisor e as expectativas do sector — ver a cláusula de precedência da Política 29 §7.
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 |