Teste de intrusão orientado por conformidade
A maioria dos testes de intrusão é contratada porque uma norma os exige. A norma determina o escopo, a frequência e — a parte que costuma ser subestimada — as evidências que você precisará apresentar depois. Esta página compara os regimes contra os quais eu testo, para que você identifique qual realmente se aplica a você.
As normas comparadas
Cada um destes regimes exige testes de segurança independentes ou os requer na prática. As diferenças que importam: quem é obrigado, com que frequência e o que você precisa demonstrar depois.
Arábia Saudita
- NCA Essential Cybersecurity Controls (em inglês) - a base nacional para órgãos públicos, seus contratados e infraestrutura crítica. O controle 2-11 trata de teste de intrusão: definido, documentado, aprovado e implementado, com escopo cobrindo no mínimo os serviços expostos à Internet e a infraestrutura técnica por trás deles. De forma periódica.
- NCA Critical Systems Cybersecurity Controls - quando sistemas são classificados como críticos, a frequência passa para pelo menos a cada seis meses. É essa mudança de ritmo que costuma derrubar a premissa orçamentária.
- SAMA Cyber Security Framework (em inglês) - bancos, seguradoras, financeiras e provedores de pagamento supervisionados pelo banco central saudita. Testes externos independentes no mínimo anuais, cobrindo sistemas expostos à Internet, aplicações web e infraestrutura de rede.
Emirados Árabes Unidos
- NESA / UAE Information Assurance Standards (em inglês) - entidades federais e infraestrutura de informação designada crítica. Avaliações de vulnerabilidade e testes de intrusão são realizados e acompanhados, anualmente na prática, com remediação documentada e evidência de reteste para achados críticos e altos dentro de um prazo definido. Os auditores analisam as credenciais de quem testou.
- Dubai ISR (DESC) - entidades públicas de Dubai e seus fornecedores. Convive com o NESA; um mesmo trabalho pode evidenciar ambos.
- CBUAE, DFSA e ADGM (em inglês) - bancos e financeiras onshore, empresas do DIFC, empresas do ADGM. Nos três casos esperam-se testes independentes regulares.
- VARA - prestadores de serviços de ativos virtuais de Dubai. Teste de intrusão independente no mínimo anual sob o Technology and Information Rulebook, com testes orientados por inteligência quando a VARA considerar proporcional.
- ADHICS (em inglês) - prestadores de saúde de Abu Dhabi e seus fornecedores de tecnologia.
Internacional
- PCI DSS - para quem armazena, processa ou transmite dados de portadores de cartão. O requisito 11.4 exige testes de intrusão internos e externos pelo menos anuais e após mudanças significativas, além de testes de segmentação quando esta é usada para reduzir o escopo.
- SOC 2 - não é uma obrigação prescritiva, mas o teste de intrusão é a evidência que a maioria dos auditores espera para CC4.1 e CC7.1, e clientes corporativos cada vez mais o exigem no relatório.
- ISO 27001 - gestão de vulnerabilidades técnicas do Anexo A, onde o teste é a forma prática de demonstrar que o controle opera.
O que os auditores realmente pedem
O relatório é necessário e não suficiente. Quatro artefatos compõem um pacote de evidências completo, e a maioria das organizações chega apenas com o segundo:
- Um documento de escopo - o que foi testado, o que não foi, e por que aquele escopo correspondia ao controle. Um teste que excluiu justamente os sistemas que interessam ao controle reprova por melhor que tenha sido.
- O relatório - achados, severidades, detalhe de reprodução e mapeamento para os controles envolvidos.
- Remediação documentada - o que você corrigiu, quando, e o que aceitou como risco com a justificativa. Aceitar risco é permitido; não registrar a decisão, não.
- Evidência de reteste - a confirmação de que os achados críticos e altos estão de fato fechados, dentro do prazo da sua norma. A expectativa de 90 dias do NESA é a que pega as pessoas: um teste no décimo primeiro mês não deixa espaço para reteste antes do fim do ciclo.
Uma carta de atestação — quem testou, qual escopo, quais datas — fecha o pacote e costuma ser o que é arquivado ou encaminhado a um cliente. Todo trabalho aqui inclui uma.
Independência é o requisito que se interpreta errado
Várias dessas normas usam a palavra independente, e ela tem um significado preciso: o teste não pode ser feito por quem construiu ou opera o sistema avaliado. Uma equipe de segurança interna testando a infraestrutura da própria organização atende a algumas normas e não a outras; a equipe que escreveu a aplicação e depois a testa não atende a nenhuma.
Essa é boa parte da razão de existirem consultores externos neste mercado, e vale checar isso contra a sua obrigação específica antes de supor que sua capacidade interna cobre. Errar aqui é caro, porque você descobre na auditoria e não no escopo.
Como eu delimito um trabalho de conformidade
A primeira conversa é sobre a obrigação, não sobre tecnologia: qual norma, qual controle, qual prazo e se algo mudou de forma material desde o último teste. A partir disso, normalmente consigo dizer em uma ligação se um único trabalho cobre tudo a que você está sujeito, e o que o escopo precisa incluir para produzir evidências que sobrevivam a uma auditoria.
O que você recebe: preço fechado antes de começar, teste feito pela pessoa com quem você conversou, aviso imediato de qualquer achado crítico em vez de surpresa no documento final, um relatório escrito para a diretoria e para os engenheiros ao mesmo tempo, apoio durante a remediação, um reteste e a carta de atestação. Há um relatório de exemplo caso queira ver o formato antes (em inglês), e a página de preços para as ordens de grandeza.
Por região
Se você está no Golfo, as páginas regionais aprofundam quais regimes se aplicam e como interagem: teste de intrusão na Arábia Saudita e teste de intrusão nos Emirados. Para o restante, as páginas de serviços cobrem o teste em si, e entrar em contato é o caminho mais rápido para uma resposta clara.
Perguntas sobre testes de conformidade
Normalmente sim, e sai bem mais barato que a alternativa. O escopo técnico se sobrepõe bastante — superfície externa, aplicações web e APIs, rede interna, Active Directory, nuvem — então o que muda é o mapeamento para os controles e o formato do relatório, não o teste em si. A condição é definir assim desde o início: um teste delimitado apenas para PCI não produzirá as evidências que o NESA pede, embora o trabalho subjacente seja praticamente idêntico. Informe-me no escopo todos os regimes aos quais está sujeito e o relatório vinculará os achados a cada um deles.
Não, e esse é o motivo mais comum de rejeição de evidências. Um scan compara assinaturas conhecidas com versões conhecidas e produz uma lista; um teste de intrusão encadeia achados para mostrar o que alguém conseguiria de fato fazer com eles. As normas dizem isso cada vez mais explicitamente, e os auditores já identificam bem um relatório de scan com capa de pentest — o sinal é que todo achado é um CVE e nenhum se conecta a outro. A diferença em detalhe (em inglês).
Quatro coisas, e a maioria das organizações só guarda a segunda. Um documento de escopo mostrando o que foi testado e por que aquele escopo era adequado. O relatório em si, com achados, severidades e detalhe de reprodução. A remediação documentada dos achados críticos e altos. E a prova de um reteste confirmando que as correções funcionaram, dentro do prazo da sua norma — 90 dias é comum. Uma carta de atestação indicando quem testou, com que escopo e em quais datas liga tudo isso, e costuma ser a página que vai para o arquivo.
Anualmente é a base habitual: SAMA, NESA, VARA e PCI DSS convergem aí. Duas coisas encurtam esse prazo: a classificação como sistema crítico sob os CSCC sauditas, que exige testes pelo menos a cada seis meses, e mudanças significativas. Quase toda norma exige novo teste após alterações materiais no ambiente, independentemente de quando foi o último teste anual — uma migração grande ou uma nova aplicação exposta à Internet reinicia o relógio.
Em geral sim, e as causas são previsíveis: escopo estreito demais para o que o controle exigia; teste feito pela equipe que construiu o sistema, portanto não independente; ausência de evidência de reteste; ou um scan apresentado como teste de intrusão. Os quatro são corrigíveis, e a solução costuma ser um único trabalho bem delimitado, não um programa. Envie-me a observação do auditor e o relatório anterior e eu digo qual dos quatro foi, antes que você gaste qualquer coisa.
Não sabe qual norma se aplica a você?
Uma conversa curta costuma resolver — e mostra se um único teste consegue cobrir todas.