Como um teste acontece

Do primeiro mapeamento à correção validada.

Um teste só termina quando a falha deixa de existir, não quando o relatório é entregue.

A metodologia é a mesma em todos os serviços; o que muda é a superfície avaliada e a profundidade permitida pela modalidade escolhida. Cinco etapas, executadas em sequência, com comunicação aberta durante todo o percurso.

01 · O percurso

As cinco etapas, uma a uma

As etapas não são estanques: o que se descobre na exploração costuma alimentar novo reconhecimento, e o impacto medido pode abrir uma frente que não estava prevista. A sequência abaixo descreve o fluxo principal.

Etapa 01

Reconhecimento

Mapeamento da superfície de ataque real da empresa.

Antes de atacar qualquer coisa, é preciso saber o que existe. Levantamos o que está publicado, o que está acessível e o que se relaciona com o alvo, inclusive ativos que não constavam no inventário. Essa etapa frequentemente já produz achados por si só, porque exposição esquecida é uma das formas mais comuns de porta aberta.

  • Identificação de ativos e superfícies expostas
  • Levantamento de tecnologias, versões e integrações
  • Informação pública aproveitável em um ataque
  • Priorização dos alvos dentro do escopo acordado

Etapa 02

Exploração

Simulação de ataques reais, manuais e direcionados.

Com o mapa em mãos, começa o trabalho ofensivo propriamente dito. A exploração é manual e direcionada: automação apoia a cobertura, mas as falhas que realmente importam, as de lógica, autorização e encadeamento, exigem alguém entendendo o que o sistema faz e porque ele faz daquele jeito.

  • Validação manual de cada hipótese levantada
  • Encadeamento de falhas individualmente pequenas
  • Testes de autorização com cada nível de privilégio
  • Registro de evidência para cada achado confirmado

Etapa 03

Escalada & Impacto

Demonstração do impacto real de negócio.

Uma vulnerabilidade sem contexto é apenas um item de lista. Nesta etapa, medimos até onde o achado leva: que dados alcança, que privilégio concede, que operação interrompe. É essa medida que transforma severidade técnica em prioridade de negócio, e é ela que permite decidir o que corrigir primeiro.

  • Escalada de privilégio a partir do acesso obtido
  • Alcance real: dados, sistemas e operações atingidos
  • Tradução do risco técnico em risco operacional e financeiro
  • Comunicação imediata de achados de alta severidade

Etapa 04

Relatório & Remediação

Evidências claras, priorizadas por risco, com plano de correção.

A entrega é construída em camadas para servir a duas audiências: quem decide prioridade e orçamento, e quem vai efetivamente corrigir. Cada achado traz o caminho percorrido, a evidência que o sustenta e uma recomendação prática, orientada ao seu contexto técnico, não a uma referência genérica.

  • Leitura executiva do cenário de exposição
  • Relatório técnico com passos de reprodução
  • Priorização por impacto real na operação
  • Plano de correção executável, com sessão de esclarecimento técnico

Etapa 05

Reteste

Validação das correções e dos controles implementados.

O ciclo não fecha na entrega do relatório. Depois que sua equipe implementa as correções, testamos de novo: confirmamos que o caminho de ataque deixou de existir e que a correção não abriu um caminho novo. É o reteste que transforma uma recomendação em resultado verificado.

  • Nova execução dos testes sobre os achados corrigidos
  • Verificação de que a correção não introduziu regressão
  • Registro do estado final de cada achado
  • Base comparável para a próxima avaliação

02 · Modalidades

Quanto o testador sabe antes de começar

A modalidade não muda a metodologia: muda o ponto de partida. E o ponto de partida determina quanto do ambiente o mesmo prazo consegue cobrir.

Black Box

Sem conhecimento prévio do alvo. O auditor inicia sem informações internas sobre a infraestrutura ou o código, exatamente como um atacante externo começaria.

