Criticidad del activo y su dueño

Una CMDB (base de datos de gestión de la configuración) es la tabla donde cada activo se relaciona con lo que sostiene. Para el analista, el campo más útil es la criticidad, y no sale del tamaño ni del precio del equipo: sale de cuánto pierde el negocio cuando el activo se detiene o se compromete, de los datos que maneja, de si da a internet y de cuánto tiempo puede estar fuera.

Un servidor viejo en un rincón puede ser más crítico que uno nuevo: depende del proceso que cuelga de él. Por eso el campo que une activo y proceso importa tanto como la criticidad misma.

Ejecuta activos. Cada fila tiene proceso, datos, exposición y la criticidad declarada. Ejecuta después procesos: allí está lo que cada proceso pierde por cada hora detenido. Una buena práctica de revisión es cruzar las dos: si el proceso que más pierde cuelga de un activo declarado de criticidad baja, la declaración está mal, y cualquier alerta de ese equipo se triará con menos prisa de la debida.

Ejecuta procesos | sort by perdida_hora_cop desc | take 1 y activos | where criticidad == "baja".

La CMDB también dice quién decide. El dueño del proceso es quien aprueba que se aísle un equipo, quien sabe si una descarga masiva es normal y quien autoriza un parche. Un dueño solo es un punto único de falla: si no contesta, la alerta espera. Por eso cada proceso lleva un suplente, y la ventana de mantenimiento del proceso dice cuándo se puede actuar sin pedir permiso especial.

Ejecuta procesos | where proceso == "Tienda para distribuidores" para ver al dueño y al suplente del proceso de la tienda en línea.

Una base de configuración envejece como cualquier otra: los equipos cambian de manos, de proceso y de lugar, y las filas se quedan como estaban. La columna meses_sin_revision mide cuánto hace que alguien confirmó la fila. No hay un número universal; muchas organizaciones revisan al menos una vez al año, y ese es el umbral que se usa aquí.

Ejecuta activos | where meses_sin_revision > 12 | count.

Ejecuta ultima_actividad. Una fila dice que rfr-srv-vieja02 está retirado, y sin embargo mandó un registro al SIEM hace unas horas. Hay dos explicaciones posibles: la CMDB se quedó atrás y el servidor nunca se apagó, o alguien volvió a encender un equipo que ya no debería existir. Con la evidencia que hay no se sabe cuál es, pero sí se sabe qué no se puede hacer: confiar en la fila.