Antivirus que deja inutilizables los PCs: la ironía que se repite

La ironía repetible: por qué la “seguridad” se convierte en tiempo de inactividad

El antivirus es una especie invasora por diseño. Engancha aperturas de archivos, vigila la creación de procesos, inspecciona memoria, desvía llamadas de red y a veces se incrusta en flujos de autenticación. Si no lo hiciera, estaría ciego. Pero esa misma visibilidad implica que se ubica exactamente donde el rendimiento y la estabilidad son frágiles: controladores de kernel, filtros del sistema de archivos, pilas de red y el cargador de procesos.

Cuando se rompe, lo hace de forma ruidosa. No obtienes una degradación suave; obtienes bucles de arranque, pantallas azules, “acceso denegado” en binarios del sistema, compilaciones que tardan 10× más y bases de datos que de repente se comportan como si funcionaran desde una unidad USB. Eso ocurre porque las herramientas de seguridad endpoint están diseñadas para ser autoritativas. Pueden bloquear lo que intentas hacer, y pueden hacerlo antes de que tu software tenga voto.

El patrón recurrente no es que “la seguridad sea mala”. El patrón es que tratamos la herramienta de seguridad como una actualización del navegador: desplegarla por todas partes, de inmediato, con mínima disciplina de despliegue—porque la propia herramienta se supone que reduce el riesgo. Eso es al revés. Debes tratar la herramienta de seguridad como una actualización de kernel, porque efectivamente lo es.

Idea parafraseada de John Allspaw: “La fiabilidad viene de la capacidad de aprender y adaptarse en condiciones reales”. Eso incluye agentes de seguridad: envíalos como si fueran a fallar, porque eventualmente fallan.

Un chiste corto, porque hace falta: El software antivirus es el único producto que puede decir “He encontrado un virus” y querer decir “Yo soy el virus hoy”.

Datos interesantes y contexto histórico (breve y concreto)

• Años 1980: El “antivirus” temprano era principalmente coincidencia de firmas de boot-sector y file infectors; no estaba profundamente integrado en kernels porque los sistemas operativos tampoco lo estaban.
• Años 1990: Los virus macro (notablemente vía documentos de oficina) desplazaron la detección hacia la inspección de contenido y el escaneo heurístico, aumentando el uso de CPU en flujos de trabajo con muchos documentos.
• Finales de 1990–2000: Los gusanos propagados por correo empujaron a los proveedores a añadir escaneo en tiempo real de almacenes de correo y adjuntos, causando con frecuencia amplificación de I/O en PST/OST y formatos similares.
• Años 2000: Los minifiltros del sistema de archivos de Windows se convirtieron en un mecanismo estándar para el escaneo on-access—potente, pero adyacente al kernel y fácil de desestabilizar cuando están defectuosos o mal configurados.
• Años 2010: El EDR se expandió más allá del malware hacia la detección de comportamiento, prevención del robo de credenciales y detección de movimiento lateral—más sensores, más hooks, más cosas que pueden romperse.
• Puntos finales modernos: Muchos agentes usan detecciones entregadas desde la nube y actualizaciones frecuentes de reglas. Eso hace que las “actualizaciones de definiciones” se parezcan más a “actualizaciones de políticas”, con impacto comportamental real.
• Realidad de rendimiento: El escaneo on-access puede convertir una operación lógica de archivo en múltiples lecturas y escrituras físicas, especialmente con escaneo de archivos comprimidos y descompresión de contenido.
• Realidad operativa: Una actualización de agente de seguridad suele ser un instalador privilegiado que actualiza controladores/servicios, a veces requiere reinicio, a veces lo hace de todos modos.

Modos de fallo: cómo el antivirus rompe PCs en la práctica

1) Bucles de arranque y pantallas azules: la cercanía al kernel es un cuchillo afilado

La seguridad endpoint adora el kernel. No siempre de forma directa, pero lo suficiente: controladores filtro del sistema de archivos, callouts de red, proveedores de credenciales, hooks de integridad de código y componentes de escaneo de memoria. Cuando uno de estos controladores se comporta mal—condiciones de carrera, suposiciones erróneas sobre versiones del SO, metadatos de archivo inesperados—no obtienes un fallo limpio en el espacio de usuario. Obtienes una máquina que no puede arrancar o que no puede mantenerse encendida.

Desencadenantes típicos: una actualización que introduce un nuevo driver, una actualización acumulativa de Windows que cambia el comportamiento del kernel, o activar una bandera de función que amplía el alcance del monitoreo a una ruta de código que nunca fue sometida a pruebas de estrés en tu mezcla hardware/controlador.

