Gestión de la respuesta a incidentes

Un inicio de sesión, una actualización de software y una solicitud web son eventos: acontecimientos observables que afectan a activos informáticos. La mayoría de los eventos son normales. Un evento adverso tiene una consecuencia negativa, como un fallo de disco, un corte de electricidad o una infección de malware.

Decide cuándo se necesita una respuesta de seguridad

Un incidente de ciberseguridad pone en peligro, de forma real o inminente y sin autorización legal, la confidencialidad, integridad o disponibilidad de la información o de los sistemas. También incluye infracciones reales o inminentes de leyes, políticas de seguridad, procedimientos de seguridad o políticas de uso aceptable. La organización redacta criterios de incidente para que los analistas puedan aplicar esta definición de forma coherente.

Un atacante que utiliza una contraseña robada causa un incidente incluso antes de que alguien confirme el robo de datos. Un corte de electricidad habitual es un evento adverso, pero normalmente no cumple los criterios de incidente de seguridad. Una brecha de seguridad de los datos es un tipo de incidente que implica el acceso o la divulgación de datos sin autorización. Un ataque de denegación de servicio puede ser un incidente sin una brecha de seguridad de los datos.

Una alerta es una señal que debe investigarse. Cuando las evidencias cumplen los criterios escritos, un analista declara un incidente: abre el registro del incidente, asigna un responsable y activa las reglas de gravedad, respuesta y comunicación del plan. Tratar cada alerta como un incidente genera ruido; esperar a que se demuestre un robo hace que se pasen por alto incidentes que ya amenazan los sistemas.

Relaciona las fases

El ciclo de vida clásico agrupa el trabajo en cuatro fases:

1. Preparación: establece la autoridad, los contactos, el acceso, las herramientas, los registros, las copias de seguridad y los procedimientos practicados.
2. Detección y análisis: valida las señales, establece qué ocurrió, encuentra los activos afectados y evalúa el impacto.
3. Contención, erradicación y recuperación: detén el daño, elimina el acceso del atacante y sus causas, y restaura servicios fiables.
4. Actividad posterior al incidente: revisa la respuesta y haz un seguimiento de las mejoras.

Los temarios de certificación pueden dividir el trabajo intermedio en pasos separados, con siete pasos en total. Esto describe el mismo trabajo con más detalle. Las fases se solapan. Un analista puede descubrir una segunda cuenta comprometida durante la contención y volver a determinar el alcance. Una limpieza fallida puede hacer que un sistema vuelva al aislamiento.

Interpreta el modelo actual del NIST

NIST SP 800-61 revisión 3, publicada en abril de 2025, sitúa la respuesta a incidentes dentro de las seis funciones del Marco de Ciberseguridad (CSF) 2.0. Gobernar, Identificar y Proteger apoyan la preparación mediante una gestión de riesgos más amplia. Detectar, Responder y Recuperar organizan la respuesta a incidentes propiamente dicha. La categoría Mejora dentro de Identificar recopila lecciones de cualquier actividad, incluido un incidente en curso.

Por ejemplo, un equipo descubre durante la contención que su lista de contactos de la nube está obsoleta. Actualiza la lista inmediatamente y registra el cambio para revisarlo. No necesita esperar a que todos los servicios se recuperen para mejorar su preparación. Los incidentes pueden tardar semanas o meses en resolverse, por lo que compartir las lecciones solo al final dejaría una carencia conocida sin resolver durante todo ese tiempo.

Una respuesta necesita tanto autoridad como una forma práctica de ejercerla. Tres niveles de documentación relacionan las decisiones de la dirección con las acciones en una consola.

Asigna a cada documento una función clara

La política establece el compromiso de la dirección, el alcance, las definiciones y la autoridad, incluido quién puede desconectar un sistema. El plan explica cómo responde la organización: funciones, categorías de incidentes, niveles de gravedad, vías de escalamiento, comunicación, recursos y documentación. Los procedimientos generales y de respuesta explican los pasos y las decisiones para situaciones concretas.

Un plan utilizable incluye listas de contactos, suplentes, requisitos de evidencias, enlaces a procedimientos de respuesta y un calendario de revisión. Asigna funciones que se mantienen pese a los cambios de personal. Si solo un directivo designado puede aprobar el aislamiento y no está disponible, el plan tiene un punto único de fallo. Autoriza de antemano la contención para situaciones definidas y designa suplentes para tomar decisiones.

Relaciona las decisiones con las funciones

El responsable de la gestión del incidente, también llamado comandante del incidente, coordina el trabajo, asigna tareas, sigue el estado y toma decisiones dentro de la autoridad que le concede el plan. Los encargados de gestionar incidentes validan los hallazgos, preservan evidencias y ejecutan acciones de respuesta. El personal de sistemas, redes, nube y desarrollo realiza cambios en sus servicios.

La dirección proporciona recursos y aprueba acciones de gran impacto. Los responsables de los activos explican el impacto en el negocio y las prioridades de recuperación. La asesoría legal asesora sobre preservación, contratos y notificaciones; relaciones públicas gestiona las declaraciones públicas. Recursos humanos participa en los casos relacionados con empleados y seguridad física facilita el acceso a las instalaciones.

Un CSIRT interno es un equipo de respuesta a incidentes de seguridad informática. Un modelo externalizado puede recurrir a un proveedor de servicios de seguridad gestionados (MSSP) o a una empresa de respuesta contratada de antemano. Un modelo híbrido combina personal interno de respuesta con especialistas externos. Para los servicios en la nube, registra qué capas gestiona el proveedor y cuáles siguen siendo responsabilidad del cliente, incluido cómo obtener evidencias del proveedor.

Planifica la comunicación antes del incidente

El plan de comunicación indica quién recibe una actualización, quién la envía, cuándo, por qué canal y con qué detalle. Entre los destinatarios internos están quienes responden, la dirección, los responsables de los activos, la mesa de ayuda y el personal afectado. Los destinatarios externos pueden incluir clientes, socios, organismos reguladores, autoridades policiales, aseguradoras y medios. La dirección y la asesoría legal deciden las notificaciones externas; los analistas siguen la vía asignada.

Utiliza comunicación fuera de banda si el correo, el chat o los sistemas de identidad pueden estar comprometidos. Una conferencia telefónica independiente o un servicio de mensajería separado impide que un atacante presente en el entorno principal siga la respuesta. Comparte los detalles del incidente según el principio de necesidad de conocer.

A las 02:10, un analista confirma el cifrado en un servidor de nóminas. El plan clasifica el incidente con gravedad 1. El analista avisa al responsable de la gestión del incidente, quien abre una conferencia telefónica independiente e informa al CISO. La asesoría legal evalúa las implicaciones para los datos personales. Relaciones públicas prepara una declaración preliminar para su aprobación. El registro del incidente recoge cada acción y su hora.

Haz práctica la preparación

Mantén planes sin conexión, contactos actualizados de proveedores y personal, un inventario de activos, diagramas de red, registros centralizados sincronizados, líneas base de actividad y acceso aprobado de antemano para quienes responden. Un kit de respuesta a incidentes contiene un portátil limpio, herramientas forenses, bloqueadores de escritura, almacenamiento, cables, bolsas para evidencias y formularios de custodia. Revisa el plan al menos una vez al año y después de incidentes graves o cambios significativos; comprueba que los contactos y el acceso funcionan realmente.

