Análisis de un host Linux frente a una línea base con OpenSCAP

Objetivo

Evaluar un host Linux frente a un perfil de seguridad publicado con OpenSCAP y generar un informe que muestre con exactitud qué comprobaciones se superan, cuáles fallan y cuáles no son aplicables.

Requisitos previos

Privilegios de root (un análisis sin root no puede leer muchos de los archivos y ajustes que comprueban las reglas). En los sistemas de la familia RHEL, el paquete openscap-scanner proporciona oscap y scap-security-guide aporta el contenido, que incluye un archivo de data stream como /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml (ssg-rhel8-ds.xml o ssg-rhel10-ds.xml para otras versiones; conviene listar el directorio en lugar de adivinar el nombre). Otras distribuciones empaquetan el contenido con nombres distintos, o no lo empaquetan. El proyecto se llamó originalmente SCAP Security Guide (SSG) y distribuye un archivo de data stream por cada producto compatible.

Pasos

1. Listar los perfiles disponibles en un archivo de data stream: oscap info /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. Cada perfil tiene un ID como xccdf_org.ssgproject.content_profile_cis; los perfiles que existen (niveles CIS, STIG, OSPP, etc.) dependen de la versión del contenido, así que hay que copiar el ID de esta salida.
2. Ejecutar una evaluación con el perfil elegido, escribiendo tanto un archivo de resultados legible por máquina como un informe HTML: oscap xccdf eval --profile xccdf_org.ssgproject.content_profile_cis --results-arf arf.xml --report report.html /usr/share/xml/scap/ssg/content/ssg-rhel9-ds.xml. El manual de oscap documenta exactamente esta forma xccdf eval --profile PROFILE_ID ... --report REPORT_FILE. En scripts, hay que tener en cuenta que oscap termina con código 2 cuando el análisis se completó pero al menos una regla falló, y con código 1 cuando se produjo un error real; no se debe tratar cualquier código distinto de cero como un análisis fallido.
3. Abrir report.html (o copiarlo fuera del host) y leer los recuentos de superadas, fallidas y no aplicables por regla antes de cambiar nada.
4. Se puede generar un script de remediación a partir de los resultados con oscap xccdf generate fix --fix-type bash --output fix.sh --result-id <id> arf.xml (o --fix-type ansible); hay que leer cada comando que contiene: es un punto de partida, no un script para pasarlo directamente a un shell. Se debe evitar oscap xccdf eval --remediate en hosts de producción: aplica todas las correcciones del perfil durante el análisis.
5. Aplicar solo las remediaciones revisadas y aceptadas y volver a ejecutar el mismo comando oscap xccdf eval para confirmar que las reglas concretas ahora se superan.
6. Conservar el par arf.xml/report.html con su fecha como registro de auditoría de ese host y de esa versión del perfil.

Resultado esperado

Un informe que lista todas las reglas del perfil elegido con un estado de superada, fallida, no aplicable o error, reproducible al volver a ejecutar el mismo comando con el mismo archivo de data stream.

Límites y base de verificación

oscap informa del estado de un sistema frente a las comprobaciones de un perfil; no garantiza por sí mismo que dichas comprobaciones sean adecuadas para una carga de trabajo concreta, por lo que hay que revisar antes de remediar (véase el artículo sobre líneas base CIS/STIG). Ningún comando individual deshace lo que aquí se describe: antes de ejecutarlo, conviene hacer una copia de seguridad de cualquier archivo de configuración que oscap o su remediación modifiquen, igual que en cualquier otra edición manual. Para ejecutar un análisis no hace falta reiniciar; un paso de remediación sí puede requerirlo, según lo que cambie.