2) “Todo va lento”: amplificación de I/O y contención

El escaneo on-access suele significar: abrir archivo → el antivirus intercepta → leer contenido → quizá descomprimir → escanear → permitir la lectura original. Multiplica eso por sistemas de compilación (miles de archivos pequeños), gestores de paquetes (muchos archivos comprimidos) y flujos de trabajo de desarrollador (node_modules, target/, bin/obj), y has convertido una laptop en un calefactor.

El almacenamiento lo empeora. Las cargas de trabajo de antivirus son “lecturas aleatorias pequeñas” más churn de metadatos. En discos giratorios es un suplicio; en SSDs es un suplicio más rápido. En unidades de red, es sufrimiento con latencia.

3) Las aplicaciones fallan: falsos positivos y remediación agresiva

Las herramientas modernas no solo detectan; remedian. Ponen en cuarentena, eliminan, bloquean la ejecución, bloquean cargas de DLL, niegan aperturas de handle. Si la herramienta marca un binario legítimo (artefacto de build nuevo, herramienta interna sin firmar, un instalador empaquetado), la “solución” se convierte en una interrupción de producción porque un agente decidió que tu software parecía sospechoso.

4) Rariedades de red: inspección TLS y manipulación de paquetes

Algunas pilas endpoint se insertan en la red para protección web, defensa contra phishing o inspección TLS. Si se hace mal, obtienes cadenas de certificados rotas, reinicios intermitentes de conexión y caídas de rendimiento en aplicaciones de alto rendimiento (runners de CI, caches de artefactos, pulls de contenedores).

5) Tormentas de actualización: un cambio de política que se propaga instantáneamente

A los equipos de seguridad les encantan las consolas centrales. A las consolas centrales les encantan los interruptores globales instantáneos. Activa una palanca que aumenta la agresividad de escaneo, y de repente cada endpoint empieza a hashear archivos, escanear archivos comprimidos y rescannar caches. Tu “problema” no es una sola máquina; es una bomba de carga sincronizada.

6) VDI y máquinas compartidas: un host, muchas víctimas

En VDI, un único host ejecuta muchos escritorios. Si el agente en cada VM decide “iniciar un escaneo completo ahora”, el almacenamiento compartido y la CPU se ven asaltados. Si la herramienta está instalada en la imagen golden con exclusiones incorrectas, cada clon hereda el problema al instante.

7) Entornos de desarrollador y SRE: escáneres vs. grafos de build

Las herramientas de build crean miles de archivos transitorios. Los gestores de paquetes escriben caches. Los contenedores producen capas. El antivirus lo ve como una orgía de actividad sospechosa. Tú lo ves como “¿por qué mi suite de pruebas pasó de 8 minutos a 45?”

Segundo chiste corto, porque lo merecemos: La manera más rápida de medir tu SSD es instalar un antivirus sobreprotector y verlo descubrir límites nuevos y emocionantes.

Guía rápida de diagnóstico (qué comprobar primero/segundo/tercero)

Este es el bucle de “dejar de adivinar”. Estás intentando responder a una pregunta: ¿Es el agente de seguridad el cuello de botella y, si es así, qué subsistema está estrangulando?

Primero: confirma alcance y momento (radio de explosión)

• ¿Es un host, un departamento o todo el mundo?
• ¿Comenzó justo después de una actualización del agente, una actualización de política o una actualización del SO?
• ¿Está correlacionado con reinicios, inicios de sesión o cambios de red?

Decisión: Si el radio de explosión es amplio y la aparición está sincronizada, trátalo como un incidente de despliegue/política, no como “los PCs son viejos”. Congela los cambios y comienza la contención.

Segundo: identifica el recurso constreñido (CPU, disco, memoria, red)

• ¿Alta CPU en procesos de seguridad? Probablemente escaneo, análisis de comportamiento o telemetría descontrolada.
• ¿Alta actividad de disco / profundidad de cola? Probablemente escaneo on-access o churn de cuarentena.
• ¿Anomalías de red? Posiblemente módulo de protección web, proxy, inspección TLS o bucles de fetch de reglas en la nube.
• ¿Fallas en arranque/BSOD? Problema a nivel de driver, frecuentemente relacionado con actualizaciones.

Decisión: Escoge la herramienta de medición más rápida disponible en el SO impactado y demuestra el cuello de botella antes de cambiar configuraciones.