Un procedimiento de respuesta proporciona pasos y decisiones para un tipo de incidente, como phishing, ransomware, compromiso de una cuenta o exfiltración de datos. Una guía operativa suele referirse a un procedimiento técnico más específico, como aislar un equipo en la consola de detección y respuesta en dispositivos finales (EDR). Los equipos a veces usan los términos de manera diferente, así que defínelos en el plan.

Redacta decisiones que quienes responden puedan seguir

Un procedimiento de respuesta útil indica su desencadenante, las preguntas iniciales de evaluación y clasificación, las evidencias que se deben recopilar, las funciones responsables, las acciones de contención y recuperación, los criterios de escalamiento, los pasos de comunicación y las condiciones de cierre. Una lista de comprobación por sí sola no puede decidir si un administrador comprometido necesita una respuesta distinta de la de una cuenta normal.

Considera el aviso: «Introduje mi contraseña en una página de phishing». Un procedimiento de respuesta puede guiar a la persona encargada por estas acciones:

1. Confirma el aviso y localiza el mensaje.
2. Utiliza los registros de correo y del proxy para identificar a los destinatarios, quiénes hicieron clic y los usuarios que introdujeron credenciales.
3. Restablece las contraseñas expuestas, revoca las sesiones y los tokens, y elimina los dispositivos MFA añadidos por el atacante.
4. Busca accesos del atacante en los registros de inicio de sesión y comprueba las reglas de buzón que reenvían u ocultan mensajes.
5. Bloquea el remitente y la URL, elimina el mensaje de los buzones e informa a los usuarios afectados.

Asocia decisiones a los pasos. Por ejemplo, escala el caso si la cuenta tiene privilegios o aparecen inicios de sesión del atacante. Indica quién aprueba los cambios disruptivos. La automatización puede realizar los pasos rutinarios, pero una acción como apagar un servidor crítico conserva un punto de aprobación humana.

Forma para distintas responsabilidades

Quienes responden practican con el SIEM, el EDR, las herramientas forenses y los procedimientos de evidencias. Los directivos practican decisiones urgentes sobre la interrupción de servicios y los recursos. Todo el personal aprende a comunicar rápidamente la actividad sospechosa y a preservar la situación para investigarla. Borrar un portátil después de encontrar una nota de rescate puede destruir evidencias y retrasar la determinación del alcance.

Un ejercicio de mesa pone a prueba las decisiones mediante el debate. Un facilitador presenta un escenario y después añade información nueva por etapas, llamada información introducida en el ejercicio. Los participantes utilizan el plan para explicar sus siguientes acciones. Esto revela autoridades poco claras, contactos ausentes y suposiciones contradictorias sin modificar los sistemas de producción.

Una simulación, o ejercicio funcional, hace que los participantes realicen acciones con herramientas en un entorno de prueba bajo presión de tiempo. Puede revelar que falla un comando de aislamiento o que una exportación de evidencias tarda más de lo esperado. Un ejercicio a gran escala incorpora a la respuesta a varios equipos y, a menudo, a socios externos.

Convierte los hallazgos del ejercicio en mejoras

En un ejercicio de mesa sobre ransomware, cinco llamadas a la mesa de ayuda informan del cifrado de unidades compartidas a las 07:30. A las 08:15, una nueva información revela la filtración de archivos de recursos humanos. A las 10:00, llama un periodista. El equipo debe decidir quién declara el incidente, quién aprueba la desconexión de los servidores, quién habla públicamente y qué copias de seguridad pueden restaurarse primero.

Si nadie conoce el tiempo de restauración, registra una acción como: «Responsable de almacenamiento: probar una restauración completa del servidor de archivos antes de que termine el trimestre y registrar la duración medida». Actualiza el procedimiento de respuesta y vuelve a probarlo. Un ejercicio es útil cuando revela carencias que la organización puede subsanar; tratarlo como una prueba que hay que aprobar anima a las personas a ocultar precisamente las debilidades que debería descubrir.

Las señales de seguridad llegan mediante alertas del SIEM y del EDR, antivirus, herramientas de detección de red, registros de la nube y de identidad, herramientas de prevención de pérdida de datos e informes de personas dentro o fuera de la organización. Una señal precursora apunta a un posible incidente futuro, como un escaneo o un nuevo código de explotación para software que se utiliza. Un indicador apunta a una actividad que podría haber ocurrido ya o estar ocurriendo.

Construye el contexto de la señal

La recopilación de registros permite acceder a los registros de dispositivos finales, servidores, dispositivos de red, sistemas de identidad y servicios en la nube. Los relojes sincronizados, habitualmente mediante el protocolo de tiempo de red (NTP), ayudan a compararlos. La correlación relaciona registros mediante atributos como equipo, cuenta, dirección y hora. El enriquecimiento añade la criticidad y el responsable del activo, la función del usuario, la ubicación y la reputación según la inteligencia de amenazas.

Una carga de gran volumen desde un servidor de copias de seguridad durante su tarea programada tiene un significado distinto de la misma carga realizada por un proceso desconocido en un portátil de recepción. La reputación puede ayudar a investigar un dominio, pero es solo una parte del contexto.

Evalúa y clasifica la alerta

1. Lee la alerta y comprende qué detectó la regla.
2. Identifica el equipo, el usuario, el proceso y la hora.
3. Comprueba la importancia del activo, los privilegios, el comportamiento normal y las solicitudes de cambio pertinentes.
4. Examina los inicios de sesión, procesos padre, conexiones y archivos relacionados.
5. Comprueba la reputación de dominios, direcciones y hashes de archivos.
6. Decide si la actividad es benigna, un falso positivo o un posible incidente. Escala las dudas que no se hayan resuelto.

Una alerta que identifica correctamente una actividad maliciosa es un verdadero positivo. Un falso positivo se activa ante una actividad benigna. Un falso negativo es una actividad maliciosa que no generó ninguna alerta; no aparece en la cola. Un verdadero negativo es una actividad benigna sin alerta.

Sigue las evidencias hasta la declaración

A las 07:55 UTC, una alerta de EDR informa de un comando de PowerShell codificado en FIN-LT-042. Su proceso padre, WINWORD.EXE, abrió «Invoice_0310.docm» desde un correo electrónico. Después, PowerShell contactó con un dominio registrado tres días antes. Estos hallazgos justifican tratar el caso como un posible incidente e investigarlo sin demora.

El analista decodifica el comando y descubre que descarga y ejecuta un script en memoria. Los registros del proxy corroboran la descarga y el contenido del script demuestra la ejecución maliciosa. La alerta es ahora un verdadero positivo confirmado. El criterio de la organización, «ejecución confirmada de código malicioso en un dispositivo final de la empresa», respalda la declaración del incidente.

Un dominio reciente o un comando codificado por sí solos también pueden aparecer en el trabajo legítimo. La decisión se basa en los hallazgos combinados y en el criterio escrito. Del mismo modo, la negación de un usuario no basta para cerrar el caso sin comprobar los datos.

Mantén el registro de la respuesta desde el principio

Registra el número de caso, la persona que lo comunicó, la hora de detección en UTC, las observaciones, las fuentes de evidencias y cada acción con quien la realizó y su hora. Documenta los falsos positivos y utiliza los hallazgos útiles para ajustar las detecciones. Si el antivirus indica «Amenaza eliminada», investiga cómo llegó y qué se ejecutó antes del cierre: eliminar un archivo deja sin responder si se ejecutó otro código, se expusieron credenciales o permanece algún mecanismo de persistencia.

