Resposta a incidentes sem time interno: como uma startup se prepara e reage

A realidade da startup: sem SOC, sem CSIRT, com risco real

A grande maioria das startups brasileiras chega a dezenas de colaboradores — e às vezes a centenas — sem um único profissional dedicado a segurança da informação. O time de engenharia cuida do produto, o CTO resolve tudo de infraestrutura e o fundador assina o contrato de SaaS de segurança que ninguém lê. Essa configuração não é irresponsabilidade: é a realidade financeira e de prioridades de quem está crescendo.

O problema é que atacantes conhecem essa realidade. Grupos de ransomware, operadores de infostealer e agentes de phishing direcionado escolhem vítimas justamente pelo tamanho da superfície de ataque combinada com a ausência de detecção. Uma startup fintech com 30 colaboradores processa pagamentos, armazena CPFs e tem acesso a APIs bancárias — do ponto de vista do risco, ela é tão atraente quanto uma empresa maior, mas oferece resistência muito menor.

A boa notícia é que preparação mínima viável não exige contratação imediata de um CISO. Exige decisão, documentação e alguns controles técnicos que qualquer CTO pode implementar em menos de uma semana. O que não funciona é esperar o incidente acontecer para pensar no assunto.

Preparação mínima viável antes do incidente

O ponto de partida é um plano de resposta a incidentes simples: um documento de no máximo duas páginas que responde quatro perguntas — quem decide declarar incidente, quem notifica quem, onde ficam as credenciais de emergência e qual a ordem das ações prioritárias. Esse documento precisa existir em papel ou num sistema offline acessível mesmo se o ambiente principal estiver comprometido.

MFA em todas as contas com acesso privilegiado não é opcional. Contas de cloud, repositórios de código, plataformas de pagamento e e-mail corporativo com MFA eliminam a maioria dos vetores de acesso inicial que levam a incidentes graves. Hardware tokens oferecem a proteção mais robusta; aplicativos TOTP são aceitáveis; SMS não é.

Backups imutáveis testados merecem ênfase especial. Imutável significa que o backup não pode ser alterado ou apagado por credenciais comprometidas — a maioria dos provedores de cloud oferece políticas de retenção imutável a custo baixo. Testado significa que alguém fez a restauração completa e confirmou que funciona. Um backup que nunca foi restaurado não existe do ponto de vista operacional.

Logs centralizados em destino separado do ambiente principal são a diferença entre uma investigação forense eficaz e um exercício de especulação. Ferramentas como AWS CloudTrail, Google Cloud Audit Logs ou um SIEM leve bastam para startups em estágio inicial. O requisito fundamental é que os logs não possam ser apagados por quem comprometeu o ambiente operacional.

Um retainer de IR — contrato prévio com uma empresa especializada em resposta a incidentes — garante que, quando o incidente acontecer, você terá profissionais disponíveis em horas, não em semanas, e a um custo acordado previamente. Contratar IR em regime de emergência sem retainer custa entre duas e cinco vezes mais e frequentemente envolve espera de dias para alocação de equipe.

O ciclo NIST SP 800-61 adaptado para time pequeno

O NIST SP 800-61 define seis fases de resposta a incidentes que funcionam independentemente do tamanho do time: Preparação, Detecção e Análise, Contenção, Erradicação, Recuperação e Atividades Pós-Incidente. Em uma startup, cada fase pode ter um ou dois responsáveis em vez de uma equipe inteira, mas a estrutura lógica se mantém.

Detecção e Análise começa com um alerta — um usuário reportando comportamento estranho, um alarme de ferramenta de monitoramento ou uma notificação externa como a que o CERT.br envia quando detecta atividade maliciosa associada ao seu ASN. A análise inicial tem uma pergunta central: isso é um incidente real ou um falso positivo? Preserve as evidências antes de qualquer ação — screenshots, logs, timestamps. Não reinicie sistemas antes de capturar o estado.