Tercero: demuestra causalidad (deshabilitar vs. excluir vs. revertir)

• ¿Puedes reproducir la ralentización tocando una ruta caliente conocida (p. ej., construir un repo, descomprimir un archivo)?
• ¿Desaparece el problema en Modo Seguro (donde muchos drivers/servicios de terceros están deshabilitados)?
• ¿Reduce la carga añadir una exclusión focalizada sin deshabilitar completamente la protección?

Decisión: Si el Modo Seguro o una desactivación controlada lo arregla, escala al equipo de seguridad/proveedor con evidencia y revierte o estratifica una configuración actualizada.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas son tareas prácticas que puedes ejecutar en una estación/servidor Linux o en un endpoint Windows usando un entorno shell (WSL, Git Bash o herramientas remotas). Los comandos son realistas; el punto es el flujo de trabajo: ejecutar → interpretar → decidir.

Task 1: Find top CPU consumers (is the scanner burning cycles?)

cr0x@server:~$ ps -eo pid,ppid,cmd,%cpu,%mem --sort=-%cpu | head -n 8
  PID  PPID CMD                         %CPU %MEM
 2143     1 /opt/edr/agentd              186.3  2.1
 2210  2143 /opt/edr/scanner --realtime   94.2  1.4
 1055     1 /usr/lib/systemd/systemd      1.2  0.1
 1899     1 /usr/sbin/sshd               0.3  0.2

Qué significa: El agente y el escáner están dominando la CPU. Si esto coincide con quejas de usuarios, no es “solo percepción”.

Decisión: Pasa a las comprobaciones de disco y actividad de archivos; si la CPU está al tope con poco I/O, sospecha de bucles del motor de comportamiento o tormentas de telemetría.

