VAPT: avaliação de vulnerabilidades e teste de intrusão

Na Índia, “VAPT” é o termo usado no dia a dia para testes de segurança. Clientes, parceiros, auditores e contrapartes reguladas frequentemente pedem um “relatório de VAPT” antes de assinar um contrato, conectar uma integração ou aprovar um lançamento. O termo combina duas atividades: a avaliação de vulnerabilidades, que busca de forma ampla fragilidades conhecidas, e o teste de intrusão, que examina em profundidade se essas fragilidades podem ser exploradas. Este guia explica o que um trabalho de VAPT costuma abranger, como definir um escopo sensato e o que verificar antes de compartilhar o resultado.

O que é

A parte de avaliação de vulnerabilidades (VA) é ampla. Ela combina varredura automatizada com revisão para identificar patches ausentes, componentes desatualizados, serviços expostos, configurações fracas e problemas web comuns nos ativos acordados. A parte de teste de intrusão (PT) é profunda. Um testador trabalha manualmente em alvos selecionados, normalmente aplicações web, APIs e aplicativos móveis, validando achados e testando autenticação, gerenciamento de sessão, controle de acesso entre perfis, exposição de dados e lógica de negócio. Juntas, a VA oferece cobertura e o PT oferece confiança sobre o que é realmente explorável. Um trabalho de VAPT deve terminar com um relatório escrito que registre escopo, método, achados classificados por severidade com evidências, orientações de correção e, quando acordado, o resultado de um reteste após as correções. As solicitações às vezes mencionam frameworks como o OWASP Top 10 ou as orientações do OWASP Mobile Application Security; eles são pontos de referência úteis sobre o que os testadores analisam.

A quem se destina

O VAPT é comumente solicitado por ou para:

Equipes de SaaS, fintech e e-commerce cujos clientes corporativos pedem um relatório de VAPT recente durante o processo de compra
Empresas que vão se conectar a um parceiro, banco ou provedor de pagamentos que exige evidências de testes de segurança antes da integração
Equipes de produto que preparam o lançamento público de uma aplicação web ou de um aplicativo móvel
Organizações que mudaram a hospedagem, a autenticação ou os fluxos de pagamento e querem uma verificação independente

O que ajuda a esclarecer

Um VAPT com escopo bem definido ajuda a esclarecer:

Quais aplicações, APIs e ambientes o solicitante realmente espera ver testados
Se o requisito exige um tipo específico de auditor ou credenciamento que precisa ser confirmado antes da escolha do fornecedor
Quais achados são riscos validados e quais são observações do scanner
Quais correções precisam ser feitas antes que um relatório possa ser compartilhado com segurança

O que está incluído

Obtenha por escrito o requisito exato do solicitante: ativos, profundidade, formato do relatório e eventuais critérios para o fornecedor
Liste os alvos: domínios, URLs das aplicações, caminhos base das APIs, builds dos aplicativos móveis e ambientes (homologação ou produção)
Prepare contas de teste para cada perfil de usuário, para que o teste de controle de acesso seja significativo
Confirme a autorização por escrito, a janela de teste, os contatos nomeados e as condições de interrupção
Informe os provedores de hospedagem, CDN ou WAF, se os termos deles exigirem
Acorde as classificações de severidade, o formato do relatório e a forma de compartilhamento das evidências
Reserve tempo para corrigir os achados e solicitar um reteste dos problemas acordados

O que não está incluído

Uma declaração de que um VAPT torna uma aplicação segura ou em conformidade
A afirmação de que qualquer fornecedor atende a um requisito específico de credenciamento ou empanelamento sem que isso seja verificado em relação a esse requisito
Testes de sistemas de terceiros sem a permissão do proprietário
Aconselhamento jurídico ou regulatório sobre o que uma determinada norma exige

Quando escolher esta opção

Contrate um VAPT quando uma contraparte identificada o solicitar, antes de um lançamento relevante ou após mudanças significativas na forma como os usuários fazem login, pagam ou acessam dados. Se a solicitação vier de uma relação regulada, leia o requisito com atenção: alguns especificam um auditor credenciado ou empanelado (na Índia, alguns reguladores e contrapartes mencionam auditores empanelados pelo CERT-In), um escopo específico ou um ciclo de testes fixo. Confirme esses detalhes primeiro com o solicitante, pois um relatório que não corresponde ao requisito pode precisar ser refeito. Este artigo contém informações gerais e não constitui aconselhamento jurídico ou regulatório.

A Nossa Abordagem

Use o checklist do solicitante como ponto de partida e acrescente os sistemas que concentram mais risco para o seu negócio, mesmo que ninguém tenha perguntado sobre eles. Teste em um ambiente de homologação que espelhe a produção sempre que possível e acorde com antecedência como os testes em produção serão conduzidos, se forem necessários. Nosso serviço Application Security Review abrange testes de aplicações web e APIs, com achados escritos e classificados por severidade e orientações de correção; escopos mais amplos, com vários ambientes ou de rede, são tratados pelo nosso serviço Penetration Testing. Em ambos os casos, o escopo, a autorização e o formato dos relatórios são confirmados por escrito antes do início do trabalho. Após a entrega, corrija primeiro os achados altos e críticos, registre as decisões sobre riscos aceitos e solicite um reteste. Em seguida, compartilhe um resumo executivo ou uma carta de status da correção em vez do relatório técnico completo, a menos que o solicitante precise especificamente desse nível de detalhe e tenha uma forma segura de recebê-lo.

Application Security Review

Ver a página do serviço Application Security Review