La determinación del alcance establece los equipos, cuentas, aplicaciones, datos y ubicaciones afectados, así como el punto de entrada y si el atacante sigue activo. El primer equipo que genera una alerta es el punto de partida de esta búsqueda. Los nuevos hallazgos pueden ampliar el alcance durante la contención y la erradicación.

Sigue cada indicador útil

La exploración de registros relacionados consiste en buscar en otras evidencias un atributo encontrado en el caso: un hash, nombre de archivo, dominio, dirección, cuenta, clave del Registro o nombre de tarea. Un dominio malicioso en un portátil puede aparecer en los registros del proxy de otros dos portátiles. Un inicio de sesión desde uno de esos dispositivos en un servidor de archivos introduce otro equipo y otra cuenta que investigar.

Para cada línea de investigación, pregunta cómo comenzó el acceso, qué se ejecutó, qué mecanismos de persistencia se instalaron, qué cuentas se utilizaron, por dónde se movió el atacante, a qué datos se accedió o cuáles se exportaron y cuándo aparecieron la primera y la última actividad. Registra los sistemas como afectados, sospechosos o revisados sin hallazgos coincidentes; explica las evidencias y el periodo de búsqueda que sustentan cada estado.

Normaliza la hora antes de ordenar

Una cronología combina la hora, la fuente, el equipo, el usuario y una descripción del evento. Conserva las marcas de tiempo y los desfases originales, conviértelos a UTC y registra los errores conocidos de los relojes. Las marcas de tiempo locales originales de distintas zonas pueden invertir el orden aparente de un ataque.

Considera estos registros de una investigación:

Resta un desfase positivo para obtener la hora UTC. Después de la conversión, la entrega precede al inicio de sesión, la ejecución y la conexión. Conserva también la fecha, porque la conversión puede cruzar la medianoche. Un desfase registrado con el evento permite resolver los cambios de horario de verano con más fiabilidad que el nombre de una ciudad por sí solo.

Utiliza con cuidado los volúmenes y los intervalos de tiempo

Los registros de flujo de red muestran que se enviaron 2,4 GB al exterior durante 40 minutos. Las unidades SI decimales dan 2400 MB y la duración es de 2400 segundos:

La media es de 1 MB/s. En una estación de trabajo que normalmente envía solo unos pocos megabytes al día, esto es una razón sólida para investigar una posible exfiltración. El volumen no identifica los archivos; combínalo con evidencias de acceso a archivos, procesos y destinos.

El tiempo de permanencia sin detectar transcurre desde el compromiso inicial hasta la detección. Desde el 2 de febrero a las 14:00 UTC hasta el 19 de febrero a las 09:30 UTC transcurren 16 días y 19,5 horas. Un tiempo de permanencia mayor da más oportunidades al atacante y puede hacer que la actividad más antigua quede fuera del plazo de conservación de los registros.

Mantén visible la incertidumbre en la cronología

Distingue los hallazgos confirmados de las hipótesis e indica cada fuente de evidencia. Escribe «Los registros anteriores al 1 de marzo no están disponibles porque el plazo de conservación es de 30 días» cuando esa sea la laguna. Escribir «El atacante llegó el 1 de marzo» convertiría el inicio de las evidencias disponibles en una fecha de inicio sin fundamento. Revisa la contención cuando nuevas exploraciones de registros relacionados revelen otra vía de acceso.

La gravedad describe el impacto del incidente. La prioridad determina el orden de trabajo según el impacto y la urgencia. Una carga activa de archivos confidenciales puede necesitar contención inmediata aunque otro caso grave ya esté estabilizado. El plan de la organización proporciona la escala, los criterios y las expectativas de respuesta.

Evalúa el impacto en el negocio

Considera el impacto funcional: ¿qué servicios del negocio no están disponibles o funcionan de forma deficiente? Considera el impacto en la información: ¿se expuso información privada o propietaria, o se dañó la integridad de los datos? Después evalúa la capacidad de recuperación: ¿pueden los recursos existentes restaurar el servicio de forma previsible, se necesitan recursos adicionales, es incierto el esfuerzo de recuperación o la pérdida es irreversible?

Examina también la importancia del activo, los usuarios y sistemas afectados, la sensibilidad de los datos y si el atacante aún tiene acceso. Un solo controlador de dominio comprometido puede poner en riesgo muchos sistemas. Contar los equipos que generaron alertas sin considerar su función puede infravalorar considerablemente la gravedad.

Aplica la escala del plan

Un ejemplo de escala de cuatro niveles es:

• Gravedad 1, crítica: un servicio esencial para el negocio está caído, se ha confirmado el robo de datos confidenciales o regulados, o un atacante tiene derechos de administrador de dominio.
• Gravedad 2, alta: hay servidores o cuentas con privilegios comprometidos, o el malware se está propagando.
• Gravedad 3, media: una cuenta estándar o estación de trabajo está comprometida y contenida.
• Gravedad 4, baja: se bloqueó un intento o una infracción de una política no tiene impacto.

Según un plan de este tipo, la gravedad 1 podría exigir una respuesta en 15 minutos a cualquier hora. Estas etiquetas y tiempos pertenecen a esa escala de ejemplo; en una respuesta real, aplica los criterios de la organización correspondiente.

Elige el siguiente caso según el riesgo y la urgencia

Llegan tres casos: adware en el portátil de un usuario estándar; una incorporación inesperada a Domain Admins a las 03:12, registrada por el evento 4728 del registro de seguridad; y un sitio web desfigurado sin evidencias actuales de acceso a datos. Investiga primero el cambio en el grupo con privilegios porque el control del atacante en ese grupo amenaza a todo el dominio. Después viene la pérdida de integridad del sitio web y su impacto público; a continuación, el caso limitado de adware.

El registro de incorporación al grupo aún necesita validarse. Determina si estaba autorizado, identifica la cuenta añadida y comprueba su actividad. Una señal de alto riesgo merece un análisis rápido incluso antes de que se confirmen todas sus implicaciones. La clasificación por tipo, como compromiso de cuenta, ransomware o ataque a una aplicación web, permite seleccionar el procedimiento de respuesta y el equipo especializado.

Escala la respuesta y eleva el caso con criterio

El NIST distingue entre el escalamiento de la respuesta, que amplía los recursos o los plazos de respuesta, y la elevación al nivel directivo, que incorpora a un nivel superior de dirección a las decisiones de respuesta. Un especialista forense o una empresa contratada de antemano añade capacidad de respuesta; un CISO que decide si detener un servicio crítico añade autoridad directiva. Ambos pueden darse en el mismo caso.

Sigue los desencadenantes del plan: los incidentes críticos llegan al CISO, la implicación de datos personales incorpora a la asesoría legal y al responsable de privacidad, y la sospecha de uso indebido por un empleado incorpora a recursos humanos. Actualiza la gravedad cuando cambien las evidencias, indicando la hora y el motivo. Un caso tratado inicialmente como adware puede revelar un programa de robo de credenciales y un acceso más amplio; su clasificación debe cambiar con esos hallazgos.

Las evidencias incluyen la memoria, los datos de disco, los registros, las capturas de paquetes, los mensajes, las capturas de pantalla, los registros de auditoría de la nube y las notas de quienes responden. La recopilación comienza con las preguntas del caso y el riesgo de perder los datos necesarios para responderlas.