Task 2: Spot disk pressure (is it I/O bound?)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(16 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.50    0.00    9.20   38.10    0.00   40.20

Device            r/s     w/s   rkB/s   wkB/s  await  aqu-sz  %util
nvme0n1         320.0   210.0  8200.0  6400.0  18.40    6.20  98.70

Qué significa: iowait es alto; la utilización del dispositivo está ~99%. El sistema espera por el almacenamiento.

Decisión: Identifica qué proceso está provocando I/O (probablemente escaneo). Considera exclusiones para directorios calientes y limitar escaneos completos.

Task 3: Identify the I/O offender (which PID is hitting disk?)

cr0x@server:~$ sudo iotop -o -b -n 3
Total DISK READ: 45.12 M/s | Total DISK WRITE: 12.34 M/s
  PID  PRIO  USER     DISK READ  DISK WRITE  SWAPIN      IO>    COMMAND
 2210 be/4   root     42.10 M/s   0.00 B/s    0.00 %  92.00 %  /opt/edr/scanner --realtime
 2143 be/4   root      2.20 M/s   9.80 M/s    0.00 %  18.00 %  /opt/edr/agentd

Qué significa: El escáner está saturando lecturas. Esto ocurre a menudo cuando rescanea caches o artefactos de build.

Decisión: Inspecciona las rutas de archivos que se están accediendo, luego implementa exclusiones focalizadas o ajusta el modo de escaneo.

Task 4: See what files the scanner is touching (hot paths)

cr0x@server:~$ sudo lsof -p 2210 | head -n 12
COMMAND   PID USER   FD   TYPE DEVICE SIZE/OFF     NODE NAME
scanner  2210 root  cwd    DIR  259,1     4096  1310730 /home/dev/build
scanner  2210 root   12r   REG  259,1  5242880  1311102 /home/dev/build/node_modules/.cache/tmp.bin
scanner  2210 root   13r   REG  259,1   912384  1311120 /home/dev/build/target/classes/app.jar

Qué significa: Está acampando en salidas de build y caches de dependencias.

Decisión: Excluye directorios de build efímeros y caches de paquetes; sigue escaneando código fuente y artefactos descargados si la política lo requiere.

Task 5: Detect file-change storms (are we rescanning because the filesystem churns?)

cr0x@server:~$ inotifywatch -t 10 -r /home/dev/build
Establishing watches...
Finished establishing watches, now collecting statistics.
total  184532
create  61210
delete  60210
modify  48200
close_write  14912

Qué significa: Churn masivo; los escáneres en tiempo real pueden convertirse en DoS auto-infligido aquí.

Decisión: Para árboles de build, prefiere modos “scan on close” o “scan on execute”, o excluye el directorio y escanea artefactos en CI en su lugar.

Task 6: Check memory pressure (are we paging because the agent is bloated?)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            31Gi        28Gi       1.1Gi       312Mi       2.0Gi       1.6Gi
Swap:          8.0Gi       5.2Gi       2.8Gi

Qué significa: El sistema está profundamente en swap. Incluso un pico “pequeño” de CPU se vuelve catastrófico cuando todo empieza a paginar.

Decisión: Reduce funciones del agente, limita telemetría o redimensiona endpoints—luego verifica qué proceso tiene RSS con la siguiente tarea.

Task 7: Find which processes own memory (RSS reality check)

cr0x@server:~$ ps -eo pid,cmd,rss --sort=-rss | head -n 6
  PID CMD                           RSS
 2143 /opt/edr/agentd            1824300
 2210 /opt/edr/scanner --realtime 943200
 3321 /usr/lib/firefox/firefox    612400

Qué significa: El agente es un gran consumidor de memoria. Algunas herramientas cachean firmas/modelos agresivamente; a veces es una fuga.

Decisión: Si el crecimiento de memoria es ilimitado en el tiempo, planifica un rollback o una escalada al proveedor con evidencia (tendencia RSS).

Task 8: Verify service health and recent restarts (crash loops are a clue)

cr0x@server:~$ systemctl status edr-agent --no-pager
● edr-agent.service - Endpoint Detection and Response Agent
     Loaded: loaded (/etc/systemd/system/edr-agent.service; enabled)
     Active: active (running) since Wed 2026-01-22 09:11:02 UTC; 3min ago
   Main PID: 2143 (agentd)
     Tasks: 48 (limit: 38241)
     Memory: 1.8G
     CGroup: /system.slice/edr-agent.service
             ├─2143 /opt/edr/agentd
             └─2210 /opt/edr/scanner --realtime

Qué significa: El servicio está activo ahora, pero el estado por sí solo no muestra si está flapping.

Decisión: Inspecciona el journal por reinicios/fallos recientes y correlaciónalos con los reportes de usuarios.

Task 9: Read logs around the incident window (pinpoint policy/engine changes)

cr0x@server:~$ sudo journalctl -u edr-agent --since "2026-01-22 08:30" --no-pager | tail -n 12
Jan 22 08:58:10 server agentd[2143]: policy update received: profile=Workstations-Strict
Jan 22 08:58:11 server agentd[2143]: enabling feature: archive_deep_scan=true
Jan 22 08:58:12 server scanner[2210]: started full content scan: reason=policy_change
Jan 22 08:58:13 server scanner[2210]: warning: scan queue length=8421
Jan 22 08:58:20 server agentd[2143]: telemetry backlog increasing: 1200 events/sec

Qué significa: No es misterioso. Una actualización de política habilitó escaneo profundo de archivos comprimidos y disparó escaneos completos.

Decisión: Revierte la política o acótala; añade salvaguardas para que los cambios de política no desencadenen escaneos completos automáticos en toda la flota.

Task 10: Check network churn (are we hammering cloud endpoints?)

cr0x@server:~$ ss -tpn | head -n 12
State  Recv-Q Send-Q Local Address:Port  Peer Address:Port Process
ESTAB  0      0      10.0.3.14:51944    52.85.12.33:443  users:(("agentd",pid=2143,fd=28))
ESTAB  0      0      10.0.3.14:51946    52.85.12.33:443  users:(("agentd",pid=2143,fd=29))
ESTAB  0      0      10.0.3.14:51948    52.85.12.33:443  users:(("agentd",pid=2143,fd=30))

Qué significa: Varias sesiones TLS persistentes. Normal—a menos que los conteos exploten o el tráfico sature enlaces.

Decisión: Si los endpoints son lentos solo cuando están “en línea”, prueba aislando temporalmente una máquina (en una VLAN de laboratorio) para ver si las búsquedas en la nube están condicionando la ejecución.

Task 11: Confirm CPU throttling / thermal issues (sometimes the agent is just the trigger)

cr0x@server:~$ cat /proc/cpuinfo | grep -E "model name|cpu MHz" | head -n 6
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 799.932
model name	: Intel(R) Core(TM) i7-10610U CPU @ 1.80GHz
cpu MHz		: 800.021

Qué significa: La CPU está aparcada alrededor de 800 MHz—probablemente throttling térmico/potencia. La carga del agente puede estar empujando un sistema de refrigeración marginal al límite.

Decisión: Arregla el perfil subyacente de energía/temperatura (BIOS, política de energía del SO) y aun así ajusta el escaneo. No culpes al “antivirus” por un portátil que no puede enfriarse.

Task 12: Measure latency to a file-heavy operation (before/after exclusions)

cr0x@server:~$ time find /home/dev/build -type f -maxdepth 4 -print0 | xargs -0 sha256sum >/dev/null
real	0m42.118s
user	0m8.901s
sys	0m31.772s

Qué significa: Alto tiempo en sys sugiere overhead de kernel/I/O de archivos—clásico con escaneo on-access.

Decisión: Aplica una exclusión focalizada para el directorio de build y vuelve a ejecutar. Si el tiempo cae drásticamente, has demostrado causalidad sin desactivar la protección globalmente.

Task 13: Inspect loaded filesystem filter drivers (Windows-adjacent, but conceptually crucial)

cr0x@server:~$ fltmc
Filter Name                     Num Instances    Altitude    Frame
------------------------------  -------------  ------------  -----
WdFilter                                 10       328010         0
edrFilter                                 8       321200         0
luafv                                    1       135000         0

Qué significa: Múltiples filtros están apilados. La altitud indica el orden; las interacciones importan. Dos productos escaneando las mismas aperturas pueden duplicar trabajo o provocar deadlocks en casos extremos.

Decisión: Evita ejecutar dos escáneres en tiempo real. Si es obligatorio tener dos herramientas, pon una en modo pasivo/compatibilidad y valida el orden de filtros con la guía del proveedor.

Task 14: Verify Windows Defender status quickly (common in mixed EDR setups)

cr0x@server:~$ powershell -NoProfile -Command "Get-MpComputerStatus | Select AMServiceEnabled,AntispywareEnabled,RealTimeProtectionEnabled,IoavProtectionEnabled"
AMServiceEnabled AntispywareEnabled RealTimeProtectionEnabled IoavProtectionEnabled
---------------- ----------------- ------------------------- ---------------------
            True              True                      True                  True

Qué significa: Defender real-time está activado. Si también tienes un EDR de terceros haciendo escaneo on-access, podrías estar doblemente escaneando.

Decisión: Decide qué producto es el autoritativo para escaneo en tiempo real; configura el otro en modo pasivo cuando sea posible y confirma vía política.

Task 15: Check for recent Windows bugchecks (BSOD evidence)

cr0x@server:~$ powershell -NoProfile -Command "Get-WinEvent -FilterHashtable @{LogName='System'; Id=1001} -MaxEvents 3 | Format-Table TimeCreated,Message -Auto"
TimeCreated           Message
-----------           -------
1/22/2026 8:14:02 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...
1/22/2026 8:01:44 AM  The computer has rebooted from a bugcheck. The bugcheck was: 0x0000007e ...

Qué significa: Bugchecks repetidos. Si la marca temporal se alinea con la actualización del agente/cambio de política, tienes una pista sólida.

Decisión: Preserva volcados de memoria (crash dumps), detén el rollout y coordina un rollback/hotfix. No “reimages y seguimos” hasta que hayas contenido el riesgo en la flota.

Tres mini-historias corporativas desde las trincheras

Mini-historia 1: El incidente causado por una suposición errónea

La empresa tenía dos herramientas endpoint: un EDR de terceros y Microsoft Defender. El equipo de seguridad creía que Defender pasaría automáticamente a modo pasivo cuando se instalara un agente de terceros. Lo habían visto ocurrir en algunos entornos y eso se convirtió en “cómo funciona Windows” en sus cabezas.

Luego llegó una actualización de Windows y Defender volvió a activarse en tiempo real en un subconjunto de máquinas. Nadie lo notó de inmediato, porque nada “se rompió” de forma obvia. Lo que ocurrió en cambio fue una muerte lenta: los inicios de sesión tardaban más, Outlook se congelaba al azar y las compilaciones en portátiles de desarrollador empezaron a agotar tiempo al descomprimir dependencias.

SRE fue llamado porque “el repositorio de artefactos está lento”. No lo estaba. Los endpoints estaban escaneando cada archivo descargado dos veces, y uno de los escáneres tenía la inspección profunda de archivos comprimidos activada. El equipo de almacenamiento vio un pico en operaciones de metadatos SMB y culpó al filer; el equipo de red vio más TLS hacia endpoints de seguridad en la nube y culpó a la “congestión de Internet”. Bola clásica de culpables.

La solución fue aburrida: poner Defender en modo pasivo explícitamente vía política en máquinas donde el EDR de terceros proveía escaneo en tiempo real, y verificarlo continuamente. La lección fue más aguda: nunca confíes en la “coexistencia automática” entre productos de seguridad. Si no puedes describir la máquina de estados, no la controlas.

Mini-historia 2: La optimización que salió mal

Otra organización intentó reducir el tiempo de respuesta a incidentes activando agresivamente “bloquear a la primera vista” y búsquedas en la nube para cualquier cosa ejecutada por primera vez. El proveedor de seguridad lo vendió como una manera más inteligente y rápida de prevenir malware desconocido. Funcionó—hasta que se topó con una flota de estaciones de desarrollo.

Los desarrolladores ejecutaban herramientas internas sin firmar, compilaban binarios constantemente y ejecutaban desde directorios de salida de build. La nueva política hizo que cada artefacto de build nuevo fuera tratado como sospechoso y enviado a comprobaciones de reputación. Algunas comprobaciones tomaban segundos. Otras minutos cuando el endpoint en la nube estaba lento o cuando el agente decidía subir más contexto.

De repente, “make test” dejó de ser un comando y se convirtió en un retiro de meditación. La gente empezó a copiar salidas de build en directorios extraños para “evitar el escaneo”, lo que hizo lo contrario: creó más binarios desconocidos en más ubicaciones, incrementando la superficie de escaneo. La optimización creó una industria interna de shadow IT dentro de la empresa.

Tras dos semanas, el equipo de seguridad revirtió la política para máquinas de desarrollador y CI y la reemplazó por un patrón más seguro: escaneo más estricto para descargas y adjuntos, controles de ejecución para rutas de riesgo conocidas y una canalización de firmas para herramientas internas. El problema no fue la característica. Fue aplicarla sin entender la carga de trabajo.

Mini-historia 3: La práctica aburrida pero correcta que salvó el día

Una empresa trató su EDR como infraestructura crítica. Tenían anillos: test de TI, un pequeño grupo piloto en cada unidad de negocio y luego despliegue escalonado al resto. También tenían un proceso de “interruptor de apagado”: una forma preaprobada de pausar despliegues y revertir políticas sin una semana de reuniones.

Cuando un proveedor envió una actualización que aumentaba la agresividad de escaneo en archivos comprimidos, el anillo de pruebas de TI se encendió inmediatamente. El equipo de build notó una desaceleración 4× en un benchmark de compilación estándar que ejecutaban después de cada cambio en endpoints. Enviaron un ticket con logs, marcas de tiempo y una carga de trabajo reproducible en pocas horas.

Como el despliegue era escalonado, solo el anillo de prueba se vio afectado. No hubo llamadas de emergencia con ejecutivos preguntando “por qué la compañía está en llamas”. El equipo de seguridad trabajó con el proveedor, recibió una configuración actualizada y ajustó exclusiones para caches calientes conocidas.

La práctica fue aburrida: un anillo canario, un benchmark y un plan de rollback. Evitó una caída masiva. Ese es el punto de las operaciones aburridas—no consigues titulares, ganas sueño.

Errores comunes: síntoma → causa raíz → solución

Síntoma: El PC está “lento”, el disco está al 100%, los ventiladores rugen

Causa raíz: Escaneo en tiempo real de directorios de alto churn (salidas de build, caches, perfiles VDI), frecuentemente combinado con escaneo profundo de archivos comprimidos.

Solución: Añadir exclusiones focalizadas para directorios efímeros; cambiar el modo de escaneo a scan-on-execute/close; programar escaneos completos fuera de horario con tiempos de inicio aleatorizados. Validar con mediciones de I/O antes/después.

Síntoma: Fallos aleatorios de aplicaciones (“acceso denegado”, fallos de carga de DLL)

Causa raíz: Bloqueos de comportamiento o falsos positivos que ponen en cuarentena binarios recién construidos/actualizados; a veces Controlled Folder Access o reglas de protección contra ransomware mal aplicadas.

Solución: Crear reglas de permitidos para binarios internos firmados; implementar firma de código; afinar reglas para dispositivos de desarrollador; recopilar logs del agente y hashes como evidencia para escalada al proveedor.

Síntoma: Bucle de arranque o BSOD justo después de una actualización del agente

Causa raíz: Controlador kernel/minifilter defectuoso, incompatibilidad con un parche reciente del SO o instalación de driver fallida que deja un estado inconsistente.

Solución: Detener el despliegue inmediatamente. Usar Modo Seguro/recuperación para deshabilitar el driver/servicio, revertir a la versión de agente conocida buena, preservar volcados de crash y coordinar con el proveedor para una build corregida.

Síntoma: La red se siente inestable; los certificados parecen “malos”

Causa raíz: Módulo de protección web actuando como proxy local o inspección TLS insertando una CA raíz; conflictos con VPN, proxy corporativo o aplicaciones con certificate pinning estricto.

Solución: Deshabilitar la inspección TLS para apps/dominios afectados; asegurar que el despliegue de la CA raíz sea correcto; validar la compatibilidad proxy/VPN en un anillo piloto.

Síntoma: Runners de CI o agentes de build se ralentizan repentinamente

Causa raíz: EDR instalado con valores por defecto de workstation; escaneando directorios de trabajo y caches de dependencias; escaneando capas de contenedor agresivamente.

Solución: Crear una política específica para CI: escaneo en tiempo real mínimo, escaneo estricto en ingress (descargas), escaneo de artefactos en el momento de publicar y exclusiones agresivas para espacios de trabajo efímeros.

Síntoma: Picos de CPU al mismo tiempo en muchas máquinas

Causa raíz: Push de política que dispara escaneo completo o rehash; actualización de definiciones/reglas que causa rescans; flush de backlog de telemetría.

Solución: Usar anillos y límites de tasa; deshabilitar “escanear inmediatamente tras cambio de política”; aleatorizar inicio de escaneos; limitar uso de CPU; monitorizar cumplimiento de actualizaciones en la flota vs. rendimiento.

Síntoma: Un usuario está afectado; otros no

Causa raíz: Corrupción local, actualización parcial, software de terceros en conflicto o una carga de trabajo extraña (archivo de correo enorme, repo masivo, contenedor cifrado).

Solución: Comparar versiones/políticas del agente; reaplicar política; reinstalar el agente limpiamente; recopilar métricas antes/después; no “arreglar la flota” por un caso aislado sin evidencia.

Listas de verificación / plan paso a paso

Lista de contención (cuando los endpoints están fallando activamente)

1. Congelar el rollout: detener nuevos despliegues de agentes y pausar la propagación de políticas en la consola central.
2. Identificar anillos: determinar qué cohorte recibió el cambio (piloto vs. general). Si no tienes anillos, ya los tienes—empieza agrupando “ya actualizado” vs. “aún no”.
3. Capturar evidencia: recopilar logs, versiones y marcas de tiempo de 3–5 máquinas afectadas y 1 control no afectado.
4. Decidir alcance del rollback: revertir política primero si es posible; revertir versión del agente si se sospecha de problemas a nivel de driver.
5. Comunicar claramente: nota para usuarios: qué está roto, solución temporal, ETA y qué no hacer (p. ej., no reinstalar limpiadores aleatorios).
6. Proteger seguridad: si debes reducir protección temporalmente, compensa (restringir acceso de red, bloquear descargas de alto riesgo, endurecer controles de correo) hasta estabilizar.

Lista de estabilidad por diseño (cómo dejar de repetir esto)

1. Rollouts en anillos: test → piloto → escalonado. Haz que el agente siga la misma gestión de cambios que las actualizaciones del SO.
2. SLOs de rendimiento para endpoints: define presupuestos medibles (overhead de CPU, latencia de disco, deltas de tiempo de build) y rechaza cambios que los violen.
3. Políticas conscientes de la carga: separa escritorios de desarrollador, VDI, servidores y runners de CI. Una política para todos es cómo creas dolor universal.
4. Exclusiones con disciplina: excluye directorios efímeros y caches; no excluyas discos enteros; revisa exclusiones trimestralmente.
5. Control de doble escaneo: asegura que solo un producto haga escaneo en tiempo real; los demás en modo pasivo/telemetría.
6. Guardrails de actualización: evita “escanear todo inmediatamente tras cambio de política” en toda la flota; aleatoriza horarios de escaneo.
7. Retención de volcados y logs: conserva lo necesario para probar un bug de driver; de lo contrario cada incidente se vuelve superstición.
8. Paquete para escalada al proveedor: bundle estándar: logs del agente, build del SO, volcados de crash, pasos de reproducción y una línea temporal.

Ajustes conscientes del almacenamiento (porque los discos sufren en silencio)

1. No escanees lo que puedes regenerar: salidas de build, caches de dependencias y directorios temporales suelen ser seguros para excluir.
2. Escanea en los límites: escanea descargas, adjuntos de correo y artefactos al publicar—lugares donde el contenido entra o se vuelve duradero.
3. Evita el escaneo profundo de archivos por defecto: habilítalo selectivamente donde el riesgo sea real (gateways de correo, carpetas de descargas), no en todas partes.
4. VDI: coordina escaneos: escalona tiempos de inicio y limita recursos; de lo contrario tu almacenamiento compartido se convierte en víctima.

Preguntas frecuentes

1) ¿“Antivirus” es lo mismo que EDR?

