En los últimos dos años, he presenciado una y otra vez el mismo drama en empresas de distintos sectores. El guion apenas varía: a las 4:47 de la madrugada de un sábado, un analista del SOC detecta que una carga útil de ransomware se propaga por tres servidores del centro de datos. El protocolo indica aislarlos. Accionan el interruptor. Dieciséis minutos después, el director financiero llama: esos servidores eran parte de la pasarela de pago en producción. El aislamiento provocó catorce horas de pérdida de ingresos. El lunes, el consejo no pregunta cómo entró el atacante, sino quién estaba autorizado a tomar una decisión de tal magnitud a las 4:47 de la madrugada.

La paradoja de la contención: el poder sin responsabilidad

Esta es la pregunta que la mayoría de los planes de respuesta a incidentes evitan responder. El plan está documentado, el SOC lo tiene abierto en el segundo monitor. Pero falta una pieza clave: ¿quién decide que un sistema crítico para el negocio quede fuera de línea y quién asume las consecuencias? En la mayoría de los manuales, esa autoridad recae implícitamente en el analista de turno, alguien que ni es responsable del proceso empresarial afectado ni puede ver el impacto completo de su acción. Esta asimetría entre autoridad técnica y responsabilidad operativa es lo que llamamos la paradoja de la contención.

La publicación NIST SP 800-61 Revision 3, finalizada en abril de 2025, reestructura el modelo de respuesta a incidentes en torno al NIST Cybersecurity Framework 2.0, desplazando el enfoque de la ejecución táctica hacia la alineación estratégica con la gestión de riesgos. Este giro reconoce que la respuesta a incidentes no es solo una función del SOC, sino una actividad de gestión de riesgos organizacional donde el propietario del negocio debe ser un participante con nombre propio. La ciberresiliencia como brújula del negocio es clave para entender este cambio.

El registro de “no tocar” o cómo proteger las joyas de la corona

La mayoría de los programas de seguridad mantienen un registro de “joyas de la corona”: sistemas cuya pérdida sería existencial. Pero esa lista tiene una segunda función igual de importante: es el inventario de sistemas que el SOC no debe tocar sin confirmación de un responsable de negocio. A esto lo llamamos registro de no intervención. No es una base de datos nueva, sino la misma lista con una columna adicional: para cada activo, qué medidas de contención están preautorizadas y cuáles requieren veto operativo.

RACI para decisiones de contención: asignando responsabilidades

Una vez que existe el registro de no intervención, el modelo RACI para las acciones protegidas se vuelve claro. Siguiendo las recomendaciones del Grupo de Trabajo sobre Ransomware del Instituto de Seguridad y Tecnología, la autoridad de contención recae en el responsable operativo, no solo en seguridad.

En la mayoría de las empresas, esta matriz RACI nunca se ha completado. El coste de esa omisión se hace evidente cuando un regulador o un demandante pregunta quién decidió desconectar el sistema y con qué autoridad. El hacking ético y las pruebas de penetración ayudan a identificar estas brechas de gobernanza antes de que ocurra un incidente.

La objeción: ¿esto ralentiza la respuesta mientras los atacantes actúan?

En todos los talleres surge la misma resistencia: si el SOC tiene que esperar confirmación, el tiempo de permanencia aumenta. Pero esta objeción se basa en tres malentendidos:

• El veto se aplica a una clase muy concreta de activos. No a todo el parque informático, solo a los activos más valiosos. La contención de un portátil comprometido no está vetada.
• El veto tiene una duración limitada. Se define una cadena de escalación con plazos fijos y una acción de respaldo si se agota. Por ejemplo: 5 minutos para contactar al responsable del servicio, 10 minutos al propietario del activo, 15 minutos al directivo de guardia, quien aplica un plan de contingencia de estado seguro preacordado.
• El veto se aplica a acciones, no a detecciones. El SOC conserva plena autoridad para detectar, enriquecer, preservar pruebas y supervisar. Lo que está vetado es el conjunto de acciones que causarían una interrupción no planificada de un servicio crítico.

Tres pasos para implementar el registro de no intervención

No se necesita nuevo software ni presupuesto extra. Solo cuatro horas en una sala con las personas adecuadas y la voluntad de plasmar por escrito decisiones que antes eran implícitas.

1. Elabore el registro. Reúnase con los responsables de los activos empresariales e identifique los sistemas cuya interrupción no planificada sería más dañina que el peor ciberincidente plausible. La lista es más corta de lo que los CISO esperan. La conversación es el resultado real; la tabla, el documento.
2. Incorpore la medida en el manual del SOC. Antes de cualquier acción de contención contra un activo del registro, inserte un punto de control: confirmación de una función empresarial designada, cadena de escalación, plazo máximo y plan de contingencia de estado seguro.
3. Rellene la matriz RACI. Para la contención de activos registrados: propietario del negocio como Responsable, SOC como Encargado, CISO consultado, dirección ejecutiva informada. Rellenar esta columna es la condición previa para poder responder, tras el incidente, quién decidió qué y con qué base.

Para una gestión eficiente de estos procesos, herramientas como NEXGestión permiten automatizar el seguimiento y la gobernanza de estos acuerdos. Además, la evolución hacia plataformas low-code con IA puede facilitar la implementación de estos flujos de decisión.

La prueba de las 4:47 de la madrugada

Si tuviera que hacer un único diagnóstico sobre un programa de respuesta a incidentes, sería este: a las 4:47 de la madrugada de un sábado, con un ransomware propagándose, ¿está autorizado el analista del SOC a desconectar sistemas críticos por su cuenta? Si la respuesta es sí, la gobernanza aún no se ha puesto al día con el coste de esa decisión. Si es no, ¿puede contactar a un responsable designado dentro de un plazo definido y existe un plan de contingencia preacordado? Si ambas respuestas son afirmativas, el registro de no intervención existe en la práctica. Si alguna es negativa, la laguna está en la gobernanza, no en la tecnología.

La paradoja de la contención no se resuelve con automatización más rápida ni añadiendo personas a posteriori. Se resuelve estableciendo por escrito, con antelación y en lenguaje sencillo, quién está autorizado a desconectar qué servicio empresarial y cuál es la respuesta cuando no se puede localizar a esa persona. El documento es de una sola página. La conversación dura horas. El coste de no tenerlo se mide en informes del consejo, documentos regulatorios y solicitudes de información.

Fuente original: ComputerWorld. Análisis y adaptación por ForgeNEX.