Ciberseguridad · Respuesta a incidentes · 10 min
Responder a un incidente no es improvisar. Al terminar sabrás decir en qué fase estás, qué hace cada fase, y cuál es el error que hace que el incidente vuelva a la vida.
Un evento es algo observable en un sistema o red: puede ser normal o sospechoso. Un incidente es un evento con impacto real o probable en la seguridad — confidencialidad, integridad o disponibilidad. Un exploit publicado no ha tocado nada todavía; un servidor que se cifra delante de ti ya ha pasado.
La primera habilidad de la respuesta es este juicio: convertir señales en una decisión. La taxonomía del módulo lo afina con dos palabras que vas a necesitar:
Precursor — «algo podría ocurrir». Un exploit nuevo para un servicio expuesto, un boletín de vulnerabilidad crítica sin parche.
Indicador — «algo ocurre o ya ocurrió». Una conexión saliente a un servidor de mando y control, un cifrado masivo, una cuenta privilegiada activa a las 3 de la mañana.
Y en el SOC, una alerta aislada rara vez cuenta toda la historia: se correlacionan fuentes — el SIEM, el EDR, los logs, las personas — antes de saltar. La decisión «¿hay incidente?» necesita contexto, no reflejos.
El plan no es un PDF que se guarda: son contactos, canales alternativos, herramientas, inventario de servicios críticos y copias que se prueban. Y prepararse también previene: bastionado, parches, logs con relojes sincronizados, formación, simulacros.
Detectar y analizar convierte señales dispersas en una decisión: correlaciona el SIEM, el EDR, los logs y las personas. Analizar es hacer buenas preguntas.
Priorizar cruza el impacto funcional, el impacto sobre la información y el esfuerzo de recuperación. La severidad — baja, media, alta, crítica — es lo que activa recursos y escalados, no lo ruidosa que suena la alerta.
Aislar el equipo, bloquear el dominio, deshabilitar la cuenta. Cada medida se elige con criterio: su coste sobre la disponibilidad y las evidencias que hay que conservar. Apagar el servidor crítico sin autorización puede empeorar el incidente que intentabas frenar.
Eliminar malware y persistencia, corregir la vulnerabilidad, rotar credenciales y tokens, revisar cuentas y permisos y buscar indicadores en toda la organización. Si entraron por una VPN sin doble factor, cerrar una sesión no arregla nada.
Restaurar desde una copia verificada, validar la integridad, aplicar parches antes de exponer, monitorizar de forma reforzada y confirmar con el propietario del servicio. La normalidad no se decide por intuición.
Reunión de lecciones aprendidas, línea temporal completa, causa raíz cuando se pueda, acciones correctivas con responsable y fecha, y revisión del plan y los playbooks. Aprender exige responsables y fechas, no buenas intenciones.
Preparar, detectar y analizar, priorizar, contener, erradicar, recuperar y aprender. El ciclo no siempre avanza en línea recta: puedes contener un equipo y volver al análisis si aparecen nuevos indicios; y la mejora continua cierra el bucle sobre la preparación.
Cuando ya sospechas o confirmas un incidente, toca priorizar. La severidad se asigna por el impacto real y probable, no por orden de llegada:
Y el escalado es un flujo, no un capricho: confirmar indicios → clasificar severidad → activar al responsable de seguridad → convocar al equipo → escalar a legal, dirección o comunicación → ejecutar el playbook y hacer seguimiento. Un incidente alto o crítico no puede quedarse solo en el equipo técnico. La política da esa autoridad: el equipo puede saber qué hacer sin tener autoridad para aislar un sistema.
Baja: sin impacto en servicios críticos. La severidad no mide lo alarmante que suena la alerta, mide el impacto real; y es ese impacto el que activa recursos y escalados. Nadie mueve un equipo completo por una alerta bloqueada en un puesto no crítico.
Todo lo anterior en una sola tarde. A las 9:14 varios usuarios no pueden abrir documentos de la carpeta compartida; aparecen extensiones raras y el EDR alerta en un equipo administrativo. Mira la red mientras avanzas.
9:14. El EDR dispara en el puesto administrativo y, a los usuarios, les faltan documentos. La alerta es una señal, no un veredicto: todavía hay que convertirla en una decisión.
La carpeta compartida da servicio a varias áreas. No te quedas en «documentos raros»: haces preguntas. ¿Qué equipo empezó? ¿Qué usuario abrió la puerta? ¿Hay más equipos con el mismo patrón? ¿El destino aparece en inteligencia? ¿El activo es crítico? Analizar es hacer buenas preguntas.
Contener frena el daño con el menor impacto necesario: aislar el equipo afectado, proteger las copias, deshabilitar la cuenta comprometida. El servidor crítico se desconecta si hace falta — con la autoridad y las evidencias correspondientes.
Aísla el puesto y protege las copias. Eso es contener: frenar el daño con el menor impacto necesario. El servidor de nóminas sigue funcionando; si hay que tocarlo, será una decisión escalada, no un reflejo.
El malware fuera no basta. Hay que eliminar la persistencia y el mecanismo que lo mantuvo vivo: rotar credenciales y tokens, revisar cuentas y permisos, buscar indicadores en toda la organización. Si entraron por una VPN sin doble factor, cerrar una sesión no arregla nada.
El servicio vuelve desde la copia verificada: integridad validada, parches antes de exponer, monitorización reforzada y confirmación con quien usa el servicio. La normalidad no se decide por intuición.
Recuperar sin erradicar reintroduce el incidente. La persistencia y las credenciales comprometidas siguen dando acceso. Por eso la causa se busca antes de restaurar y cada restauración se valida: no es burocracia, es lo que separa una recuperación de una reinfección.
Son las tres que más se mezclan, y la mezcla suele significar dos incidentes. Cada una responde una pregunta distinta:
La última fase no es «por fin funciona». Es una reunión de lecciones aprendidas, una línea temporal completa, la causa raíz cuando se pueda, acciones correctivas con responsable y fecha, y la revisión del plan y los playbooks. Sin responsables ni fechas, el aprendizaje es una intención. Y cada incidente se registra con un mínimo — identificador, fecha, estado, responsable, causa raíz y mejoras — que es lo que hace posible el siguiente informe.
El informe describe acciones, evidencias y lecciones; las credenciales comprometidas se describen como rotadas, jamás se copian en claro a un documento. Quien cierra un incidente con contraseñas en claro dentro ya ha filtrado el siguiente. Y el informe tiene dos mitades — lo que pasó y lo que hiciste: el resumen, el alcance, las evidencias, las acciones, las comunicaciones y las medidas correctivas tienen su sitio.
El proceso necesita papeles, y no son intercambiables. La política dice qué debe cumplirse y da autoridad: quién puede declarar un incidente crítico o aislar un sistema. El plan organiza la respuesta: equipos, canales y escalado. El playbook guía un escenario — qué hacer ante un ransomware. Y el runbook baja al detalle repetible: el comando exacto para aislar un equipo o restaurar una copia. Un ransomware los necesita todos a la vez.
La política responde «qué y quién», el plan «cómo nos organizamos», el playbook «qué hacemos en este escenario» y el runbook «qué tecleo». Cuando a un analista solo se le da el runbook, sabe teclear pero no sabe si debe; por eso van juntos.
El proceso se convierte en plan en el punto 4.1.2, el plan se concreta en playbooks y runbooks en 4.1.3, y la recuperación conecta con la ciberresiliencia en 4.3.1. Fuera del módulo, monta una mesa de crisis en papel: es la forma más barata de descubrir que falta autoridad, un contacto o una copia probada.