Endurecimiento según benchmark

Un benchmark devuelve, por máquina, cuántos controles evaluó, cuántos aprobó, cuántos falló y cuántos quedaron como excepción. Es tentador reducirlo a un porcentaje y a un semáforo. El problema es que un 90 % de aprobados puede esconder que el 10 % que falla es justo el inicio de sesión remoto de root, mientras que otra máquina con 80 % solo falla detalles cosméticos.

Abre resultado-benchmark.csv. Las cifras por máquina son el punto de partida; el control concreto que falla es lo que decide qué se arregla primero.

Cuando un mismo control falla en casi toda la flota, rara vez es descuido de cada administrador: casi siempre es algo que la imagen o la configuración base nunca trajo. Arreglarlo en la imagen resuelve la flota entera y evita que reaparezca en la próxima instancia.

hallazgos-por-control.csv es un extracto con la lista de hosts que fallan cada control. La columna cantidad ya cuenta cuántos son.

Un benchmark no se cumple al pie de la letra en todas partes. A veces un control choca con la función de la máquina y se acepta una excepción: con responsable, motivo y fecha de vencimiento. La fecha es lo que la distingue de un olvido: al vencer, la excepción se renueva con argumentos nuevos o se corrige el control.

Lee excepciones.txt y compara su fecha de vencimiento con la del inventario, que está en el encargo.

La excepción de este caso tiene un motivo técnico plausible: una máquina que traduce direcciones necesita reenviar paquetes. Que el motivo sea razonable no la mantiene viva sola. Lo correcto es devolverla al ciclo de decisión: quien la aceptó la revisa con la evidencia de hoy, y se renueva con nueva fecha o se retira.

Para dimensionar el esfuerzo de remediación de un perfil se suman los controles fallidos de todas las máquinas evaluadas: no son hallazgos únicos, porque un mismo control puede fallar en varias, pero sí es la carga de trabajo si se arreglara máquina por máquina. Suma la columna fallidos del resultado de las cinco máquinas.