Quién ejecuta la contención cuando el SOC detecta un incidente
Resume este artículo con tu IA
Qué acciones de contención puede ejecutar tu proveedor de SOC sin esperar autorización y cuáles decides tú. La matriz que conviene firmar antes.
Depende de lo que hayas firmado. En un servicio de vigilancia, el SOC detecta y avisa, y la contención la ejecuta tu equipo o tu proveedor de IT. En un servicio de detección y respuesta (MDR), el proveedor actúa directamente sobre un conjunto de acciones pactadas por escrito, a cualquier hora. Es una cuestión que conviene resolver antes de contratar, no durante el primer incidente.
En respuesta a incidentes, el tiempo que más pesa es el que pasa entre la alerta y la primera acción de contención. Ese intervalo depende poco de la tecnología y mucho de una cuestión organizativa: si la persona que ve la alerta tiene permiso y medios para actuar, o si tiene que localizar a alguien que se lo dé.
Cuando no está claro, el procedimiento real a las tres de la madrugada acaba siendo una cadena de llamadas. El analista llama al responsable de IT, que no contesta; prueba con el proveedor de sistemas, que no tiene autorización para aislar un servidor; y la decisión llega con el turno de mañana. Se evita con un documento sencillo que se acuerda al firmar: la matriz de contención.
La matriz que debería estar en tu contrato
Define qué acciones ejecuta el proveedor por su cuenta, cuáles requieren tu aprobación y quién la da. Una base razonable para una empresa mediana:
| Acción | Quién la ejecuta | Requiere autorización previa |
|---|---|---|
| Aislar de la red un puesto de trabajo comprometido | Proveedor | No |
| Deshabilitar una cuenta de usuario y revocar sus sesiones | Proveedor | No |
| Eliminar reglas de reenvío o de bandeja de entrada creadas por el atacante | Proveedor | No |
| Detener un proceso malicioso y poner ficheros en cuarentena | Proveedor | No |
| Bloquear direcciones IP, dominios o hashes maliciosos | Proveedor | No |
| Aislar un servidor no crítico | Proveedor | No, con aviso inmediato |
| Deshabilitar una cuenta de administrador o de servicio | Proveedor | Sí, salvo actividad maliciosa confirmada |
| Aislar un servidor de negocio o un controlador de dominio | Cliente | Sí |
| Cortar la conexión a internet de una sede | Cliente | Sí |
| Restaurar desde copia de seguridad | Conjunto | Sí |
La lógica es sencilla: lo que es reversible y afecta a un solo usuario o equipo se ejecuta al momento; lo que puede parar la producción se decide con el cliente. Para lo segundo tiene que haber siempre alguien localizable con autoridad para decidir.
Para el equipo técnico: lo que suele fallar cuando llega el momento
- Deshabilitar la cuenta no basta. En Microsoft 365, bloquear al usuario no invalida las sesiones ya abiertas. Hay que revocar los tokens de sesión y revisar si el atacante ha registrado un método de MFA propio o ha autorizado una aplicación con permisos sobre el buzón.
- El EDR no puede aislar lo que no gestiona. Antes de arrancar el servicio conviene comprobar que el agente está en todos los equipos, actualizado y con la protección contra manipulación activada.
- Permisos técnicos preparados. El proveedor necesita roles concretos en la consola del EDR y en Entra ID para ejecutar lo pactado. Si esos permisos se piden el día del incidente, se pierden horas.
- Exclusiones documentadas. Controladores de dominio, ERP, sistemas de producción o equipos médicos: una lista cerrada de lo que no se aísla sin llamar antes.
- Una prueba real. Aislar un equipo de prueba desde la consola y comprobar que vuelve a la normalidad es un ejercicio de diez minutos que evita sorpresas.
Cuatro puntos que conviene cerrar antes de firmar
- Lista de acciones automáticas y sus límites. Hasta dónde llega el proveedor sin preguntar y qué sistemas quedan fuera.
- Escalado fuera de horario. A quién se llama, en qué orden, por qué canal y qué hace el proveedor si nadie contesta en un tiempo determinado. Esa última parte es la que casi nunca está escrita.
- Reparto con tu proveedor de IT. Suele ser quien tiene acceso a la infraestructura y quien ejecutará las acciones que no hace el SOC. Tiene que conocer el procedimiento y estar en el árbol de llamadas.
- Un ejercicio en los primeros meses. Un simulacro, aunque sea de mesa, para comprobar que el procedimiento funciona antes de necesitarlo.
Por qué esto pesa más que cualquier funcionalidad
El daño de un incidente crece con cada minuto que el atacante sigue activo. Un servicio que detecta en dos minutos pero espera seis horas a una autorización acaba dando peor resultado que uno que detecta en diez y aísla al momento. Al comparar propuestas, la matriz de contención dice más del servicio real que la lista de integraciones o el número de reglas de detección.
Para eso está la matriz: separa las acciones reversibles y de bajo impacto, como aislar un puesto o deshabilitar una cuenta de usuario, de las que afectan a producción, que siempre pasan por ti. Además, el aislamiento desde el EDR se revierte desde la misma consola en segundos.
Depende del contrato. Comprueba si la investigación está incluida en la cuota, cuántas horas cubre y qué ocurre cuando se agotan. Si tu póliza de ciberseguro exige usar sus proveedores de respuesta, conviene saberlo antes de que haga falta.
No, si se hace bien. Aislar desde el EDR mantiene el equipo encendido y conserva la memoria, los procesos y la telemetría, que es lo que necesita la investigación posterior. Por eso es preferible a apagar el equipo o desconectarlo de la corriente.
En el servicio de detección y respuesta de Cylum, la matriz de contención se acuerda con cada cliente al arrancar. Si quieres ver cómo quedaría en tu entorno, podemos prepararla contigo.
