Respuesta a incidentes sin equipo interno: cómo una startup se prepara y reacciona

La realidad de la startup: sin SOC, sin CSIRT, con riesgo real

La gran mayoría de las startups brasileñas llegan a decenas de colaboradores — y a veces a cientos — sin un solo profesional dedicado a la seguridad de la información. El equipo de ingeniería cuida el producto, el CTO resuelve todo lo de infraestructura y el fundador firma el contrato del SaaS de seguridad que nadie lee. Esta configuración no es irresponsabilidad: es la realidad financiera y de prioridades de quien está creciendo.

El problema es que los atacantes conocen esa realidad. Los grupos de ransomware, los operadores de infostealer y los agentes de phishing dirigido eligen a sus víctimas precisamente por el tamaño de la superficie de ataque combinado con la ausencia de detección. Una startup fintech con 30 colaboradores procesa pagos, almacena datos de identificación y tiene acceso a APIs bancarias — desde el punto de vista del riesgo, es tan atractiva como una empresa más grande, pero ofrece mucha menos resistencia.

La buena noticia es que la preparación mínima viable no exige la contratación inmediata de un CISO. Exige decisión, documentación y algunos controles técnicos que cualquier CTO puede implementar en menos de una semana. Lo que no funciona es esperar a que ocurra el incidente para pensar en el tema.

Preparación mínima viable antes del incidente

El punto de partida es un plan de respuesta a incidentes simple: un documento de máximo dos páginas que responda cuatro preguntas — quién decide declarar el incidente, quién notifica a quién, dónde están las credenciales de emergencia y cuál es el orden de las acciones prioritarias. Ese documento debe existir en papel o en un sistema offline accesible incluso si el entorno principal está comprometido.

El MFA en todas las cuentas con acceso privilegiado no es opcional. Las cuentas de cloud, los repositorios de código, las plataformas de pago y el correo corporativo con MFA eliminan la mayoría de los vectores de acceso inicial que conducen a incidentes graves. Los tokens de hardware ofrecen la protección más robusta; las aplicaciones TOTP son aceptables; el SMS no lo es.

Los backups inmutables probados merecen un énfasis especial. Inmutable significa que el backup no puede ser alterado ni borrado por credenciales comprometidas — la mayoría de los proveedores de cloud ofrecen políticas de retención inmutable a bajo costo. Probado significa que alguien hizo la restauración completa y confirmó que funciona. Un backup que nunca se restauró no existe desde el punto de vista operativo.

Los logs centralizados en un destino separado del entorno principal son la diferencia entre una investigación forense eficaz y un ejercicio de especulación. Herramientas como AWS CloudTrail, Google Cloud Audit Logs o un SIEM ligero bastan para startups en etapa inicial. El requisito fundamental es que los logs no puedan ser borrados por quien comprometió el entorno operativo.

Un retainer de IR — un contrato previo con una empresa especializada en respuesta a incidentes — garantiza que, cuando ocurra el incidente, tendrá profesionales disponibles en horas, no en semanas, y a un costo acordado de antemano. Contratar IR en régimen de emergencia sin retainer cuesta entre dos y cinco veces más y frecuentemente implica esperar días para la asignación del equipo.

El ciclo NIST SP 800-61 adaptado a un equipo pequeño

El NIST SP 800-61 define seis fases de respuesta a incidentes que funcionan independientemente del tamaño del equipo: Preparación, Detección y Análisis, Contención, Erradicación, Recuperación y Actividades Posteriores al Incidente. En una startup, cada fase puede tener uno o dos responsables en lugar de un equipo completo, pero la estructura lógica se mantiene.

La Detección y Análisis comienza con una alerta — un usuario que reporta un comportamiento extraño, una alarma de una herramienta de monitoreo o una notificación externa como la que envía el CERT.br cuando detecta actividad maliciosa asociada a su ASN. El análisis inicial tiene una pregunta central: ¿es esto un incidente real o un falso positivo? Preserve las evidencias antes de cualquier acción — capturas de pantalla, logs, timestamps. No reinicie sistemas antes de capturar el estado.

