Las bases de datos de gestión de la configuración (CMDB) se desarrollaron para gestionar la configuración de la infraestructura de TI: comprender cómo dependen los activos unos de otros, planificar cambios y gestionar sistemas a gran escala. Durante años se consideraron principalmente una herramienta de TI. Sin embargo, hoy, con la proliferación de ransomware cada vez más agresivo, los frecuentes ataques a la cadena de suministro y un número creciente de posibles vectores de acceso —cada dispositivo, aplicación o conexión de red a través del cual una organización puede sufrir un ataque—, la CMDB ha adquirido un papel más estratégico: se ha convertido en un mapa actualizado de los riesgos a los que se enfrenta la organización cada día.
Cuando los datos de configuración están incompletos u obsoletos, se crean puntos ciegos —partes de la infraestructura que ni el equipo de TI ni los responsables de seguridad pueden ver— que pueden ser aprovechados durante un ciberataque. Es un problema que afecta directamente tanto a los responsables de TI como a los profesionales de ciberseguridad, que a menudo analizan la misma infraestructura utilizando herramientas y datos diferentes.
De herramienta de TI a mapa real del riesgo
En su función tradicional, una CMDB es la fuente única y fiable de información sobre la infraestructura de TI.
Una CMDB registra cada componente que debe gestionarse para prestar un servicio, los denominados elementos de configuración (configuration items o CI) —servidores, aplicaciones, dispositivos, servicios, contratos— y, sobre todo, representa sus relaciones y dependencias. Es esta información sobre las relaciones entre los distintos elementos, más que el simple listado de recursos, lo que distingue a una CMDB de un inventario estático: cuando un componente falla o cambia, el sistema muestra de inmediato qué servicios pueden verse afectados.
Conviene recordar que una CMDB no es lo mismo que la gestión de activos de TI: son dos disciplinas complementarias pero distintas, y comprender bien la diferencia es fundamental para construir una CMDB realmente fiable. Los mismos datos que permiten planificar un cambio permiten hoy al equipo de seguridad identificar qué activos están expuestos, dónde se encuentran y qué nivel de criticidad tienen.
Aquí entra en juego un principio básico de la ciberseguridad: no se puede proteger aquello cuya existencia se desconoce. Una CMDB precisa proporciona exactamente esa visibilidad de los activos (asset visibility) que hace más eficaces las medidas de protección posteriores.
Puntos ciegos: cuando la CMDB deja de reflejar la realidad
El problema es que pocas CMDB están realmente completas. Y cada dato que falta o no está actualizado puede acabar convirtiéndose en un riesgo para la seguridad. Algunos escenarios concretos muestran cómo la ausencia de información en la CMDB puede generar vulnerabilidades.
Carencias que se convierten en riesgos
El primer escenario es el de los endpoints no registrados. Un dispositivo que no aparece en la CMDB no recibe parches, no se monitoriza y queda fuera de los controles de seguridad: para la organización simplemente no existe, pero sigue siendo un posible punto de entrada a la red corporativa.
El segundo hace referencia al software no autorizado: aplicaciones instaladas al margen de los procedimientos oficiales y sin conocimiento del equipo de TI, que nadie actualiza y que aumentan el número de posibles puntos de entrada para un ataque, es decir, amplían la superficie de ataque de la organización.
El tercero hace referencia a las integraciones no documentadas: conexiones entre sistemas creadas por necesidad y que nunca se han registrado, que pueden aprovecharse para propagar una intrusión de un sistema a otro tras superar las defensas perimetrales, lo que se conoce como movimiento lateral.
Un caso especialmente representativo es el de la aplicación urgente de un parche de seguridad. Un analista identifica una vulnerabilidad crítica en un paquete de software, localiza los activos afectados y transmite la lista al equipo de TI para que intervenga. Pero si los datos de la CMDB no se corresponden con la realidad, el equipo de TI no sabe con certeza dónde se encuentran esos sistemas y el flujo de trabajo se bloquea precisamente en el momento más crítico: cuando la vulnerabilidad ya es conocida pero aún no se ha corregido. Una CMDB actualizada hace que esta intervención sea rápida y ordenada, mientras que una CMDB obsoleta la convierte en un cuello de botella.
Por qué los datos permanecen incompletos
Las carencias informativas que hemos descrito tienen una causa recurrente: procesos de descubrimiento rígidos o que solo se ejecutan periódicamente. Con la proliferación de los servicios en la nube, los dispositivos móviles y el Internet de las Cosas, un inventario actualizado solo de forma ocasional ya no es suficiente.
El riesgo es que queden fuera de la CMDB activos expuestos a Internet heredados de adquisiciones o filiales, dispositivos personales que se conectan a la red y dispositivos IoT y OT —tecnologías operativas utilizadas, por ejemplo, en entornos industriales— en los que no es posible instalar los agentes de software necesarios para la monitorización.
A esto se suma el fenómeno del Shadow IT y, especialmente, del Shadow SaaS: servicios cloud contratados por distintos departamentos sin supervisión de TI, que crean puntos ciegos difíciles de detectar y aún más difíciles de proteger. En todos estos casos, lo que falta ante todo es visibilidad sobre los activos y, con ella, la capacidad de protegerlos.
El coste de los activos no gestionados
Los datos confirman el alcance del problema. Una investigación realizada por Sapio Research para Trend Micro reveló que el 74 % de los más de 2.000 responsables de TI y seguridad encuestados había sufrido incidentes causados por activos desconocidos o no gestionados.
En cuanto al impacto, el Cost of a Data Breach Report de IBM reveló que más de un tercio de las brechas implica «shadow data», es decir, datos almacenados en sistemas no gestionados. Este tipo de brechas tarda más en detectarse y contenerse y, de media, resulta más costoso.
Por último, la encuesta de TeamViewer sobre digital friction muestra hasta qué punto son frecuentes algunas de las situaciones que alimentan estos riesgos: el 66 % de los trabajadores se enfrentó durante el último año a actualizaciones forzadas o incluso a ciberataques como malware y ransomware.
¿Qué se necesita para que una CMDB esté preparada para la seguridad?
Para que la CMDB pueda contribuir a la seguridad de la organización deben cumplirse ciertos requisitos operativos, los mismos que distinguen a una CMDB fiable de un simple listado estático que acabará quedándose obsoleto.
Los requisitos técnicos
El primero es el descubrimiento continuo. No una fotografía periódica, sino un análisis constante del entorno de TI que permita identificar casi en tiempo real nuevos dispositivos, software y cambios de configuración. Es la única manera de mantenerse alineado con una infraestructura que cambia continuamente y de mantener una visibilidad de los activos que refleje realmente el estado actual del entorno.
El segundo es la reconciliación automatizada. La información detectada mediante el descubrimiento debe compararse continuamente con los datos registrados en la CMDB, señalando cualquier discrepancia. Sin esta comparación sistemática, las diferencias entre lo que realmente existe en la infraestructura y lo que la CMDB tiene registrado se van acumulando hasta que los datos dejan de ser fiables.
El tercero es la integración con la gestión de vulnerabilidades. Conectar la CMDB con las herramientas que detectan vulnerabilidades permite saber de inmediato qué activos están realmente afectados. También permite decidir qué corregir primero, no solo en función de una puntuación técnica abstracta, sino teniendo en cuenta la importancia real de cada activo: su criticidad para las operaciones, quién es responsable de él y qué servicios dependen del mismo. Es aquí donde la CMDB deja de ser un simple repositorio de TI y se convierte en una herramienta operativa de ciberseguridad.
El cuarto requisito, a menudo el más olvidado, es establecer claramente quién es responsable de la calidad de los datos. Cada tipo de elemento de configuración debe tener un responsable que garantice la calidad y actualización de su información a lo largo del tiempo.
Una inversión común para TI y seguridad
Modernizar el ITSM y, en particular, la CMDB significa mejorar al mismo tiempo la eficiencia operativa e invertir directamente en la seguridad de la organización. Es una cuestión que afecta por igual a los responsables de TI y a los de ciberseguridad, porque ambos dependen de la misma base de datos fiable.
Cuando TI y seguridad comparten una única fuente de información fiable, dejan de trabajar con visiones diferentes de una misma infraestructura. El equipo de seguridad dispone así del contexto necesario —qué activos existen, qué nivel de criticidad tienen y quién es responsable de ellos— para evaluar el riesgo y establecer prioridades de forma eficaz.
El equipo de TI, por su parte, puede actuar con mayor seguridad sobre los sistemas realmente afectados. Y en ambos casos se reducen los puntos ciegos en los que los incidentes pueden desarrollarse sin ser detectados.
En conclusión, la precisión de la CMDB es un indicador concreto del nivel de madurez en ciberseguridad. Una CMDB actualizada y completa no solo mejora la prestación de servicios: refleja hasta qué punto una organización conoce —y, por tanto, puede proteger— todos los dispositivos, aplicaciones y conexiones que podrían exponerla a un ataque.
La visibilidad de los activos que proporciona una CMDB bien mantenida sigue siendo una de las defensas más infravaloradas. Tratarla como un mero trámite técnico supone renunciar a una capacidad de protección que, en gran medida, ya existe dentro de la propia organización y que debe ser cada vez más precisa, continua y compartida.
FAQs
1. ¿Por qué es relevante una CMDB para la ciberseguridad?
Porque proporciona un mapa actualizado de todos los activos y de las dependencias entre ellos. Sin esta visibilidad, los equipos de seguridad no pueden saber con certeza qué deben proteger ni dónde aplicar los parches. Los activos no registrados pueden quedar expuestos sin que la organización sea consciente de ello.
2. ¿Qué carencias de la CMDB crean riesgos para la seguridad?
Principalmente los endpoints no registrados, el software no autorizado y las integraciones no documentadas. Cada elemento ausente de la CMDB queda fuera de la monitorización, las actualizaciones y los controles, ampliando de forma silenciosa la superficie de ataque.
3. ¿Qué distingue a una CMDB «preparada para la seguridad»?
Cuatro requisitos: descubrimiento continuo en lugar de periódico, reconciliación automatizada entre el estado detectado y los datos registrados, integración con la gestión de vulnerabilidades y una responsabilidad clara sobre la calidad de los datos.
4. CMDB y visibilidad de los activos: ¿qué relación existe entre ambas?
La visibilidad de los activos es la capacidad de saber qué activos existen y en qué estado se encuentran. Una CMDB precisa y continuamente actualizada es una de las herramientas que permite conseguir esa visibilidad y, por tanto, constituye un pilar tanto del ITSM como de la ciberseguridad.
Guía sobre IA en ITSM
Descubre cómo integrar la inteligencia artificial en tu ITSM, replantear tus procesos y mejorar la eficiencia de tu empresa.