Trabaja según el orden de volatilidad

La volatilidad describe la facilidad con la que los datos cambian o desaparecen. RFC 3227 ofrece este orden de ejemplo, de mayor a menor volatilidad:

1. Registros y caché de la CPU.
2. Tablas de enrutamiento y ARP, tablas de procesos, estadísticas del núcleo y memoria.
3. Sistemas de archivos temporales.
4. Contenido del disco.
5. Datos de registro y supervisión remotos.
6. Configuración física y topología de red.
7. Medios de archivo, incluidas las copias de seguridad.

Utiliza este orden para planificar la recopilación, comprobando al mismo tiempo los plazos de conservación y las condiciones reales. Un registro de la nube que está a punto de caducar necesita preservarse sin demora. Varias personas pueden preservar distintas fuentes en paralelo mientras el responsable de las evidencias hace un seguimiento del trabajo.

Preserva los datos en vivo antes de reiniciar

La recopilación de evidencias en sistemas en ejecución reúne memoria, procesos, conexiones, usuarios con sesión iniciada, archivos abiertos y otros datos cambiantes de un sistema en funcionamiento. Reiniciar elimina el malware que solo está en memoria, las conexiones activas y las posibles claves de cifrado. El aislamiento de red puede detener la comunicación y mantener disponibles esas evidencias.

Utiliza herramientas fiables desde medios externos de solo lectura o una plataforma EDR. Las herramientas propias del equipo sospechoso pueden haber sido modificadas por un atacante. Cargar una herramienta de recopilación sigue modificando un sistema en ejecución: registra sus comandos, hora, resultado y efectos inevitables para que otro analista pueda comprender la adquisición.

Elige el método de adquisición adecuado

Una imagen forense de disco es una copia bit a bit, incluidos el espacio no asignado y los datos eliminados recuperables. Entre los formatos habituales están las imágenes en bruto dd y Expert Witness (E01). Una copia lógica recopila archivos visibles seleccionados y deja fuera otras áreas de almacenamiento.

Para una unidad sin conexión, utiliza un bloqueador de escritura que impida escribir en el origen durante la creación de la imagen. Los sistemas en ejecución y los volúmenes en la nube utilizan herramientas en vivo o instantáneas del proveedor; un bloqueador de escritura para unidades sin conexión no sirve para esas adquisiciones. Documenta el método de recopilación y los cambios que puede causar.

Exporta los registros de auditoría de la nube y de identidad antes de que se eliminen por el plazo de conservación. Captura instantáneas de discos virtuales y obtén exportaciones del administrador de aplicaciones cuando corresponda. El contrato con el proveedor puede determinar cómo solicitar evidencias de las capas que este gestiona. Una instantánea de disco preserva el estado de un disco; recopila la memoria por separado cuando se necesite esa evidencia volátil.

Realiza la recopilación en un servidor en ejecución

Una alerta de EDR muestra una extracción de credenciales en un servidor de archivos de producción. La persona encargada primero lo aísla mediante la contención del EDR, manteniendo el canal de gestión de seguridad. A continuación, captura la memoria en almacenamiento externo y calcula inmediatamente la huella de la captura. Después, el equipo registra los procesos, las conexiones y las entradas de inicio automático; exporta los registros de seguridad, sistema y PowerShell; y captura una instantánea del disco virtual o una imagen de disco.

Solo después de la preservación decide el equipo si apagar o reconstruir el sistema. Un análisis antivirus completo antes de la recopilación puede eliminar muestras y alterar los metadatos de los archivos. Cuando la destrucción activa no puede detenerse mediante el aislamiento, detener el daño tiene prioridad; registra por qué se aceptó la pérdida de evidencias.

Las evidencias son fiables cuando el equipo puede explicar de dónde proceden, cómo se manipularon y si su contenido cambió. La cadena de custodia, las comprobaciones de integridad y el almacenamiento protegido responden a distintas partes de esa cuestión.

Registra cada transferencia

La cadena de custodia es el registro continuo de la recopilación, manipulación, transferencia y almacenamiento. Asigna a cada elemento un identificador vinculado al caso. Registra su descripción, la marca y el modelo del dispositivo cuando corresponda, el número de serie, el lugar de recopilación, la persona que lo recopiló, la hora y los valores hash. Cada transferencia necesita el remitente, el receptor, la hora, el propósito, las firmas y el nuevo lugar de almacenamiento.

Sella y etiqueta los elementos físicos. Guarda las evidencias digitales en un almacenamiento controlado que registre los accesos. Un hash coincidente no puede explicar un periodo sin documentar en el que una unidad estuvo fuera del almacenamiento controlado; eso es una laguna en la custodia aunque los bytes se verifiquen correctamente después.

Establece una referencia de integridad

Una huella criptográfica (hash) convierte datos en una huella de longitud fija. SHA-256 es una opción habitual. MD5 y SHA-1 tienen debilidades conocidas frente a colisiones, aunque las herramientas pueden registrarlos junto con SHA-256. Un valor SHA-256 coincidente aporta evidencias sólidas de que una copia posterior tiene los mismos bytes que el elemento registrado; no identifica quién creó esos bytes.

Para un origen estable, como una unidad apagada, calcula el hash del origen durante la adquisición y verifica la imagen comparándola con él. El origen debe permanecer estable para que esta comparación tenga sentido. Para la memoria en ejecución, captura primero y calcula inmediatamente el hash del archivo resultante. La memoria cambia durante la adquisición, por lo que intentar calcular dos veces el hash de la memoria en ejecución no proporciona una referencia repetible del origen.

Un cambio diminuto en el contenido puede producir una huella muy distinta. El texto «Case IR-2026-0142» tiene el prefijo SHA-256 45a24047; cambiar el último dígito para obtener «Case IR-2026-0143» da 8e5320c9. Registra el hash completo para verificar las evidencias; estos prefijos cortos ilustran el cambio.

Verifica las transferencias y analiza las copias

Supón que se calcula el hash del elemento de captura de memoria M-03 al adquirirlo. Antes de que un segundo analista abra una copia transferida, vuelve a calcular su SHA-256 y lo compara con el valor de adquisición registrado. Si no coinciden, la copia no ha superado la verificación. Comprueba el elemento de origen, la transferencia, el almacenamiento y los errores de adquisición antes de confiar en ella; vuelve a adquirirla cuando sea posible.

Calcula el hash durante la adquisición, después de las transferencias y antes del análisis. Conserva el original preservado como referencia y analiza copias de trabajo verificadas. Guarda los hashes en el registro de evidencias, donde su relación con el elemento y la hora quede clara.

Preserva los datos durante el tiempo necesario

La preservación incluye almacenamiento de solo lectura o de escritura única, contenedores de evidencias cifrados, acceso controlado y exportaciones de registros que de otro modo caducarían. Suspende la eliminación o la rotación de los registros que necesita la investigación.

Una obligación de conservación por motivos legales, normalmente emitida por la asesoría legal, exige preservar la información pertinente para un litigio o una investigación real o razonablemente prevista. Prevalece sobre los calendarios normales de eliminación para los datos, las personas y los sistemas indicados. El departamento de TI confirma que se ha detenido la eliminación y mantiene la obligación hasta que la asesoría legal la levanta. Reconstruir un portátil no autoriza a borrar su unidad original sujeta a conservación.