La Contención tiene dos momentos distintos. La contención de corto plazo aísla el problema de inmediato: desconectar un host comprometido de la red, revocar credenciales expuestas, bloquear una IP maliciosa. La contención de largo plazo prepara el terreno para operar de forma degradada mientras avanza la investigación — sin destruir evidencias ni interrumpir el negocio más de lo necesario.

La Erradicación elimina la causa raíz: eliminar el malware, cerrar la vulnerabilidad explotada, revocar todos los accesos comprometidos. Esta fase exige un análisis forense mínimo para garantizar que eliminó todo, no solo la parte visible. Saltarse la erradicación completa por prisa de volver a la normalidad es la causa más común de reinfección.

La Recuperación es el retorno controlado a la operación normal, con monitoreo intensificado para detectar cualquier señal de persistencia remanente. Los sistemas se restauran desde backups verificados o se reconstruyen desde cero, las credenciales se rotan por completo y el entorno se valida antes de reabrir el acceso.

Las lecciones aprendidas cierran el ciclo con una reunión estructurada dentro de las dos semanas posteriores al incidente: qué ocurrió, qué funcionó, qué falló, qué cambia en el proceso y en los controles. Esta fase transforma el costo en inversión — cada incidente bien documentado reduce el impacto del próximo.

Qué no hacer durante un incidente

Apagar todos los sistemas por reflejo de pánico es uno de los errores más costosos. Apagar las máquinas elimina la memoria volátil — donde frecuentemente están las evidencias más valiosas sobre lo que hizo el atacante y cómo entró. El aislamiento correcto mantiene el sistema encendido pero desconectado de la red, preservando el estado para el análisis.

Borrar logs o reformatear discos antes de un análisis forense básico equivale a limpiar la escena de un crimen antes de la pericia. Aunque la intención sea proteger datos sensibles o acelerar la recuperación, la destrucción de evidencias compromete la capacidad de entender el incidente, de cumplir obligaciones regulatorias y, en casos extremos, puede configurar problemas legales.

Pagar el rescate por impulso, sin análisis previo, es una decisión que debe involucrar al menos una consulta con especialistas antes de tomarse. Pagar no garantiza la recuperación de los datos, financia el desarrollo de nuevos ataques y puede violar sanciones internacionales dependiendo del grupo atacante. En algunos casos, la decodificación proporcionada por el atacante es incompleta o defectuosa incluso después del pago.

Comunicar públicamente antes de tener los hechos es otro error común en startups que, por transparencia o presión de los usuarios, divulgan información imprecisa en las primeras horas. La comunicación prematura puede alertar al atacante de que fue detectado, comprometer la investigación y crear obligaciones jurídicas antes de que se conozca el alcance real.

Obligaciones legales: LGPD, ANPD y BCB

La Ley General de Protección de Datos (LGPD) establece que el controlador debe comunicar a la Autoridad Nacional de Protección de Datos (ANPD) la ocurrencia de un incidente de seguridad que pueda acarrear riesgo o daño relevante a los titulares. El plazo regulatorio consolidado por la ANPD es de hasta 3 días hábiles contados a partir del momento en que el controlador toma conocimiento del incidente.

La comunicación a la ANPD debe contener información mínima: naturaleza de los datos afectados, número aproximado de titulares, medidas técnicas y de seguridad adoptadas, riesgos relacionados con el incidente y las medidas adoptadas o que serán adoptadas. Las startups que no documentan el incidente en tiempo real tienen dificultad para cumplir ese requisito, lo que puede resultar en una sanción adicional por incumplimiento del deber de comunicación.

Las fintech y las empresas que actúan en el sistema financiero tienen obligaciones adicionales ante el Banco Central de Brasil, especialmente bajo la Resolución BCB n.º 85/2021 y normas complementarias sobre seguridad cibernética para instituciones de pago y financieras. Estas normas exigen un plan de respuesta a incidentes formalizado, pruebas periódicas y el reporte de incidentes relevantes a la entidad. El incumplimiento puede resultar en la cancelación de la autorización operativa.