No. El antivirus tradicional se centra en la detección de malware (firmas/heurísticas). EDR añade monitoreo de comportamiento, telemetría y acciones de respuesta. Muchos productos hacen ambas cosas hoy, por eso pueden tanto salvarte como romperte.

2) ¿Por qué el antivirus ralentiza tanto las compilaciones?

Las compilaciones crean y tocan un gran número de archivos pequeños. El escaneo en tiempo real puede inspeccionar cada apertura/escritura/cierre, multiplicando I/O. Añade escaneo de archivos comprimidos y acabarás escaneando dependencias comprimidas repetidamente.

3) ¿Las exclusiones son peligrosas?

Algunas sí. Excluir “C:\” es rendirse. Excluir directorios efímeros y regenerables (como salidas de build y caches) suele estar bien cuando se combina con escaneo en ingress (descargas) y al publicar (artefactos).

4) ¿Debemos ejecutar dos productos antivirus por “defensa en profundidad”?

No como dos escáneres en tiempo real. Eso es “defensa en profundidad de disco”. Si necesitas dos herramientas, pon una en modo pasivo/solo monitoreo y verifica ese estado continuamente.

5) ¿Cómo demostramos que el agente de seguridad es la causa sin desactivarlo?

Mide una carga de trabajo reproducible (hashear un árbol de directorios, compilar un repo, descomprimir un conjunto de dependencias), luego aplica una exclusión estrecha y vuelve a ejecutar. Si la diferencia es grande, has establecido causalidad con riesgo mínimo.