El análisis forense digital transforma los datos preservados en respuestas sobre la entrada, la ejecución, el uso de cuentas, la persistencia, el movimiento y la pérdida de datos. Parte de estas preguntas del caso para que el examen tenga un propósito.

Sigue las cuatro fases forenses

NIST SP 800-86 describe la recopilación, que identifica y adquiere datos; el examen forense, que extrae información pertinente preservando su integridad; el análisis, que interpreta esos hallazgos; y el informe, que explica los hallazgos, los métodos, las herramientas y las recomendaciones. Extraer una línea de comandos es examen. Decidir qué muestra sobre el incidente es análisis.

Interpreta los registros de Windows en contexto

El registro de seguridad puede mostrar lo siguiente cuando está activada la auditoría correspondiente:

El evento 7045 del registro System registra la instalación de un servicio. El registro de bloques de scripts de PowerShell utiliza el evento 4104 en un registro de PowerShell. Conserva el canal junto con el identificador del evento para que otro analista pueda recuperar el registro correcto.

Los fallos repetidos seguidos de un éxito para la misma cuenta sugieren adivinación de contraseñas, pero comprueba también el origen y la autorización. Una incorporación a un grupo puede ser administración rutinaria o una obtención de privilegios por parte de un atacante. El registro establece la acción; las evidencias relacionadas establecen su significado.

La persistencia en Windows puede aparecer en las claves Run y RunOnce del Registro, las tareas programadas o los servicios. Prefetch puede mostrar que se ejecutó un programa, cuándo y con qué frecuencia en los sistemas donde está activado. El historial del navegador, las descargas, el contenido de la papelera de reciclaje y los metadatos de la tabla maestra de archivos ($MFT) añaden información sobre la actividad de archivos y usuarios.

Comprueba las evidencias de Linux, memoria y red

Los registros de autenticación de Linux suelen aparecer en /var/log/auth.log en Debian y Ubuntu y en /var/log/secure en sistemas basados en Red Hat. Examina el historial del intérprete de comandos, como ~/.bash_history, las tareas de cron, las unidades de systemd, /etc/passwd, las claves añadidas en ~/.ssh/authorized_keys y los registros de acceso web. El historial y los registros locales pueden estar incompletos o modificados, así que busca registros independientes.

El análisis de memoria, por ejemplo con Volatility, puede revelar procesos, código inyectado, módulos cargados, líneas de comandos y conexiones que nunca llegaron al disco. Los paquetes y registros de flujo de red aportan destinos, tiempos y volúmenes. El tráfico cifrado sigue dejando metadatos útiles incluso cuando su contenido no está disponible.

Construye y cuestiona una explicación

A las 02:09 UTC, el evento 4624 de tipo 10 registra que svc_backup inició sesión desde un equipo interno. Prefetch muestra que RCLONE.EXE se ejecutó por primera vez a las 02:14. Los flujos del cortafuegos muestran que se enviaron 2,4 GB al exterior entre las 02:15 y las 02:55. La secuencia respalda una hipótesis de acceso por RDP seguido de una carga con rclone.

Para establecer la relación, busca telemetría de red vinculada al proceso, la línea de comandos, la configuración o los registros de rclone y evidencias de que este uso de la cuenta no estaba autorizado. Un administrador legítimo puede utilizar el mismo software. Presenta los hechos observados por separado de la interpretación e indica qué lagunas quedan.

Las técnicas antiforenses intentan ocultar la actividad mediante el borrado de registros, la eliminación de datos o el cambio de marcas de tiempo. El evento 1102 puede revelar el borrado del registro de seguridad. Las horas de creación de NTFS en $STANDARD_INFORMATION anteriores a las de $FILE_NAME pueden indicar manipulación de marcas de tiempo. Investiga estas pistas junto con otros artefactos; la ausencia de registros locales deja una pregunta que debe contrastarse con registros remotos y otras evidencias.

La contención limita los daños, la propagación y la pérdida de datos, y da tiempo para investigar. Elígela pronto utilizando el plan, el alcance conocido y las consecuencias de dejar activo al atacante.

Compara las ventajas y los costes

Considera los posibles daños y el robo de recursos, la preservación de evidencias, la disponibilidad del servicio, el tiempo y los recursos necesarios, la eficacia y la duración. Una medida que funciona durante horas puede no ser adecuada durante varias semanas. Registra el efecto previsto y el coste para el negocio de modo que la decisión pueda reevaluarse cuando cambie el alcance.

La contención a corto plazo actúa inmediatamente: aísla un equipo, desconecta una vía de red, bloquea un dominio o una dirección del atacante, desactiva una cuenta comprometida, revoca sesiones y tokens o detiene un servicio. La contención a largo plazo mantiene las actividades esenciales bajo restricciones mientras se prepara la erradicación. Puede utilizar un segmento de red restringido, permisos más estrictos, reglas temporales de cortafuegos, parches de emergencia y una mayor supervisión.

Distingue los niveles de restricción

La segmentación limita los sistemas que pueden comunicarse. El aislamiento desconecta un equipo salvo, posiblemente, de su canal de gestión de seguridad. La retirada deja un sistema completamente fuera de servicio, por ejemplo apagándolo. El apagado hace que se pierda la memoria volátil; un aislamiento de red exitoso puede preservar esa evidencia mientras bloquea las comunicaciones del atacante.

Una consola EDR puede informar de una solicitud de aislamiento antes de que esta se complete. Comprueba el estado resultante y el tráfico. Verifica también que el canal de gestión permitido solo llegue a la infraestructura de seguridad necesaria para la respuesta.

Coordina las vías de acceso conocidas

Si un atacante tiene varios puntos de apoyo, bloquear un equipo puede alertarlo mientras siguen disponibles otros accesos. Puede cambiar de cuenta, destruir datos o iniciar el cifrado. La contención coordinada elimina las vías conocidas al mismo tiempo después de determinar suficientemente el alcance. El cifrado o la exfiltración activos requieren una acción inmediata para detener el daño; esperar a tener un conocimiento perfecto puede agravar la pérdida.

En un caso de phishing, FIN-LT-042 y FIN-LT-057 contactaron con el dominio del atacante y una cuenta de administrador de finanzas accedió a un servidor de archivos. A las 10:30 UTC, quienes responden aíslan ambos portátiles, bloquean el dominio en el DNS y el proxy, desactivan la cuenta de administrador y revocan sus sesiones. Después restringen el acceso al servidor de archivos, amplían el registro de eventos y continúan buscando indicadores en todo el entorno.

La coordinación abarca los equipos, el acceso a la red y la identidad. Desactivar únicamente una cuenta local puede dejar utilizable un token existente en la nube. Incluye esas sesiones en el plan de contención y verifica el resultado en los registros de identidad.

Comprueba que la contención se mantiene

Confirma el estado de aislamiento en el EDR, inspecciona los registros de DNS y del proxy en busca de nuevas conexiones del atacante y comprueba si las cuentas comprometidas siguen autenticándose correctamente. Busca actividad a partir de los indicadores recién descubiertos y revisa el límite de contención cuando sea necesario.

Algunas organizaciones optan por observar de forma controlada a un intruso para aprender más antes de la contención. Como esto deja abierta una vía para causar más daños, requiere la aprobación de la dirección y de la asesoría legal. Eliminar el archivo de malware detectado tampoco basta como estrategia de contención: pueden seguir activos otros accesos, mecanismos de persistencia e identidades expuestas incluso después de que desaparezca ese archivo.