Además de las obligaciones regulatorias, los contratos con clientes enterprise frecuentemente incluyen cláusulas de notificación de brecha con plazos menores que los regulatorios — a veces 24 o 48 horas. Revisar esos contratos antes de un incidente es parte de la preparación mínima viable.

Cuándo y cómo activar un socio externo de IR

La activación de un socio externo de respuesta a incidentes debe ocurrir lo antes posible tras la confirmación de que el incidente es real. La tendencia a intentar resolverlo internamente antes de pedir ayuda es comprensible, pero cada hora sin contención adecuada amplía el alcance del compromiso y aumenta el costo de recuperación.

Con un retainer vigente, la activación es simple: una llamada o un mensaje al canal de emergencia definido en el contrato, con la información inicial recopilada en la fase de detección. La empresa de IR ya conoce el entorno básico del cliente — por el onboarding del retainer — y puede iniciar el triaje remoto en minutos.

Sin retainer, el proceso de contratación en emergencia implica negociar el alcance y el NDA en una situación de presión, transferir el contexto desde cero y frecuentemente disputar la asignación de recursos con otros clientes en emergencia. El costo medio de IR contratado en emergencia en Brasil es significativamente superior al de un retainer anual para startups de pequeño y mediano porte.

Decripte ofrece respuesta a incidentes 24x7 y retainer de IR para startups de 1 a más de 100.000 colaboradores, con SLA de activación definido en contrato y un equipo especializado en entornos de cloud, fintech y SaaS. El plan gratuito de Gestión de Amenazas ya incluye monitoreo de filtraciones y diagnóstico inicial — una forma de comenzar sin costo y evolucionar conforme la madurez de la operación lo exija. Para contratar el retainer o el plan de respuesta a incidentes, acceda a decripte.com.br/plano/resposta-incidentes.

Checklist práctico

1. 1

   1. Documente el plan de respuesta básico

   Cree un documento de máximo dos páginas con los criterios para declarar un incidente, la lista de contactos de escalamiento (interno y externo), la ubicación de las credenciales de emergencia y el orden de las acciones prioritarias. Guarde una copia offline o fuera del entorno principal de trabajo.

2. 2

   2. Active MFA en todas las cuentas críticas

   Revise el acceso a cloud, repositorios de código, plataformas de pago, DNS y correo corporativo. Active MFA en todas esas cuentas — preferentemente con token de hardware o aplicación TOTP. Revoque cualquier sesión activa tras la activación y audite a los usuarios con acceso privilegiado.

3. 3

   3. Configure backups inmutables y pruebe la restauración

   Active políticas de retención inmutable en los proveedores de cloud para los backups más críticos. Programe una prueba de restauración completa al menos una vez por trimestre. Documente el tiempo de recuperación real y mantenga ese número visible para el equipo de ingeniería.

4. 4

   4. Centralice los logs fuera del entorno operativo

   Configure el reenvío de logs de autenticación, accesos privilegiados y cambios de infraestructura hacia un destino separado — un bucket con control de acceso restringido o un SIEM ligero. Defina una retención mínima de 90 días para tener un historial útil en una investigación.

5. 5

   5. Contrate un retainer de IR antes de necesitarlo

   Evalúe a los proveedores de respuesta a incidentes, verifique el SLA de activación y los servicios cubiertos por el retainer — triaje remoto, forense, contención, comunicación regulatoria. Firme el contrato y haga el onboarding de contexto mientras todo funciona normalmente.

6. 6

   6. Ejecute el ciclo NIST en el orden correcto

   Cuando ocurra el incidente: preserve las evidencias antes de actuar, aísle sin apagar, elimine la causa raíz por completo antes de restaurar, vuelva a la normalidad con monitoreo intensificado y documente las lecciones aprendidas en hasta dos semanas tras el cierre.

7. 7

   7. Cumpla los plazos regulatorios sin improvisar

   Notifique a la ANPD dentro de los 3 días hábiles de haber tenido conocimiento del incidente si hay datos personales afectados. Las fintech deben verificar las obligaciones adicionales del Banco Central. Revise los contratos con clientes enterprise para identificar plazos de notificación contractuales, que pueden ser más cortos que los regulatorios.

Preguntas frecuentes