ENS desde dentro (XXIV): Protección frente a código dañino (op.exp.6) — qué evidencias pide un auditor sobre tu antivirus

Tener un antivirus instalado no es lo mismo que poder demostrar que protege lo que dice proteger. Y op.exp.6 está pensado exactamente para esa diferencia.

Este artículo forma parte de la serie ENS desde dentro.

👉 Puedes ver la guía completa aquí:

https://www.handersonboratto.com/ens-desde-dentro/

👉 Si es tu primera vez en la serie, empieza por aquí:

https://www.handersonboratto.com/blog/que-es-ens/

👉 O continúa con el artículo anterior:

https://www.handersonboratto.com/blog/ens-gestion-del-cambio-op-exp-5/

Si op.exp.5 se ocupaba de decidir qué modificación necesita papeles y cuál no, op.exp.6 vuelve a un terreno más conocido para cualquier técnico: el antivirus. La diferencia es que el ENS no pregunta si tienes uno instalado, sino si puedes demostrar, con capturas y configuración real, que cumple ocho características concretas en todos los puestos, servidores y elementos perimetrales.

Qué exige realmente el control

No basta con "tenemos antivirus". El ENS detalla ocho comportamientos que la solución tiene que cumplir, y que un auditor puede pedirte que le enseñes uno por uno:

Las firmas y bases de detección se actualizan de forma permanente, sin depender de que alguien se acuerde de lanzar la actualización. Los usuarios no tienen permisos para desactivar ni alterar la solución: si un usuario pudiera pararla desde el propio equipo, el control no vale de nada. El mantenimiento se hace conforme a las instrucciones del fabricante, no "a ojo". Hay protección en tiempo real, que analiza cualquier fichero que llegue de una fuente externa —USB, descarga, correo—. Se ejecutan escaneos periódicos programados, no solo análisis bajo demanda. Existe monitorización de integridad, capaz de detectar modificaciones no autorizadas en las funciones críticas del sistema al menos al arrancar. Hay una lista blanca de aplicaciones autorizadas que impide ejecutar cualquier cosa que no esté en ella. Y por último, la solución tiene capacidades EDR: detectar, investigar y resolver actividad sospechosa, no solo bloquear firmas conocidas.

Dos frentes distintos: consola central y estaciones

En la práctica esto se despliega en dos capas que conviene distinguir bien porque un auditor las revisa por separado. Por un lado, el software de protección contra código malicioso instalado en los servidores, gestionado desde una consola central donde se ve el estado de todo el parque de un vistazo. Por otro, el EDR en las estaciones de usuario, que añade la capa de detección y respuesta que un antivirus tradicional no cubre: no solo avisa de que algo raro ha pasado, sino que permite investigar qué hizo ese proceso y aislar el equipo si hace falta.

La consola central es la pieza que más tranquilidad da el día a día: un panel donde se ve de un vistazo qué hosts están protegidos, cuáles llevan tiempo sin reportar y qué alertas están abiertas. Si un equipo desaparece de esa lista o deja de actualizar firmas, es la primera señal de que algo no va bien, mucho antes de que se convierta en un incidente.

Cómo se demuestra: la evidencia mínima

Aquí es donde este control se parece más a una auditoría técnica que a una declaración de intenciones. La evidencia que suele pedirse incluye, como mínimo: constancia de la instalación del software de protección en servidores y, por separado, del EDR en estaciones de usuario; una captura del panel central del producto antimalware; una captura de la lista de hosts y alertas en la consola; algo que acredite que las funciones críticas se escanean al iniciar el sistema para detectar modificaciones no autorizadas; evidencia de que existe una lista blanca de aplicaciones autorizadas; y una muestra de que el producto tiene capacidades reales de EDR —no solo la casilla marcada en la ficha comercial, sino la funcionalidad activa y usada—.

Ninguna de estas evidencias es difícil de obtener por separado. Lo que las hace un problema real es reunirlas todas juntas, actualizadas, el día que el auditor las pide con una semana de margen. La solución de siempre: una carpeta con capturas fechadas, revisada cada vez que cambias de producto o de versión, no la noche antes de la auditoría.

La lección práctica

Si algo me llevo de este control es que la parte técnica —tener un buen antivirus o un buen EDR— suele estar resuelta hace años; la parte que falla es la evidencia: la captura de pantalla que nadie guardó, la lista blanca que existe pero no está documentada, el escaneo de integridad al inicio que está activado pero nadie ha comprobado nunca que realmente se dispara.

Mi recomendación: no esperes a la auditoría para mirar tu propia consola con ojos de auditor. Una vez al trimestre, entra en el panel central, haz las ocho capturas que este control te va a pedir, y guárdalas con fecha. Si algún día un host no aparece donde debería, lo vas a descubrir tú antes que el auditor.

Este post forma parte de la serie "ENS desde dentro", donde comparto cómo se implementan y auditan en la práctica las medidas del Esquema Nacional de Seguridad. Si te está siendo útil, puedes suscribirte a la newsletter para recibir cada entrega, o descargar el checklist "Documentación para una auditoría ENS" con los 8 bloques de evidencia que un auditor va a pedirte.