Deja que el EDR actúe solo cuando el coste de equivocarse sea menor que el coste de esperar. En la práctica eso reduce la lista a muy pocas señales: cifrado masivo de ficheros, borrado de copias de seguridad y manipulación del propio agente. Todo lo que dependa de una cuenta legítima o de un binario de administración pasa por una persona, hasta que tengas una reversión probada y alguien de guardia.
¿Qué rompe cada acción de respuesta si se dispara mal?
Las acciones que ofrece un EDR con respuesta activa no tienen el mismo riesgo entre sí, ni el mismo en un portátil que en un controlador de dominio. Conviene saber qué avería provoca cada una cuando la detección se equivoca.
Aislar el equipo corta su tráfico con el resto de la red: para el movimiento lateral y la exfiltración desde ese host, y es la que más tiempo compra. Cuando se dispara mal, el usuario se queda sin red en mitad de su trabajo, y si el equipo aislado es un servidor, el corte lo notan todos los que dependen de él.
Matar el proceso detiene la ejecución en marcha. El fallo típico no es que el proceso muera, es que muere mientras escribe: una base de datos a medio commit, un documento a medio guardar, un instalador a medio aplicar. Y matar el padre se lleva a los hijos: terminar un proceso de servicio puede tirar algo que no estaba en la alerta.
Poner un fichero en cuarentena lo saca de circulación con su hash y su cadena de custodia. Es la acción que más veces se lleva por delante una aplicación de negocio: el software vertical suele estar firmado por un editor que nadie reconoce e instalado fuera de Program Files. La aplicación deja de arrancar y, dos horas después, nadie relaciona la avería con la cuarentena.
Bloquear la cuenta corta la sesión y los inicios de sesión siguientes. Deja a una persona real fuera del correo y de la VPN, y el desbloqueo depende del equipo de identidad, no del analista. Es la acción con el camino de vuelta más largo.
| Acción | Qué corta | Qué rompe si se equivoca | ¿Segura de automatizar? |
|---|---|---|---|
| Aislar el equipo | Movimiento lateral y exfiltración | El usuario pierde la red; si es un servidor, la pierden sus clientes | Solo en patrones acotados y en equipos de usuario |
| Matar el proceso o el árbol | La ejecución en curso y sus hijos | Datos a medio escribir; procesos que dependían del padre | No, salvo comportamiento sin equivalente legítimo |
| Cuarentena del fichero | Nuevas ejecuciones del binario | Una aplicación de negocio se queda sin un ejecutable | No sin exclusiones de tus aplicaciones verticales |
| Bloquear la cuenta | La sesión y los inicios de sesión siguientes | Una persona real sin acceso, con desbloqueo en otro equipo | No; el camino de vuelta es muy largo |
| Revertir cambios en ficheros | Las modificaciones del proceso detenido | Escrituras legítimas perdidas si la ventana está mal calculada | No; depende de calcular bien la ventana |
¿Qué señales se pueden automatizar sin discutirlo mucho?
El criterio no es cuánto confías en la detección, sino qué pasa si se equivoca en ese equipo. Las señales que admiten automatización son las que casi no tienen actividad legítima parecida: ahí el coste esperado del falso positivo se acerca a cero. En la práctica son señales de impacto o de sabotaje de la defensa, no de ejecución sospechosa.
- Cifrado masivo de ficheros por un proceso que no es el software de copias. MITRE ATT&CK lo documenta como Data Encrypted for Impact (T1486), dentro de la táctica de Impacto. Un proceso de usuario que reescribe cientos de ficheros por segundo en un recurso compartido no tiene equivalente administrativo, y cada minuto de espera son ficheros.
- Borrado de las copias de sombra de volumen o desactivación de la recuperación del sistema. ATT&CK lo recoge como Inhibit System Recovery (T1490), y su página cita
vssadmin.exe delete shadows /all /quietentre los ejemplos de familias como WannaCry, Ryuk, Conti o LockBit. Ningún administrador ejecuta eso en el portátil de un comercial. - Intento de parar, desinstalar o degradar el propio agente. ATT&CK lo describe en Disable or Modify Tools (T1685), que incluye matar procesos del EDR, tocar su configuración y cortar la telemetría hacia el SIEM. Sin ventana de mantenimiento declarada, la respuesta automática es defendible.
¿Y qué señales no deberías automatizar?
El uso de credenciales válidas es el caso más claro. La página de Valid Accounts (T1078) señala que un atacante puede prescindir de malware porque el acceso legítimo que dan esas credenciales hace más difícil detectar su presencia. Un inicio de sesión desde una IP nueva a las tres de la mañana es un comercial en otro huso horario tan a menudo como un atacante.
Lo mismo pasa con PowerShell y los binarios firmados del sistema. ATT&CK documenta su abuso en T1059.001 y en System Binary Proxy Execution (T1218), cuya descripción recuerda que los binarios implicados suelen estar firmados por Microsoft. Son las mismas herramientas con las que tu MDM despliega paquetes y tus tareas programadas hacen inventario.
Dos cualificadores importan tanto como la señal. La clase de activo: el mismo cifrado masivo que automatizarías en un portátil no se automatiza en un hipervisor, porque el coste del falso positivo cambia de orden de magnitud. Y la antigüedad de la regla: una detección escrita la semana pasada no tiene historial de falsos positivos. Automatiza pares de señal y clase de activo, nunca señales sueltas.
¿Cómo debería empezar un equipo pequeño?
Con todo en aprobación. Es la posición documentada de Protoxol: los playbooks proponen la acción, la encolan y la explican, y una persona aprueba antes de ejecutar, según cómo está construida la plataforma y el módulo de automatización de respuesta. Para patrones acotados como el cifrado masivo, el aislamiento se puede configurar para ejecutarse solo y avisar después.
- Semanas 1 a 8: aprobación para todo. El objetivo no es contener mejor, es acumular historial. Por cada alerta anota qué acción se aprobó, cuánto se tardó y si fue correcta. Sin esos datos, decidir sobre automatizar es una opinión.
- Una sola automatización, lo más estrecha posible. Una señal, una clase de activo, una acción: aislamiento ante cifrado masivo en portátiles de usuario, con los servidores excluidos por nombre.
- Revisión a los 30 días. Si no hubo falsos positivos y el tiempo de contención bajó, añade el siguiente par. Si hubo uno, entiende por qué antes de añadir nada.
Queda un factor que descoloca el plan: la franja horaria. A las tres de la mañana nadie va a aprobar nada en seis horas, y una detección de cifrado masivo que espera seis horas no sirve. Muchos equipos sin guardia acaban con dos reglas para la misma señal: con aprobación en horario laboral, automática con notificación fuera de él. En EDR para pymes está el contexto de por qué un equipo sin SOC parte de aquí.
¿Qué tienes que tener montado antes de poner algo en automático?
- Una reversión probada. Has aislado un equipo real, lo has sacado del aislamiento y sabes cuánto tardó. Si solo has hecho el camino de ida, tienes una casilla marcada, no una reversión.
- El alcance por escrito. Qué señal, qué acción, qué clase de activo, y la lista explícita de exclusiones: controladores de dominio, servidores de ficheros e hipervisores.
- Un responsable de guardia con nombre y teléfono. Alguien recibe la notificación de la acción automática y sabe qué hacer. Un buzón compartido no es un responsable.
- Registro de auditoría exportable. Qué se disparó, qué regla, en qué equipo, a qué hora y quién lo revirtió. Te permite revisar la decisión y contestar al usuario que pregunta por qué perdió la red el jueves.
- Un camino de comunicación al afectado. El texto que ve la persona cuando su portátil pierde la red, y un canal de respuesta que no sea el correo corporativo: está en el equipo que acabas de aislar.
- Ventanas de mantenimiento declaradas. Despliegues, parches y migraciones generan comportamiento parecido a un ataque. Si el EDR no los conoce, los vas a contener tú mismo.
- Historial de la señal. Unas semanas de esa detección en modo aprobación, con los falsos positivos contados, no estimados.
- Un criterio de apagado decidido de antemano. Cuántos falsos positivos devuelven esa automatización a aprobación manual. Decidirlo en caliente no sale bien.
¿Cómo se revisa la decisión después?
Cada ejecución automática se clasifica en las 24 horas siguientes, con tres etiquetas y no dos: correcta, falso positivo, y correcta pero excesiva. La tercera es la que más información da: la detección acertó y la acción fue desproporcionada para ese activo. Ahí el arreglo no es desactivar la regla, es cambiar la acción o excluir esa clase de equipo.
Una vez al mes bastan dos números: cuántos falsos positivos automáticos hubo, que es el coste, y cuánto bajó el tiempo hasta la contención, que es el beneficio. Si el primero sube y el segundo no se mueve, ese par vuelve a aprobación. Cada automatización activa debería tener un responsable y una fecha de revisión, para que no sobreviva años a la amenaza que la justificó.
La pregunta no era si automatizar la respuesta, sino qué triadas de señal, activo y acción has ganado el derecho a automatizar, y cada cuánto vuelves a mirar la lista. El alcance de las acciones está en el módulo EDR; qué entra en cada plan, en planes y precios.