Del hallazgo a la remediación en el servidor

Un buen hallazgo de configuración tiene cinco partes: la evidencia, una línea o un resultado que cualquiera puede volver a abrir; la clasificación, el CWE que corresponde; la severidad, medida con la rúbrica del cliente y no con la sensación del auditor; la remediación, que quita la causa y no el síntoma; y la verificación de cierre, un paso que alguien puede repetir para comprobar que ya no se da.

Una remediación como «revisar» o «tener cuidado» no cumple: no dice qué cambiar. Y una severidad sin rúbrica invita a discutirla en lugar de arreglarla.

La rúbrica del cliente define tres niveles con una condición cada uno. Un hallazgo sube o baja de nivel por esa condición, no por lo mucho que suene. Un dato de la plataforma que ayuda a quien prepara un ataque pero no da acceso por sí solo cae en lo más bajo de la escala; ponerlo al nivel de una clave expuesta quita credibilidad a todo el informe.

Abre rubrica.txt y borrador.txt y compara la severidad de cada fila con su condición.

Una acción que no modifica la configuración no corrige nada: al volver a arrancar, el servidor lee el mismo archivo y ofrece lo mismo. Una remediación vale si, aplicada, la evidencia de la columna anterior deja de existir. La pregunta para cada fila es simple: si se hace esto, ¿qué línea de la configuración cambia?

Revisa la columna de remediación del borrador y busca la que no cambia ninguna línea.

Sin verificación de cierre, un hallazgo se «cierra» porque alguien dice que lo hizo. Con ella, el equipo repite un paso concreto, como una petición, una lectura de permisos o un escaneo, y ve el cambio. El auditor que redacta la verificación obliga a pensar si la remediación realmente se puede comprobar.

Cuenta las filas del borrador cuya columna de verificación está vacía.

El borrador anota la clave privada del certificado con permiso de lectura para cualquier usuario del sistema (CWE-732). Aquí la remediación tiene dos partes, y la segunda es la que más se olvida: restringir el permiso arregla el futuro, pero si cualquier cuenta del sistema pudo leer la clave durante meses, no se puede asegurar que nadie la copió. Una clave privada que estuvo al alcance de quien no debía se trata como expuesta.