La erradicación elimina al atacante y lo que dejó: malware, puertas traseras, intérpretes de comandos web maliciosos, tareas, servicios, entradas del Registro, cuentas, claves SSH y otros mecanismos de persistencia. La corrección de vulnerabilidades repara las debilidades que hicieron posible la intrusión. Ambas dependen de comprobar todo el alcance del incidente.

Decide si la limpieza puede restablecer la confianza

Reconstruir a partir de una imagen de confianza o una plantilla de infraestructura como código es más fiable cuando un atacante tenía derechos de administrador, utilizó un rootkit o dejó mecanismos de persistencia desconocidos. Una limpieza específica puede ser adecuada para malware común bien conocido en un sistema de poco valor, siempre que la verificación cubra los cambios conocidos.

Una copia de seguridad creada después del compromiso puede restaurar el acceso del atacante junto con los archivos legítimos. Comprueba cuándo comenzó el compromiso, qué contiene la copia de seguridad y si la imagen o la plantilla es de confianza antes de utilizarla. Preserva las evidencias necesarias antes de reconstruir un sistema afectado.

Elimina el acceso mediante identidades además de los archivos

Contén sin demora las cuentas y sesiones comprometidas. Coordina la sustitución duradera de las credenciales después de cerrar las vías de acceso del atacante y establecer un lugar limpio donde utilizar los nuevos secretos. De lo contrario, un intruso puede robar las credenciales de reemplazo desde el mismo equipo comprometido.

Restablece las credenciales de usuario y de servicio expuestas, revoca tokens, sesiones y claves de API, y rota los secretos de las aplicaciones. Elimina los métodos MFA añadidos por el atacante, las reglas de reenvío y las cuentas no autorizadas. Considera todas las credenciales expuestas en los sistemas comprometidos, incluidas las cuentas que aún no han generado su propia alerta.

Ante la sospecha de tickets Kerberos falsificados, la recuperación coordinada de Active Directory incluye restablecer dos veces la contraseña de KRBTGT, con replicación entre ambos restablecimientos. Los controladores de dominio pueden aceptar tickets protegidos por la contraseña actual o la anterior, por lo que un solo restablecimiento deja vigente la clave anterior. Se trata de una acción coordinada de dominio con verificación, no de un paso aislado de limpieza de una estación de trabajo.

Corrige la causa y verifica la corrección

Aplica parches al software explotado, corrige configuraciones incorrectas, exige MFA donde faltaba, elimina privilegios excesivos y cierra servicios expuestos. Si no hay una solución completa disponible, aplica un control compensatorio, como una regla de cortafuegos de aplicaciones web o acceso solo mediante VPN, y registra el riesgo restante.

Un servidor público contiene un intérprete de comandos web malicioso introducido mediante un fallo de carga sin parchear. El equipo comprueba si hay otros servidores vulnerables y encuentra dos más. Reconstruye los tres a partir de una plantilla endurecida, despliega la aplicación corregida, rota el secreto de la base de datos almacenado en la configuración de la aplicación y busca solicitudes al intérprete malicioso en los registros de los servidores.

Un escaneo de vulnerabilidades confirma que el fallo está corregido. El equipo comprueba las ubicaciones de persistencia, escanea con firmas actualizadas, busca todos los indicadores conocidos y supervisa los inicios de sesión y las conexiones del atacante. En este caso, siete días de supervisión no muestran solicitudes exitosas a la ruta del intérprete malicioso. Los criterios de erradicación del plan determinan si estas evidencias son suficientes.

Parchear el fallo de carga cerraría una vía de entrada, pero dejaría intacta cualquier puerta trasera existente. Eliminar solo el intérprete malicioso retiraría un artefacto, pero dejaría la aplicación explotable. Por tanto, la verificación necesita evidencias tanto del acceso restante del atacante como de la corrección de la debilidad.

La recuperación devuelve los sistemas y servicios a su funcionamiento normal mediante la restauración, la reconstrucción, la reconexión y las pruebas funcionales. Puede comenzar para los sistemas no afectados o verificados como limpios mientras la erradicación continúa en otros lugares.

Selecciona fuentes de restauración fiables

Comprueba si las copias de seguridad presentan corrupción, cifrado o indicios de compromiso. Elige un punto anterior a la entrada del atacante y verifica la versión o la huella criptográfica de las imágenes de reconstrucción. Una copia de seguridad reciente puede contener los mismos mecanismos de persistencia que el equipo acaba de eliminar. Su fecha por sí sola no demuestra que esté limpia.

Identifica el trabajo que la restauración dejará fuera. Una copia de seguridad del 3 de marzo a las 23:00 UTC es 7 horas y 20 minutos anterior a un compromiso que comienza el 4 de marzo a las 06:20 UTC. Ese intervalo describe la antigüedad de la copia en el momento del compromiso. Restaurarla supone perder todos los cambios posteriores hasta que el sistema quedó fuera de servicio, incluido el trabajo legítimo realizado después de las 06:20, salvo que los cambios limpios puedan recuperarse de otro lugar.

Las posibles fuentes incluyen archivos verificados como limpios o copias locales de los usuarios. Valídalos antes de incorporar los cambios recuperados para que la restauración no vuelva a introducir contenido malicioso ni sobrescriba datos fiables.

Restaura según el orden de las dependencias

Las prioridades del negocio y las dependencias técnicas se complementan. Una aplicación ERP necesita su base de datos; la base de datos y la aplicación pueden necesitar primero servicios de red, DNS e identidad. Un orden habitual es red e identidad, base de datos, ERP y, por último, herramientas de informes. Iniciar primero la aplicación puede producir un proceso en ejecución sin un servicio útil detrás.

Utiliza los objetivos de recuperación acordados, incluidos los tiempos aceptables de inactividad y de pérdida de datos, como datos para establecer el orden. Confirma que las propias dependencias son fiables antes de conectarles los sistemas restaurados. Una aplicación crítica conectada a un servicio de identidad comprometido sigue expuesta.

Aplica los criterios de levantamiento del aislamiento

Antes de reconectar, verifica que el sistema se ha reconstruido o limpiado, está parcheado y no contiene mecanismos de persistencia conocidos. Rota las credenciales expuestas, confirma que las herramientas de seguridad están funcionando y enviando informes, establece una supervisión reforzada y obtén la aprobación del responsable del activo. Reconecta por etapas para poder contener un comportamiento inesperado antes de que afecte a todo el servicio.

Para el servidor de archivos reconstruido, el equipo restaura una copia de seguridad comprobada, escanea los datos en busca de indicadores conocidos, restaura los permisos y pide al responsable que pruebe la apertura y modificación de archivos representativos. Las comprobaciones de seguridad incluyen los informes del EDR y las conexiones previstas. El responsable aprueba la puesta en servicio después de estas pruebas y el equipo inicia el periodo de supervisión acordado.

Distingue la puesta en servicio del fin de la recuperación

Compara los procesos, las conexiones, el rendimiento y el comportamiento del servicio con la línea base normal. Un plan de respuesta podría establecer 30 días de supervisión reforzada, con alertas adicionales para los indicadores del incidente. Establece el periodo y los criterios según el caso y el plan.

El responsable de la gestión del incidente declara completa la recuperación cuando los servicios están restaurados y estables, el periodo de supervisión no muestra actividad del atacante y la documentación de la respuesta está completa.