6) ¿Cuál es el indicador más rápido de un problema de política a nivel de flota?

Correlación temporal. Si muchas máquinas se degradan dentro de la misma hora y los logs muestran una actualización de política o cambio de feature flag, trátalo como un incidente de cambio y revierte primero.

7) ¿Por qué ocurren BSODs tras actualizaciones de seguridad?

Porque las herramientas endpoint a menudo distribuyen drivers o componentes filtro. Un bug o incompatibilidad en esa capa puede crashear el SO. La vía de solución es tanto operativa (detener despliegue, rollback, recopilar volcados) como técnica.

8) ¿Qué deberían tener las máquinas de desarrollador que no necesiten las de contabilidad?

Políticas diferentes. Los desarrolladores necesitan exclusiones para caches de build y un enfoque sensato para “ejecutables desconocidos” (idealmente firma de código). Las máquinas de contabilidad pueden tolerar controles de ejecución más estrictos y escaneos más agresivos.

9) ¿Mejorar el almacenamiento por sí solo arregla el dolor del antivirus?

Los SSDs más rápidos reducen el síntoma pero no la causa. El escaneo on-access aún puede saturar discos rápidos y consumir CPU. Ajusta el modelo de escaneo; no compres únicamente como solución.

10) ¿Cuál es el control operacional único más importante?

