Como avaliar a segurança de um site antes de contratar proteção: checklist executivo

Você está na sala de aprovação orçamentária; o CISO abriu a discussão e o conselho pergunta, direto: “o que exatamente vamos comprar e como vamos provar que funciona?” Essa pergunta não é retórica — é o ponto onde compras por marketing se transformam em contratos que o time jurídico e de risco conseguem auditar. A tese prática aqui é simples: exigir evidências técnicas e cláusulas contratuais reduz ruído, facilita a aprovação e protege o orçamento contra promessas não verificadas.

Nos parágrafos seguintes eu apresento uma checklist executiva de evidências mínimas, uma matriz para comparar propostas com critérios replicáveis e um template de RFP light com campos obrigatórios. Depois detalho cláusulas contratuais úteis (reteste, tuning contínuo, acesso a evidências) e os limites e trade‑offs que vocês devem considerar antes de assinar. No final, um caminho operacional direto para executar um piloto com MVX Shield, caso queiram transformar a avaliação em prova técnica.

Que evidências pedir hoje para justificar a compra?

Peça apenas coisas auditáveis. Evite declarações abertas como “tuning contínuo” sem prova. A lista abaixo é mínima: cada item deve ter um formato de entrega (arquivo, credencial, política ou cronograma) e um responsável do fornecedor.

• Logs e retenção de telemetria: amostra de logs (anonimizados) mostrando eventos bloqueados e permitidos, com carimbo de tempo e contexto (URI, cabeçalho, regra aplicada). Exija formato e nível de detalhe para auditoria interna.
• Runbooks e playbooks: procedimentos escritos para tuning, resposta a falso-positivos, rollbacks e deploys. Não aceite “temos processos” — peça o documento.
• Reteste pós‑correção: cláusula que garanta um reteste determinístico após correção de vulnerabilidade ou ajuste, com evidência (relatório) e escopo definido.
• SLAs mensuráveis: SLA de disponibilidade da proteção (se aplicável), SLA de tempo de resposta para incidentes e SLA de tempo para ações corretivas operacionais; peça definição de métricas e método de medição.
• Auditoria e evidências de tuning: registros de mudanças de regra (change log) com justificativa técnica e aprovação; versão das regras aplicadas e periodicidade do tuning.
• Prova de integridade operacional: evidência de teste de integração (ex.: simulação em ambiente de staging), quem executou e que resultados foram observados.
• Garantia de acesso a dados para compliance: como o fornecedor disponibiliza logs e relatórios para auditoria e atendimento a requisições de GRC/LGPD.
• Inventário de cobertura: lista de endpoints, domínios e subdomínios cobertos pelo serviço e limitações explícitas (ex.: recursos dinâmicos não cobertos).
• Treinamento e transferência de conhecimento: registros de sessões de treinamento e materiais entregues à equipe interna.

Como transformar evidências em matriz de decisão comparável?

Compare propostas com quatro eixos objetivos: impacto na operação, rigidez operacional, governança e preço. Cada eixo tem critérios binários ou escalas simples para reduzir ambiguidade.

Impacto na operação

• Cobertura funcional (WAF, OWASP, bot mitigation, TLS inspection)
• Visibilidade (logs em tempo real vs relatórios diários)
• Complexidade de integração (proxy reverso, DNS, host‑based)

Rigidez operacional

• Presença de runbooks e change logs exigíveis
• Nível de automação vs necessidade de intervenção manual
• Política de rollbacks e janelas de deploy

Governança

• Acesso a logs para auditoria
• Reteste formalizado e aceito por contrato
• Política de privacidade e suporte a requisitos de GRC/LGPD (ver solução)

Preço (valor percebido)

• Preço por cobertura efetiva (domínio/endpoint)
• Custos de onboarding e tuning inicial
• Custos de operação contínua (horas de suporte, tuning mensal)

Monte uma planilha simples onde cada critério recebe nota 0–3 e um peso definido pelo conselho; isso transforma preferências em decisão auditável.

Checklist executivo: evidências mínimas que o fornecedor deve entregar

1. Arquivo de exemplo de logs anonimizados com legenda e formato.
2. Runbook de tuning e resposta a incidentes (PDF ou link protegido).
3. Declaração contratual de reteste pós‑correção com escopo e amostras de relatório.
4. Template de SLA com métricas definidas e método de medição.
5. Change log histórico (últimos 90 dias ou período negociado).
6. Inventário de cobertura e exclusões técnicas.
7. Plano de treinamento e agenda de transferência de conhecimento.