El ransomware cifra datos o bloquea sistemas y exige un pago para recuperar el acceso. En la doble extorsión, los atacantes también roban datos y amenazan con publicarlos. La extorsión con datos robados puede ocurrir sin cifrado, por lo que el daño visible en los archivos es solo una parte de la investigación.

Reconoce la actividad antes del cifrado

Una secuencia de ataque habitual comienza con phishing, credenciales de acceso remoto robadas o una vulnerabilidad expuesta. Los atacantes descubren sistemas, roban credenciales, se mueven lateralmente, desactivan herramientas de seguridad, atacan las copias de seguridad y exfiltran datos antes del cifrado masivo.

Las señales de advertencia incluyen herramientas inesperadas de administración remota, nuevas cuentas con privilegios, cargas de gran volumen y eliminación de copias de sombra. Un comando como vssadmin delete shadows debe investigarse en el contexto de su proceso y usuario. Estas señales precursoras pueden dar a los defensores la oportunidad de intervenir antes de que comience el cifrado generalizado.

Sigue los tres primeros pasos de respuesta

La lista de comprobación de CISA para el ransomware establece estas acciones en orden:

1. Identifica y aísla inmediatamente los sistemas afectados. Prioriza los sistemas críticos. Si hay varios sistemas o subredes afectados, desconecta en el conmutador cuando sea necesario. Protege los sistemas críticos no afectados y las copias de seguridad de las mismas vías de acceso.
2. Apaga solo si es imposible desconectar de la red. El apagado sacrifica evidencias volátiles, incluidas posibles claves y actividad que solo existe en memoria, pero puede ser necesario para evitar una mayor propagación cuando no se puede lograr el aislamiento.
3. Evalúa y clasifica los sistemas para su restauración. Utiliza la lista de activos críticos y las dependencias técnicas para identificar qué servicios deben volver primero.

Coordina mediante una llamada telefónica u otro canal fuera de banda. Los atacantes pueden supervisar el correo o el chat de la empresa y reaccionar acelerando la destrucción. Verifica que el aislamiento se haya realizado correctamente antes de confiar en él.

Preserva las evidencias y establece el alcance del ataque

Captura evidencias de memoria y disco de una muestra representativa de los sistemas afectados y toma instantáneas de los volúmenes pertinentes en la nube. Conserva las notas de rescate, las extensiones de los archivos cifrados, las muestras de malware, los registros y los indicadores. Estos elementos ayudan a identificar la variante, reconstruir la entrada y el movimiento, y respaldar la investigación de los colaboradores de la respuesta.

Utiliza la nota, la extensión y las muestras para comprobar si existe una herramienta de descifrado mediante servicios de confianza como No More Ransom o las autoridades policiales. Investiga también el acceso anterior y la exfiltración. Recuperar los archivos cifrados no aclara si los atacantes aún tienen una cuenta, un token o una puerta trasera.

A las 03:40 UTC de un sábado, dos servidores de archivos muestran aproximadamente 1200 cambios de nombre por minuto, o 20 por segundo, con la extensión «.lckd». La persona encargada aísla los servidores y el controlador de dominio utilizado por la cuenta del atacante, y el equipo de red desactiva el enlace ascendente del segmento afectado. Los sistemas permanecen encendidos. Una persona encargada captura la memoria de un servidor y guarda la nota mientras otra comprueba las copias de seguridad protegidas.

Activa la participación de los colaboradores previstos en el plan

El responsable de la gestión del incidente incorpora a la dirección, la asesoría legal, la aseguradora y las autoridades policiales según el plan. Las condiciones del seguro pueden exigir una notificación rápida o empresas de respuesta aprobadas. La asesoría legal determina las obligaciones de notificación aplicables cuando hay datos implicados. Haz un seguimiento de estas líneas de trabajo mientras continúa la contención técnica. La reinstalación inmediata destruiría evidencias y podría devolver un servidor a una red en la que el atacante aún tiene acceso.

La recuperación tras un ataque de ransomware debe eliminar la capacidad del atacante para repetir el daño. Contén el acceso conocido, erradica la persistencia, establece un entorno limpio, sustituye las credenciales expuestas y restaura los datos comprobados en sistemas reconstruidos. Devuelve al servicio solo los sistemas verificados como limpios.

Protege y prueba la fuente de recuperación

Las copias de seguridad desconectadas, inmutables o protegidas de otro modo pueden sobrevivir a los intentos de eliminar las copias en línea. Antes de usarlas, comprueba que el punto seleccionado sea anterior al compromiso, no esté cifrado y no contenga herramientas ni mecanismos de persistencia conocidos del atacante. Una copia sin cifrar del periodo de permanencia del atacante aún puede ser insegura.

Mide de antemano la tasa de transferencia de restauración. En unidades SI decimales, 48 TB son 48 000 000 MB. A una tasa medida de 400 MB/s, la transferencia continua tarda:

Son 120 000 segundos, o aproximadamente 33,3 horas. Si los servicios críticos solo requieren 6 TB, su transferencia es:

Son aproximadamente 4,2 horas. Estos son tiempos de transferencia. Las reconstrucciones, la validación, las dependencias y la reconexión también llevan tiempo, por lo que deben aparecer en la estimación de recuperación operativa. Restaura los servicios críticos según el orden de sus dependencias en lugar de poner todos los conjuntos de datos en cola con la misma prioridad.

Investiga la infraestructura de identidad

El ransomware dirigido por personas suele implicar el robo de credenciales con privilegios. Establece si se comprometieron cuentas con privilegios, controladores de dominio o KRBTGT. Cuando se confirma o se sospecha razonablemente el compromiso del dominio, coordina su recuperación: reconstruye o restaura controladores fiables, restablece las credenciales con privilegios y de servicio, revisa la directiva de grupo y realiza los restablecimientos necesarios de KRBTGT con replicación entre ellos.

La directiva de grupo puede distribuir cambios en muchos equipos. Dejar activa una directiva maliciosa o una identidad de confianza controlada por el atacante puede poner en peligro servidores reconstruidos que, por lo demás, están limpios. El alcance determina hasta dónde debe llegar este trabajo; el cifrado de una sola estación de trabajo no demuestra por sí solo el compromiso del dominio.

Comprende qué puede y qué no puede resolver el pago

CISA y el FBI desaconsejan pagar el rescate. Un pago no garantiza una herramienta de descifrado que funcione ni la eliminación de los datos robados. Las herramientas de descifrado pueden ser lentas, defectuosas o incompletas. El pago financia más delitos y la víctima puede volver a ser atacada. En 2021, la Oficina de Control de Activos Extranjeros (OFAC) del Departamento del Tesoro de Estados Unidos advirtió que los pagos por ransomware pueden infringir las sanciones. La dirección trabaja con la asesoría legal y normalmente con la aseguradora; un analista no decide pagar.

Presenta a la dirección las opciones de recuperación verificadas, los tiempos de restauración medidos, la exposición de datos conocida y las preguntas sin resolver. Consulta fuentes fiables de herramientas de descifrado antes de considerar el pago como la única vía. Una herramienta de descifrado no elimina la persistencia ni corrige la vía de acceso inicial.

Continúa la respuesta a los datos robados

La restauración del servicio no resuelve la divulgación. Identifica qué datos se sustrajeron y quiénes están afectados, apoya la evaluación de notificaciones de la asesoría legal y supervisa los sitios de filtraciones pertinentes. No se puede verificar la promesa de un atacante de eliminar las copias.