Despliegues escalonados con un interruptor de rollback. La mayoría de desastres por antivirus son “todo el mundo lo recibió a la vez”. No lo hagas.

Conclusión: pasos siguientes que reducen incidentes

Si tu antivirus puede tumbar endpoints, no es “solo una herramienta”. Es parte de tu sistema operativo. Trátalo con la misma disciplina: despliegues escalonados, presupuestos de rendimiento medibles y un plan de rollback que puedas ejecutar bajo estrés.

Haz lo siguiente:

1. Establece anillos para cambios en agentes de seguridad y políticas (test/piloto/escalonado).
2. Define tres benchmarks de endpoint (tiempo de inicio de sesión, tiempo de compilación/desempaquetado y una prueba de hash de recorrido de archivos) y ejecútalos tras cada cambio.
3. Separa políticas para desarrolladores, VDI, servidores y runners de CI.
4. Audita el doble escaneo y fuerza modo pasivo donde haga falta.
5. Crea un paquete de incidente estándar (logs, versiones, marcas de tiempo, volcados de crash) para que la próxima caída sea un diagnóstico rápido, no folklore.

La ironía seguirá repitiéndose hasta que cambies el flujo de trabajo alrededor de la herramienta. El software de seguridad que rompe PCs no es una paradoja. Es lo que ocurre cuando código privilegiado se publica sin operaciones de grado de producción.