ENS desde dentro (XX): Configuración de seguridad (op.exp.2) — cómo demostrar que cada equipo nace bien protegido
Qué exige realmente op.exp.2 del ENS y cómo demostrarlo con evidencias: el caso real del alta de un equipo, desde el ticket hasta el inventario.
Cómo demostrar, con evidencias reales, que cada equipo nuevo nace bien protegido
El lunes por la mañana llega un ticket desde el gestor de peticiones. Recursos Humanos necesita dar de alta a un nuevo compañero que se incorpora al equipo comercial: hace falta un portátil, listo para el primer día.
Parece una tarea rutinaria de IT. Y lo es. Pero desde el punto de vista del Esquema Nacional de Seguridad, ese portátil que va a salir del almacén es también un activo que debe nacer bastionado, documentado y trazado desde el minuto uno. Eso es exactamente lo que exige op.exp.2 — Configuración de seguridad: que la configuración segura inicial de los equipos no sea un gesto de buena voluntad del técnico de turno, sino un proceso repetible y demostrable.
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-inventario-activos-op-exp-1/
Qué pide realmente este control
Op.exp.2 no pide que "el equipo esté bien configurado" en abstracto. Pide algo más concreto: evidencia de que ese equipo, antes de llegar a manos del usuario, pasó por una configuración segura conocida, documentada y repetible. En una auditoría, la pregunta no es "¿lo hacéis bien?", es "¿me lo puedes demostrar con un ticket, un checklist o un registro?".
Esa diferencia —entre hacerlo bien y poder demostrarlo— es la que separa una organización madura en ENS de una que solo lo parece.
El punto de partida: no se improvisa configuración
Antes de bastionar nada, lo primero es comprobar si existe una guía CCN-STIC aplicable al tipo de equipo (el propio CCN-CERT publica un catálogo completo en su portal). Si existe, se aplica todo lo que no limite el uso previsto del equipo. Si no existe una guía específica, entra en juego la línea base interna: un conjunto mínimo de medidas que se aplican siempre, según el tipo de activo, y que conviene tener ya convertidas en plantillas preconfiguradas en lugar de reconstruirlas cada vez desde cero.
Esa línea base, para puestos de usuario y servidores, cubre cinco bloques:
- Cuentas de usuario: renombrar la cuenta de administrador, eliminar la cuenta de invitado (y la cuenta "root" en servidores Linux), y forzar una política de contraseñas robusta.
- Control de acceso a la red: deshabilitar NETBIOS si no hace falta, activar la firma de paquetes SMB, cifrar el RDP, impedir la enumeración de recursos y cuentas, desactivar IPv6 y otros protocolos no usados, activar el cortafuegos y eliminar accesos anónimos.
- Protección de la información: aplicar mínimo privilegio en permisos de ficheros, desactivar el uso administrativo de unidades compartidas en entornos críticos y activar la prevención de ejecución de código malicioso (DEP).
- Sistema operativo: licencias en regla, eliminación de software innecesario, cierre de puertos y servicios que no se usan, antivirus instalado y actualizado, bloqueo de pantalla por inactividad, cifrado de disco en portátiles con información de nivel medio, y actualizaciones automáticas correctamente configuradas.
- Auditoría: registro de eventos activado, de forma que quede constancia de quién hizo qué, cuándo y sobre qué información —tanto los intentos con éxito como los fallidos.
Para elementos de red (switches, routers, firewalls) la lista se reduce pero mantiene la misma lógica: fuera cuentas y contraseñas por defecto, fuera "communities" SNMP predecibles, servicios y puertos innecesarios cerrados, y firmware al día.
El caso: de la petición al inventario
Así fue, paso a paso, el alta de un equipo para un nuevo compañero del equipo comercial:
1. La solicitud. Todo empieza con una petición formal desde RRHH a través del gestor de tickets, no con un correo suelto o una llamada. Ese ticket ya es la primera evidencia: queda constancia de quién lo pidió, cuándo y para qué perfil.
2. Bastionado según la línea base. Antes de entregarlo, el equipo pasa por la plantilla de configuración segura correspondiente a puesto de usuario: cuentas renombradas o eliminadas, política de contraseñas aplicada, cortafuegos activo, servicios y puertos innecesarios cerrados, bloqueo de pantalla configurado y registro de auditoría habilitado.
3. Parches y actualizaciones. Se verifica que el sistema operativo tiene todas las actualizaciones disponibles instaladas, y que el servicio de actualización automática queda correctamente configurado para el futuro —no es solo "que arranque al día", es que se mantenga al día.
4. Aplicación de GPOs corporativas. Se comprueba, directamente desde el propio equipo, que las políticas de grupo se han aplicado correctamente: restricciones, configuración de seguridad, políticas de usuario. Esto garantiza que ese portátil no es una excepción, sino que hereda automáticamente el mismo nivel de seguridad que el resto del parque.
5. Protección antimalware. Se valida que el software antivirus corporativo está instalado, operativo y actualizado. Sin esto, ningún equipo sale de IT.
6. Puertos USB deshabilitados. Como medida adicional dentro del bloque de protección de la información, se deshabilitan los puertos USB según la política corporativa, para evitar el uso de dispositivos extraíbles no autorizados.
7. Inventario. Por último —y esto es fácil de olvidar cuando el foco está en la parte técnica—, el activo se registra en el gestor de activos. Sin este paso, el equipo mejor bastionado del mundo es, para efectos de auditoría, un equipo que "no existe".
Lo que un auditor se va a llevar
De todo este proceso, lo que realmente sostiene el control ante una auditoría son las evidencias que quedan por el camino: el ticket de bastionado, la plantilla o checklist de configuración aplicada, las capturas de las GPOs, la confirmación del antivirus activo, el registro de puertos deshabilitados y la ficha del equipo en el inventario. Ninguna evidencia por separado cuenta toda la historia; es la suma de todas, con fecha y trazabilidad, la que demuestra que el control se ejecuta de forma sistemática y no como una excepción puntual.
La lección práctica
Si algo he aprendido implementando y auditando este control es que el mayor riesgo no está en la parte técnica, está en el registro. Es fácil bastionar un equipo bien y olvidarse de guardar la evidencia, o de dar de alta el activo en el inventario. Y ante un auditor, lo que no está documentado, no existe.
Mi recomendación: convierte cada uno de estos pasos en una checklist física dentro del propio ticket de alta, no en un procedimiento aparte que nadie relee. Así la evidencia se genera sola, como subproducto del trabajo diario, en vez de como una tarea extra al final.
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.