Después, refuerza las copias de seguridad protegidas y las pruebas de restauración, exige MFA en el acceso remoto y detecta actividades tempranas como la eliminación de copias de seguridad. Comparte los indicadores pertinentes con las autoridades o los grupos sectoriales mediante el proceso aprobado por la organización.

Una revisión posterior al incidente, o revisión de lecciones aprendidas, examina qué ocurrió, cómo funcionó la respuesta y qué debería cambiar. Comparte las lecciones útiles en cuanto aparezcan durante el incidente. Realiza una revisión estructurada después de los incidentes significativos mientras las evidencias y las decisiones aún están frescas.

Prepara una explicación compartida del incidente

Una revisión suele realizarse entre unos días y dos semanas después del cierre. Reúne a quienes respondieron, al personal técnico, a los responsables de los activos, a la dirección y a las demás partes implicadas. Utiliza un facilitador para mantener centrado el debate. Un incidente grave merece su propia revisión; los casos menores pueden agruparse en sesiones periódicas.

Prepara la cronología del incidente, el registro de acciones, el alcance, el impacto y las mediciones pertinentes. Distingue lo que se sabía en el momento de una decisión de la información descubierta después. De lo contrario, el equipo puede juzgar una decisión inicial razonable utilizando hechos que no estaban disponibles para quien la tomó.

Pregunta tanto por la respuesta como por el ataque

Examina qué ocurrió y cuándo, cómo se produjo la detección y qué pasos funcionaron bien. Después examina los retrasos, las instrucciones poco claras, las herramientas y los permisos que faltaban y la información que se necesitaba antes. Identifica las señales precursoras o los indicadores que podrían revelar otro intento.

Una revisión sin culpabilización se centra en los sistemas, los procesos y las decisiones. Registrar que alguien hizo clic en un enlace de phishing es necesario para explicar la entrada. Detenerse ahí ofrece poca orientación sobre por qué un solo clic permitió acceder a un servidor de archivos. Pregunta qué controles, privilegios y disposiciones de respuesta permitieron que aumentara el impacto.

Conserva lo que funcionó y corrige lo que falló

En una respuesta a phishing, el EDR detectó la ejecución en 15 minutos. Mantén la detección y verifica que siga siendo eficaz. La contención tardó 2,5 horas porque el analista de guardia no tenía derechos de aislamiento en el EDR. Crea un cambio de acceso específico con un responsable y una prueba, utilizando los límites de autoridad del plan.

El servidor de archivos carecía de auditoría de acceso a archivos, por lo que el equipo no pudo determinar qué archivos se leyeron. Registra esa laguna de evidencias y activa una auditoría adecuada. El procedimiento de respuesta para cuentas omitía la revocación de tokens de la nube; actualízalo y haz que quienes responden practiquen el paso revisado. Estos hallazgos abordan fallos distintos y necesitan acciones separadas.

Redacta un informe posterior a la actuación que pueda utilizarse

El informe contiene un resumen ejecutivo, la descripción y cronología del incidente, el alcance y el impacto, la causa raíz y los factores contribuyentes, las acciones de respuesta con sus horas, lo que funcionó y lo que falló, las acciones correctivas con responsables y fechas límite, y las métricas del incidente. Utiliza las evidencias para respaldar los hallazgos y mantén visibles las preguntas sin resolver.

Incorpora los cambios aprobados en el plan, los procedimientos de respuesta, las detecciones, las listas de contactos, la formación y el registro de riesgos. Comparte indicadores o lecciones con los grupos pertinentes mediante el proceso aprobado. Asigna a la lista de acciones un lugar de seguimiento para que las reuniones posteriores puedan comprobar el progreso.

«Comunicarse mejor» deja sin definir el responsable, el cambio y la prueba de éxito. Una acción útil podría especificar una conferencia telefónica independiente para incidentes, su responsable, una fecha límite y una prueba de que el personal de guardia puede unirse sin acceso a la identidad corporativa. La revisión termina como reunión; el trabajo de mejora continúa hasta que se verifican sus acciones.

El análisis de causa raíz (RCA) pregunta por qué existían las condiciones para que se produjera un incidente. La causa inmediata es la causa técnica directa. Los factores contribuyentes hicieron que el incidente fuera más probable o más dañino. Un fallo subyacente de un proceso puede explicar por qué esos factores siguieron presentes.

Sigue las causas más allá del primer fallo

La técnica de los 5 porqués pregunta repetidamente por qué fue posible un fallo. El nombre describe un enfoque, no una obligación de detenerse exactamente en cinco preguntas. En un caso de ransomware:

1. Los servidores se cifraron porque el atacante obtuvo derechos de administrador de dominio.
2. Esas credenciales se obtuvieron de un servidor accesible.
3. El atacante llegó a él mediante una cuenta de VPN de un contratista sin MFA.
4. La cuenta tenía una exención temporal de MFA procedente de una migración de dos años antes.
5. Las exenciones no tenían fecha de caducidad ni proceso de revisión.

La ausencia de un proceso de revisión es una causa subyacente en esta cadena. La falta de MFA y las credenciales con privilegios expuestas siguen siendo factores técnicos que deben corregirse. Un diagrama de espina de pescado, también llamado diagrama de Ishikawa, agrupa las posibles causas bajo encabezados como personas, procesos, tecnología y entorno. El análisis de la cronología pregunta qué control podría haber detenido o revelado cada etapa.

Redacta acciones con una prueba de finalización

Una acción correctiva necesita un cambio específico, un responsable, una fecha límite, un resultado medible y una verificación. Por ejemplo: «Exigir MFA en las 214 cuentas de VPN antes del 30 de noviembre; responsable: jefe de gestión de identidades y accesos; verificar mediante un informe que muestre cero cuentas de VPN sin MFA».

Haz un seguimiento de las acciones en el sistema de casos o de riesgos y comprueba que funcionen, también en un ejercicio posterior. Las acciones preventivas reducen la recurrencia; las acciones de detección revelan antes el siguiente intento. Añadir una revisión de caducidad aborda el proceso de exenciones, mientras que una alerta por el uso de cuentas exentas añade detección. Una sola acción no tiene que cubrir todas las partes de la solución.

Define la métrica antes de calcularla

El tiempo medio de detección (MTTD) calcula la media del intervalo entre el inicio de la actividad maliciosa y su detección. El tiempo de contención suele transcurrir desde la detección hasta la contención; el tiempo de corrección, desde la detección hasta la solución. Los equipos también siguen el tiempo de permanencia sin detectar, las categorías y la gravedad de los incidentes, y los casos detectados internamente frente a los comunicados desde el exterior. Indica los puntos de inicio y fin porque las organizaciones usan algunos nombres de métricas de forma diferente.

Cuatro retrasos de detección son de 2, 30, 6 y 82 horas:

La media es de 30 horas. Ordena los valores como 2, 6, 30 y 82; la mediana es la media de los dos valores centrales:

El caso de 82 horas eleva considerablemente la media. Informa de ambas medidas e investiga ese caso. Si la contención tardó 1,5; 4; 3 y 9,5 horas, la media es 18 dividido entre 4, es decir, 4,5 horas.

Compara las tendencias solo con definiciones coherentes y un contexto adecuado. Un equipo recompensado únicamente por cerrar casos rápido puede cerrarlos antes de terminar el análisis. Combina la rapidez con evidencias de una respuesta completa y acciones verificadas para que la métrica apoye la mejora.