O cliente pede um teste de invasão — um pentest. O MSP conhece a infraestrutura, administra acessos e já responde pelos chamados. Essa proximidade ajuda a organizar o trabalho, mas não resolve as decisões que tornam uma avaliação defensável: o que será testado, quem pode autorizar, até onde a execução pode avançar e qual evidência será suficiente. O serviço ganha consistência quando essas decisões acompanham a entrega inteira, da proposta ao reteste. Um relatório sem esse vínculo deixa perguntas essenciais para depois do incidente.
Comece pela pergunta que o teste precisa responder
Antes de discutir ferramentas, identifique o motivo do pedido. Uma análise de segurança de API, uma exigência contratual e uma revisão depois de uma migração podem exigir trabalhos diferentes. O documento solicitado pelo cliente pode se chamar pentest ou teste de invasão e ainda assim não esclarecer profundidade, ativos ou critérios de aceite. O MSP precisa transformar essa intenção em perguntas verificáveis e confirmar se a entrega proposta será aceita por quem a solicitou.
É diferente perguntar se um portal está acessível pela internet e perguntar se um usuário consegue acessar dados de outra organização. A primeira questão orienta descoberta de superfície; a segunda exige examinar autorização e isolamento, com identidades e condições de teste adequadas. A proposta deve explicar quais perguntas serão examinadas, quais dependem de acesso adicional e quais ficarão fora. Essa precisão evita vender um nome conhecido com um conteúdo indefinido.
Uma avaliação delimitada não demonstra ausência de vulnerabilidades no ambiente inteiro. A conclusão vale para os ativos, condições e técnicas efetivamente examinados. Registrar essas condições protege a utilidade do resultado: quem lê consegue entender o que a equipe observou e decidir onde ainda falta investigar.
Na Wardizon, essa preparação ganha um fluxo operacional: o MSP cadastra o cliente, organiza o escopo e encaminha a autorização para assinatura antes da execução. Os achados e o relatório ficam ligados ao trabalho realizado. Assim, a conversa comercial pode partir de uma entrega definida — avaliar condições autorizadas, apresentar a evidência e acompanhar com o cliente o que precisa de tratamento.[3]
O RoE delimita a execução e mantém a responsabilidade visível
O NIST SP 800-115 inclui um modelo de Regras de Engajamento no apêndice B e trata o planejamento da avaliação como uma etapa própria. A referência ajuda a separar a autorização para testar das decisões que orientam a execução.[1]
Na prática, o contrato comercial organiza a relação entre as partes; o RoE registra as atividades autorizadas e seus limites. Ter acesso administrativo não equivale a receber autorização para executar qualquer técnica ofensiva. O MSP deve identificar o representante do cliente apto a aprovar o escopo e esclarecer quem responde pelas dependências operadas por terceiros. Permissões necessárias de provedores e de outros titulares não surgem automaticamente com a assinatura do cliente.
A assinatura também não elimina risco operacional nem concede imunidade contra responsabilidade. Um teste autorizado ainda pode produzir impacto, exceder limites ou tratar dados de forma inadequada. O trabalho é reduzir ambiguidades, estabelecer responsabilidades e registrar decisões. Questões jurídicas específicas pertencem à negociação e à assessoria das partes; não devem ser resolvidas por promessas de proteção absoluta em uma proposta técnica.
Escreva o escopo de modo que duas pessoas executem a mesma decisão
Uma lista de domínios é um começo, não a definição completa do teste. Para cada alvo, registre identificador, ambiente, responsável e exclusões relevantes. Esclareça se o domínio inclui subdomínios, se um endereço pode mudar e como a equipe deve reagir ao descobrir um destino diferente. Redirecionamentos e relações de confiança podem apontar para sistemas que não pertencem ao cliente. Descobrir um ativo não é autorização para testá-lo.
Considere um cenário hipotético: o portal aprovado redireciona o login para um provedor de identidade compartilhado. Testar o fluxo da aplicação não autoriza atacar o serviço compartilhado. A equipe deve distinguir o comportamento da aplicação sob avaliação dos controles operados pelo terceiro e obter as permissões necessárias antes de ampliar o trabalho. O mesmo cuidado vale para armazenamento, pagamentos e integrações encontrados durante a navegação.
O documento precisa permitir uma resposta objetiva quando surgir uma dúvida: esta ação, neste alvo, com esta identidade e nesta janela, foi autorizada? Se faltar uma dessas condições, o caminho é esclarecer ou solicitar nova autorização. Resolver a dúvida durante a preparação costuma custar menos do que reconstruir decisões depois da execução.
A janela precisa funcionar para quem opera o ambiente
Validade da autorização e janela de execução são decisões relacionadas, mas diferentes. Um documento vigente não torna qualquer horário adequado para testar. Combine períodos permitidos, fuso de referência, mudanças programadas e condições que impedem o início. No começo de cada execução, confirme se o alvo continua correto, se o ambiente está estável e se o contato de emergência permanece disponível. Uma autorização válida pode coexistir com uma condição operacional que exige adiamento.
Defina também quem pode interromper o trabalho e como a equipe comunicará a parada. Queda de disponibilidade, comportamento inesperado ou descoberta de um sistema fora do escopo precisam de um tratamento conhecido. O registro deve mostrar o que estava em execução, a condição observada e a decisão tomada. A ausência de resposta de um responsável não deve ser interpretada como aprovação para avançar.
Essas verificações são responsabilidades do processo do MSP. Ao escolher uma plataforma, confirme quais limites ela aplica tecnicamente e quais dependem de procedimentos do operador. Uma opção de configuração não demonstra, sozinha, que cada regra foi implementada ou que um fluxo de exceção está coberto.
Negocie profundidade, identidades e impacto antes de executar
Descoberta de superfície, teste sem credencial e teste autenticado respondem a perguntas diferentes. O escopo deve descrever o acesso disponível e o que a equipe poderá fazer com ele. Em uma aplicação com múltiplos perfis, uma conta administrativa não substitui o exame das fronteiras entre usuários comuns, gestores e organizações. Contas de teste precisam representar as relações relevantes sem recorrer desnecessariamente a dados reais.
Exploração exige uma decisão explícita sobre finalidade e limite. Confirmar uma falha de autorização pode demandar uma evidência pequena; prosseguir para coletar um volume maior de dados pode acrescentar exposição sem melhorar a conclusão. O objetivo é demonstrar a condição autorizada com impacto proporcional. Se a prova necessária ultrapassar os limites acordados, registre a restrição e devolva a decisão ao responsável.
Nenhuma automação resolve, por si, a interpretação de um fluxo de negócio ou a aceitação do risco pelo cliente. Ela pode reduzir tarefas repetitivas; a análise do contexto, das consequências e das exceções continua exigindo julgamento técnico.
Separe suspeita, confirmação e impacto demonstrado
O OWASP WSTG v4.2 recomenda revisar falsos positivos e produzir relatórios que permitam reproduzir os resultados. Também orienta documentar causa, técnica empregada, severidade e correção. Esse é um critério útil para avaliar o conteúdo de uma entrega, além da quantidade de achados.[2]
O MSP precisa distinguir três perguntas: há um indício de falha, a falha foi confirmada e qual impacto foi efetivamente demonstrado? Uma versão identificada pode sustentar uma suspeita, sem provar que a configuração é explorável. Uma resposta inesperada pode confirmar comportamento inadequado sem comprovar acesso a toda a base. O relatório deve preservar essas diferenças, inclusive quando o teste não avançou por restrição do escopo.
A prioridade também depende do contexto. Exposição externa, pré-condições, privilégio exigido e criticidade do processo ajudam a orientar a correção. Uma classificação técnica não deve ser apresentada como medida exata da perda financeira do cliente. Se o contexto ainda não foi validado com o responsável pelo ativo, explicite a hipótese e a informação necessária para decidir.
Colete evidência suficiente e reduza a exposição criada pelo teste
Uma evidência útil identifica alvo, horário, condições de acesso, comportamento observado e procedimento necessário para verificação. O responsável pela correção precisa compreender o que aconteceu e conseguir reproduzir a condição em um ambiente adequado. Capturas isoladas e descrições genéricas deixam margem para interpretações diferentes. Quando a reprodução depende de estado ou de uma sequência de operações, documente essa dependência.
O volume coletado deve ser justificado pela demonstração. Prefira registros de teste e amostras minimizadas quando forem suficientes. Remova segredos e dados pessoais dos materiais de circulação ampla e restrinja o acesso ao detalhe técnico. Defina responsáveis por armazenamento, compartilhamento, retenção e descarte. Uma evidência que ajuda a corrigir o problema não precisa circular com as mesmas permissões de uma apresentação executiva.
Hashes podem apoiar a conferência da integridade de um artefato. Eles não demonstram, sozinhos, que o conteúdo é verdadeiro, que o signatário tinha autoridade ou que toda a operação respeitou o escopo. A qualidade da evidência depende da combinação entre registro técnico, contexto e disciplina de tratamento.
A entrega termina com uma decisão sobre a correção
Cada achado relevante deve ganhar responsável, ação prevista e critério de verificação. Corrigir a causa, aplicar uma mitigação e aceitar o risco são decisões diferentes; o histórico precisa mostrar qual foi escolhida. Se a equipe instala uma barreira temporária, o registro deve manter a pendência de tratamento da causa. A mudança de status não pode apagar a condição originalmente observada.
O reteste verifica a condição que motivou o achado, sob as condições autorizadas para a nova execução. Compare o comportamento anterior com o atual, registre a versão ou configuração relevante e documente eventuais limitações. Um erro de conexão não demonstra correção de uma falha de autorização. Se a aplicação deixou de estar disponível para exame, o resultado é uma impossibilidade de verificar, não uma conclusão de segurança.
Uma mudança relevante de alvo ou profundidade exige nova autorização. A recorrência deve preservar esse vínculo: cada execução precisa caber em um RoE vigente. Repetir testes ajuda a observar mudanças; não transforma o trabalho em cobertura irrestrita de todo o ambiente.
Organize o serviço pela capacidade de fechar o ciclo
O cliente define prioridades de negócio, disponibiliza as condições acordadas e indica quem pode decidir sobre risco. O MSP organiza escopo, coordena a execução, interpreta o resultado e acompanha a correção com os responsáveis. A plataforma fornece as funções contratadas; a presença de uma função não transfere automaticamente a ela as decisões do serviço. Essa divisão deve estar clara também quando houver equipe de desenvolvimento ou outro fornecedor envolvido.
Na recorrência, a capacidade de entrega depende tanto da validação e da correção quanto da execução. Um MSP que gera mais relatórios do que consegue discutir acumula trabalho pendente. Acompanhe a passagem entre etapas para descobrir onde o serviço perde efeito.
- Cobertura realizada: alvos e cenários examinados em relação aos autorizados, com exclusões documentadas.
- Tempo de validação: intervalo entre o indício e a decisão sobre confirmação ou descarte.
- Tempo de exposição: período entre a confirmação e a correção verificada, considerando a prioridade acordada.
- Retestes concluídos: correções examinadas em relação às que estavam prontas para verificação.
- Recorrência da causa: reaparecimento de falhas da mesma origem em ciclos comparáveis.
Como o fluxo da Wardizon se encaixa nessa operação
Na Wardizon, o MSP monta o escopo e envia o pedido de autorização ao aprovador indicado. O MSP declara que esse endereço pertence ao cliente; isso não equivale a uma verificação independente de identidade pela plataforma. O link de assinatura vale 60 minutos. O escopo assinado é congelado num resumo imutável vinculado aos hashes do documento e da assinatura. Mudança material exige um novo RoE.[4]
A plataforma exige RoE assinado antes de iniciar o teste. Nos planos pagos, cada RoE vale por 30 dias e carrega até 30 execuções — no máximo uma por dia. Esses limites descrevem a recorrência autorizada; não substituem o acordo operacional sobre o momento adequado para executar. Os relatórios co-branded apresentam a marca do MSP acompanhada de “Powered by Wardizon”.
O trial executa Basic, de descoberta de superfície. O RoE do trial carrega três execuções. Essa avaliação não é um pentest e deve ser apresentada ao cliente com essa distinção. Testes com ou sem credenciais exigem e-mail de login no domínio da sua própria empresa; caixas gratuitas ficam restritas ao trial e ao Basic. O trial permite conhecer o fluxo de autorização e entrega, sem antecipar conclusões sobre a profundidade das avaliações pagas.
Defina o primeiro ciclo antes de ampliar a carteira
Escolha uma necessidade concreta, delimite os ativos e confirme quem aprova o trabalho. Prepare contas, janela e condições de parada; combine como os achados serão apresentados e quem poderá corrigi-los. Depois da execução, revise a evidência e as limitações antes de entregar o relatório. A conversa com o cliente deve terminar com decisões registradas e com o reteste previsto para as correções relevantes.
A qualidade do serviço aparece nesse encadeamento. O cliente consegue relacionar o que autorizou ao que foi examinado, compreender a diferença entre suspeita e confirmação e verificar o resultado das ações acordadas. É essa rastreabilidade que permite ampliar uma operação de pentest sem transformar recorrência em repetição de relatórios que ninguém consegue usar.
Prepare o trabalho com o modelo de Regras de Engajamento antes de enviar o pedido de autorização ao cliente.