Ponto de partida
Apenas o alvo autorizado
Trabalho característico
Reconhecimento externo, varredura, mapeamento de superfície e exploração externa
Ganha em
Fidelidade à experiência real de um atacante sem acesso
Custa em
Tempo gasto em descoberta, que deixa de ser gasto em profundidade

Gray Box

Abordagem híbrida com informações parciais: credenciais de baixo privilégio, documentação básica ou diagramas de arquitetura.

Ponto de partida
Acesso limitado e contexto parcial
Trabalho característico
Simulação de ameaça interna e exploração aprofundada da lógica de negócio
Ganha em
Equilíbrio entre realismo e cobertura efetiva
Custa em
Parte do cenário externo puro deixa de ser exercitada

White Box

Conhecimento completo do alvo: código-fonte, documentação de APIs, diagramas detalhados de rede e credenciais administrativas.

Ponto de partida
Visão integral do ambiente e do código
Trabalho característico
Análise profunda e estrutural, incluindo falhas invisíveis por fora
Ganha em
Cobertura e profundidade máximas no mesmo prazo
Custa em
Menor semelhança com a jornada de um atacante externo

Nenhuma modalidade é superior às outras. A escolha depende do que você precisa provar: a resistência a alguém que chega de fora, o alcance de quem já tem algum acesso, ou a solidez estrutural do que foi construído.

03 · Princípios de execução

O que orienta cada decisão durante o trabalho

Estes princípios não são preferências de estilo: são o que separa uma avaliação que gera direção de um documento que gera trabalho sem prioridade.

  1. 01

    Pensar como um atacante

    A avaliação parte da perspectiva de quem tenta entrar, não da lista do que deveria estar configurado.

  2. 02

    Teste real acima de checklist

    Cobertura padronizada não substitui a investigação do que aquele ambiente específico permite.

  3. 03

    Automação como apoio

    Ferramentas ampliam alcance e liberam tempo; a análise que encontra o que importa é humana.

  4. 04

    Impacto demonstrado

    Não basta listar vulnerabilidades: é preciso mostrar até onde cada uma leva.

  5. 05

    Risco técnico ligado ao negócio

    Cada achado é relacionado à operação, para que a priorização faça sentido para quem decide.

  6. 06

    Evidência clara

    Toda afirmação vem com prova reproduzível. Sem demonstração, não há risco confirmado.

  7. 07

    Remediação prática

    A recomendação considera seu contexto técnico e seu ritmo de entrega, não um cenário ideal.

  8. 08

    Correção validada por reteste

    O trabalho termina com a confirmação de que o risco foi efetivamente eliminado.

  9. 09

    Comunicação transparente

    Você acompanha o andamento durante todo o engajamento, e não apenas na entrega final.

04 · Escopo

Não existe um pacote único para todos

Um escopo bem definido é o que determina se a avaliação vai responder à pergunta certa. Ele é construído com você, antes de qualquer teste, e formalizado por escrito.

  • Tamanho da empresa. A estrutura e o volume de ativos mudam o que é possível cobrir com profundidade.
  • Maturidade da operação. O que faz sentido testar depende do que já foi endereçado antes.
  • Superfície de ataque. O que está exposto e como está exposto define as frentes prioritárias.
  • Tecnologias utilizadas. Cada stack traz classes de falha próprias e exige abordagem específica.
  • Riscos relevantes para o negócio. O que não pode falhar orienta onde concentrar esforço.
  • Limites e janelas acordados. Ambientes, horários, ações permitidas e critérios de parada.

Autorização e conduta

Todo teste é executado dentro de um escopo ético e autorizado, formalizado antes do início. Informações, ambientes e vulnerabilidades são tratados com confidencialidade, e ações destrutivas ficam fora do escopo salvo autorização específica e documentada.

Próximo passo

Vamos definir o escopo certo para o seu ambiente.

A conversa inicial serve para entender sua superfície, seus riscos prioritários e qual modalidade responde à sua pergunta. Sem compromisso.

Escopo sob medidaTestes autorizadosConfidencialidadeFortaleza, CE