Template de RFP light: campos obrigatórios

Use este RFP light como lista de verificação executável; exija resposta direta para cada campo.

• Resumo executivo: escopo de proteção solicitado (domínios, subdomínios, APIs).
• Entregáveis técnicos: logs (formato), runbooks, relatórios de tuning, change logs.
• SLAs: definir métricas e método de medição para disponibilidade e resposta a incidentes.
• Reteste: definição de quando e como o reteste será executado após correção.
• Integração: requisitos de infraestrutura (proxy, DNS, certificados) e responsabilidades.
• Governança: acesso a dados para auditoria, suporte a GRC/LGPD e transferência de conhecimento.
• Onboarding e piloto: proposta de piloto técnico, critérios de sucesso e entregáveis do piloto.
• Preços e modelos de cobrança: detalhar componentes (licença, managed services, horas de tuning).

Cláusulas contratuais recomendadas que reduzem risco

Na negociação, peça cláusulas que transformem evidências em obrigações:

• Reteste formal: o fornecedor se compromete a executar reteste no ambiente acordado e entregar relatório com evidências.
• Tuning contínuo com change log: periodicidade mínima de tuning documentada e registro de mudanças com justificativa técnica.
• Acesso a logs para auditoria: formato e periodicidade de entrega; direito a auditoria por terceiro em condições acordadas.
• Planos de rollback: obrigação de plano de rollback documentado e períodos de manutenção comunicados com antecedência.
• Critérios de aceitação do piloto: métricas e entregáveis que definem sucesso antes de efetivar contrato de longo prazo.

Limites, trade‑offs e decisões que precisam do conselho

Não existe solução sem custo. Exigir evidências aumenta tempo de avaliação e pode elevar preço inicial por trabalho de auditoria. Mas aceitar promessas reduz a defensabilidade do gasto. Escolhas típicas:

• Priorizar cobertura ampla vs. menor superfície com garantia mais forte (trade‑off entre custo e governança).
• Avaliar pilotar com escopo reduzido para validar métricas antes de expandir (custo e tempo de piloto).
• Exigir acesso a logs completo vs. logs agregados por preocupação de privacidade; negocie formatos que atendam LGPD.

Como verificar que o fornecedor realmente faz tuning contínuo?

Peça três artefatos correlacionáveis: change log, relatórios periódicos de tuning com justificativa e amostras de regras aplicadas (versões). Cruzar logs com change log mostra se mudanças produziram efeito operacional. Se o fornecedor não entrega esses artefatos, trate a promessa como não comprovada.

É razoável exigir reteste pós‑correção e como formalizar?

Sim. Formalize como parte do contrato: defina critérios técnicos do reteste (escopo, técnicas permitidas), prazo para execução e formato do relatório. Inclua cláusula que vincule aceitação da correção à entrega do relatório; sem isso, a correção fica apenas em palavra.

Perguntas frequentes do conselho

O que deve constar no SLA de um WAF gerenciado?

Inclua métricas de disponibilidade da proteção, tempo de resposta inicial a incidentes, tempo para aplicar ações corretivas críticas e fórmula de cálculo para medição. Peça também processo de evidência e auditoria para comprovar conformidade com o SLA.

Como comparar SLAs diferentes entre propostas?

Padronize a definição de métricas no RFP e peça exemplos de medições históricas no formato que vocês usarão para avaliar. Assim você compara maçã com maçã e não interpreta termos vagos.

Modelo operacional sugerido para o piloto

Execute um piloto técnico com escopo claro: 1–3 domínios em staging ou com tráfego limitado; duração fixada; critérios de sucesso (logs entregues, reteste satisfatório, tuning demonstrado). Exija entregáveis periódicos e revisões semanais com o fornecedor para ajustar parâmetros e coletar evidências.

Se decidirem avançar, MVX Shield pode ser parceiro para o piloto técnico: solicite um piloto de avaliação técnico conforme o RFP light acima e valide as evidências no ambiente controlado. Para detalhes sobre serviços gerenciados, consulte a página de Website Security Gerenciado: /pt/products/website-security.

Baixe o template de RFP e solicite um piloto de avaliação. O template transforma as seções acima em campos exigíveis e facilita a reunião com jurídico e conselho. Se quiser, peça ao time comercial um piloto técnico com entrega dos artefatos listados — é o jeito mais rápido de provar entrega e reduzir o risco de compra baseada em marketing.

CTA: Baixe o template de RFP e solicite um piloto de avaliação.