Poner un EDR en las laptops de la empresa es casi siempre buena idea sin muchas vueltas. Ponerlo en un servidor de producción crítico es también buena idea —pero con una advertencia que rara vez se dice en voz alta—: en un servidor, la herramienta que te protege puede, mal configurada, causar una caída peor que el ataque que intentaba evitar. No porque el EDR sea malo, sino porque el contexto cambia todo.
Por qué un servidor no es una laptop
La diferencia es de consecuencias. Si un EDR bloquea por error un proceso en la laptop de alguien, esa persona pierde un rato y llama a soporte. Si un EDR mata por error un proceso en el servidor de la base de datos, o pone en cuarentena un archivo que el motor necesita, puede tirar una aplicación de la que dependen cientos de personas. El falso positivo pasó de molestia a incidente. Y los servidores corren justamente el tipo de procesos —bases de datos, tareas automatizadas, scripts de administración— que a un motor de detección de comportamiento le pueden parecer sospechosos aunque sean perfectamente legítimos.
Cómo se ve el falso positivo caro
Un ejemplo que se ve en campo: un EDR recién desplegado en un servidor de base de datos, con la misma política agresiva de las laptops, interpreta que el patrón de escritura intensiva del motor sobre sus archivos es "comportamiento tipo ransomware" y pone en cuarentena un archivo de datos que la base necesita. La base se cae a medio día, la aplicación que dependía de ella también, y cientos de usuarios quedan detenidos —no por un ataque, sino por la herramienta que debía protegerlos—. La solución era simple y conocida: excluir del análisis los archivos legítimos de la base de datos. Pero se descubrió en caliente, con producción caída, en lugar de en frío durante un despliegue por fases. Ese es exactamente el escenario que un buen afinado evita.
El trade-off honesto: seguridad contra disponibilidad
Aquí hay una tensión real que no se resuelve con un eslogan. Un EDR muy agresivo (que bloquea y mata ante la duda) maximiza la protección pero aumenta el riesgo de tumbar algo legítimo. Uno muy conservador (que solo alerta) casi no interfiere, pero deja pasar. En un endpoint común, inclinarse a bloquear tiene sentido. En un servidor crítico, donde una caída se traduce directo en costo por hora de downtime, el balance se calibra con mucho más cuidado.
Cómo se afina bien
- Exclusiones informadas: excluir del análisis los procesos y rutas legítimas propias del servidor (los archivos de la base de datos, por ejemplo), documentando por qué.
- Empezar en modo detección: desplegar primero observando sin bloquear, aprender qué es normal en ese servidor, y solo entonces activar el bloqueo —un patrón hermano de construir umbrales sobre una línea base—.
- Despliegue por fases: no encender el modo agresivo en toda la flota de servidores a la vez; probar, validar, propagar.
- Conocer la carga: afinar exige entender qué hace ese servidor. Un EDR en servidores no es "instalar y olvidar".
La pregunta que conviene hacerse
La pregunta no es "¿protejo mis servidores con EDR?" —sí, deberías—, sino ¿está afinado para el servidor que protege, o lo desplegué con la misma política agresiva de las laptops y estoy a un falso positivo de tumbar producción? Ese afinado —exclusiones, modos, fases— es la diferencia entre un EDR que protege y uno que se vuelve el riesgo. Hacerlo con criterio es parte de cómo implementamos la defensa del endpoint en infraestructura crítica.