Contenção tem dois momentos distintos. A contenção de curto prazo isola o problema imediatamente: desconectar um host comprometido da rede, revogar credenciais expostas, bloquear um IP malicioso. A contenção de longo prazo prepara o terreno para operar de forma degradada enquanto a investigação avança — sem destruir evidências nem interromper o negócio mais do que o necessário.

Erradicação remove a causa raiz: eliminar malware, fechar a vulnerabilidade explorada, revogar todos os acessos comprometidos. Essa fase exige análise forense mínima para garantir que você removeu tudo, não apenas a parte visível. Pular a erradicação completa por pressa de voltar ao normal é a causa mais comum de reinfecção.

Recuperação é o retorno controlado à operação normal, com monitoramento intensificado para detectar qualquer sinal de persistência remanescente. Sistemas são restaurados de backups verificados ou reconstruídos do zero, credenciais são rotacionadas por completo e o ambiente é validado antes de reabrir o acesso.

Lições aprendidas fecha o ciclo com uma reunião estruturada dentro de duas semanas do incidente: o que aconteceu, o que funcionou, o que falhou, o que muda no processo e nos controles. Essa fase transforma custo em investimento — cada incidente bem documentado reduz o impacto do próximo.

O que não fazer durante um incidente

Desligar todos os sistemas por reflexo de pânico é um dos erros mais custosos. Desligar máquinas elimina a memória volátil — onde frequentemente estão as evidências mais valiosas sobre o que o atacante fez e como entrou. O isolamento correto mantém o sistema ligado mas desconectado da rede, preservando o estado para análise.

Apagar logs ou reformatar discos antes de uma análise forense básica é o equivalente a limpar a cena de um crime antes da perícia. Mesmo que a intenção seja proteger dados sensíveis ou acelerar a recuperação, a destruição de evidências compromete a capacidade de entender o incidente, de cumprir obrigações regulatórias e, em casos extremos, pode configurar problemas legais.

Pagar resgate por impulso, sem análise prévia, é uma decisão que deve envolver pelo menos uma consulta com especialistas antes de ser tomada. Pagar não garante a recuperação dos dados, financia o desenvolvimento de novos ataques e pode violar sanções internacionais dependendo do grupo atacante. Em alguns casos, a decodificação fornecida pelo atacante é incompleta ou defeituosa mesmo após o pagamento.

Comunicar publicamente antes de ter os fatos é outro erro comum em startups que, por transparência ou pressão de usuários, divulgam informações imprecisas nas primeiras horas. Comunicação prematura pode alertar o atacante de que foi detectado, comprometer a investigação e criar obrigações jurídicas antes que o escopo real seja conhecido.

Obrigações legais: LGPD, ANPD e BCB

A Lei Geral de Proteção de Dados (LGPD) estabelece que o controlador deve comunicar à Autoridade Nacional de Proteção de Dados (ANPD) a ocorrência de incidente de segurança que possa acarretar risco ou dano relevante aos titulares. O prazo regulamentar consolidado pela ANPD é de até 3 dias úteis contados a partir do momento em que o controlador toma ciência do incidente.

A comunicação à ANPD deve conter informações mínimas: natureza dos dados afetados, número aproximado de titulares, medidas técnicas e de segurança adotadas, riscos relacionados ao incidente e as medidas adotadas ou que serão adotadas. Startups que não documentam o incidente em tempo real têm dificuldade em cumprir esse requisito, o que pode resultar em sanção adicional por descumprimento do dever de comunicação.

Fintechs e empresas que atuam no sistema financeiro têm obrigações adicionais perante o Banco Central do Brasil, especialmente sob a Resolução BCB nº 85/2021 e normas complementares sobre segurança cibernética para instituições de pagamento e financeiras. Essas normas exigem plano de resposta a incidentes formalizado, testes periódicos e reporte de incidentes relevantes à autarquia. O não cumprimento pode resultar em cancelamento de autorização operacional.

