ENS desde dentro (XIX): Inventario de activos (op.exp.1) — no puedes proteger lo que no sabes que tienes

Inventario de activos en ENS (op.exp.1): identificador, categoría, propietario y criticidad. Descubre qué evidencias exige un auditor y por qué es la base de todo el bloque op.exp.

Share

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-mecanismo-autenticacion-op-acc-6/


Qué pide realmente el ENS

No basta con "tener controlado" el parque de equipos de cabeza. El ENS exige un inventario formal, mantenido y revisado, que identifique cada activo, lo clasifique y le asigne un responsable. Si un auditor te pregunta "¿cuántos servidores tenéis y quién responde de cada uno?", la respuesta tiene que salir de un sistema o documento, no de la memoria de alguien.


🧭 Paso 1: Qué debe incluir el inventario

Cada activo registrado necesita, como mínimo: un identificador, su categoría (equipos de usuario, servidores físicos o virtuales, software crítico y no gestionado, dispositivos de red como switches y cortafuegos) y un propietario identificado. Muchos inventarios se quedan solo en servidores y puestos de usuario, y se olvidan del equipamiento de red, que también es un activo y también hay que inventariar.

🧭 Paso 2: Propietario y ubicación, siempre

Para cada activo se registra quién es su propietario (quién decide sobre él) y dónde está ubicado. Sin estos dos campos, saber "a quién preguntar" o "dónde está físicamente" cuando hay un incidente se convierte en una búsqueda a ciegas.

🧭 Paso 3: Clasificar por criticidad

No todos los activos pesan lo mismo. Los servidores, en concreto, deben llevar asociado un nivel de criticidad además de su propietario: eso es lo que determina con qué frecuencia se revisan y qué medidas adicionales aplican. Tratar un servidor crítico igual que uno secundario es una forma fácil de fallar la revisión cuando más importa.

🧭 Paso 4: Que siga vivo — revisión periódica

Aquí es donde más organizaciones fallan. No basta con tener el inventario: hay que revisarlo periódicamente, con registro de esa revisión (por ejemplo, qué parches se han aplicado y en qué fecha). Un inventario de hace dos años, por completo que esté, no es evidencia de nada salvo de que nadie lo ha vuelto a mirar.

🧭 Paso 5: El ciclo de vida también genera evidencia

Cuando un activo cambia de forma relevante (una migración, una sustitución, una baja), ese proceso también debe quedar documentado, aunque sea con algo tan simple como el correo del proyecto. Es evidencia tan válida como una captura del inventario.


🧪 Evidencias que sí valen

Buenas evidencias:

  • Captura del gestor de activos con los equipos y servidores registrados
  • Activos clasificados por categoría (equipos de usuario, servidores, software, red)
  • Cada activo con propietario y ubicación identificados
  • Servidores con nivel de criticidad asignado
  • Registro de parches y actualizaciones con fecha de aplicación
  • Documentación de proyectos de migración o baja de activos (por ejemplo, un correo del proyecto)
  • Revisión periódica documentada, incluso cuando la realiza un proveedor externo

Malas evidencias:

  • Un Excel sin fecha de última modificación
  • Un inventario que no distingue hardware de software ni de red
  • Activos sin propietario ni ubicación
  • "Lo tenemos controlado" sin ningún documento que lo respalde

🧠 Ejemplo real

Con el fin del soporte de un sistema operativo por parte del fabricante, una organización acomete la migración de sus puestos de usuario a la versión siguiente. En los equipos donde el hardware no es compatible, en lugar de sustituirlos, se opta por una solución de virtualización de puesto. Todo el proyecto queda documentado por correo y reflejado en el inventario, sirviendo como evidencia del ciclo de vida completo del activo: qué cambió, cuándo y por qué. El auditor no solo ve el inventario actualizado, ve el porqué del cambio.

Error típico (muy común)

Inventariar servidores y puestos, y olvidarse del equipamiento de red (switches, cortafuegos). También es frecuente crear el inventario una sola vez, antes de la primera auditoría, y no volver a tocarlo: seis meses después hay activos nuevos que no están y de baja que siguen apareciendo.

Lo que te van a pedir en auditoría

El inventario en sí (documento o captura del sistema), evidencia de que se revisa periódicamente, que cada activo tenga categoría, propietario, ubicación y, en el caso de servidores, criticidad. Y la pregunta de siempre: si mañana entra un activo nuevo, o se da de baja uno viejo, ¿cómo se entera el sistema de que existe o dejó de existir?

Conclusión

El inventario de activos parece la medida más simple del ENS, y por eso mismo es la que más se descuida. Pero es la base de todo lo que viene después en el bloque op.exp: no puedes proteger, actualizar ni gestionar cambios sobre algo que no sabes que existe.


👉 Seguimos con el resto del bloque op.exp (configuración de seguridad, gestión de cambios, protección frente a código dañino, gestión de incidentes...) en próximos artículos.