Além das obrigações regulatórias, contratos com clientes enterprise frequentemente incluem cláusulas de notificação de breach com prazos menores do que os regulatórios — às vezes 24 ou 48 horas. Revisar esses contratos antes de um incidente é parte da preparação mínima viável.

Quando e como acionar um parceiro externo de IR

O acionamento de um parceiro externo de resposta a incidentes deve acontecer o mais cedo possível após a confirmação de que o incidente é real. A tendência de tentar resolver internamente antes de pedir ajuda é compreensível, mas cada hora sem contenção adequada amplia o escopo do comprometimento e aumenta o custo de recuperação.

Com um retainer vigente, o acionamento é simples: uma ligação ou mensagem para o canal de emergência definido no contrato, com as informações iniciais coletadas na fase de detecção. A empresa de IR já conhece o ambiente básico do cliente — pelo onboarding do retainer — e pode iniciar a triagem remota em minutos.

Sem retainer, o processo de contratação em emergência envolve negociação de escopo e NDA em situação de pressão, transferência de contexto a partir do zero e frequentemente disputa por alocação de recursos com outros clientes em emergência. O custo médio de IR contratado em emergência no Brasil é significativamente superior ao de um retainer anual para startups de pequeno e médio porte.

A Decripte oferece resposta a incidentes 24x7 e retainer de IR para startups de 1 a mais de 100.000 colaboradores, com SLA de acionamento definido em contrato e equipe especializada em ambientes de cloud, fintech e SaaS. O plano gratuito de Gestão de Ameaças já inclui monitoramento de vazamentos e diagnóstico inicial — uma forma de começar sem custo e evoluir conforme a maturidade da operação exige. Para contratar o retainer ou o plano de resposta a incidentes, acesse decripte.com.br/plano/resposta-incidentes.

Checklist prático

1. 1

   1. Documente o plano de resposta básico

   Crie um documento de até duas páginas com os critérios para declarar incidente, a lista de contatos de escalonamento (interno e externo), a localização das credenciais de emergência e a ordem das ações prioritárias. Guarde uma cópia offline ou fora do ambiente principal de trabalho.

2. 2

   2. Ative MFA em todas as contas críticas

   Revise o acesso a cloud, repositórios de código, plataformas de pagamento, DNS e e-mail corporativo. Ative MFA em todas essas contas — preferencialmente com hardware token ou aplicativo TOTP. Revogue qualquer sessão ativa após a ativação e audite usuários com acesso privilegiado.

3. 3

   3. Configure backups imutáveis e teste a restauração

   Ative políticas de retenção imutável nos provedores de cloud para os backups mais críticos. Agende um teste de restauração completo ao menos uma vez por trimestre. Documente o tempo de recuperação real e mantenha esse número visível para o time de engenharia.

4. 4

   4. Centralize logs fora do ambiente operacional

   Configure encaminhamento de logs de autenticação, acessos privilegiados e alterações de infraestrutura para um destino separado — um bucket com controle de acesso restrito ou um SIEM leve. Defina retenção mínima de 90 dias para ter histórico útil em uma investigação.

5. 5

   5. Contrate um retainer de IR antes de precisar

   Avalie provedores de resposta a incidentes, verifique o SLA de acionamento e os serviços cobertos pelo retainer — triagem remota, forense, contenção, comunicação regulatória. Assine o contrato e faça o onboarding de contexto enquanto tudo está funcionando normalmente.

6. 6

   6. Execute o ciclo NIST na ordem correta

   Quando o incidente acontecer: preserve evidências antes de agir, isole sem desligar, remova a causa raiz por completo antes de restaurar, volte ao normal com monitoramento intensificado e documente as lições aprendidas em até duas semanas do encerramento.

7. 7

   7. Cumpra os prazos regulatórios sem improvisar

   Notifique a ANPD dentro de 3 dias úteis da ciência do incidente se houver dados pessoais afetados. Fintechs devem verificar as obrigações adicionais do Banco Central. Revise os contratos com clientes enterprise para identificar prazos de notificação contratuais, que podem ser mais curtos que os regulatórios.

Perguntas frequentes