Aplique el SLES 15 STIG de forma segura con OpenSCAP.

Utilice el perfil DISA STIG compatible con SUSE para SLES 15, analice el servidor con OpenSCAP y aplique las correcciones solo después de revisar la línea base en un sistema de prueba. Por ejemplo, imaginemos a un administrador ficticio llamado Alex preparando un servidor SLES 15 para un servicio regulado: Alex utiliza el flujo de trabajo que se describe a continuación para identificar hallazgos, probar los cambios y recopilar evidencia, pero no considera un análisis automatizado sin errores como una aprobación de cumplimiento.

Los comandos siguen las directrices STIG actuales de SUSE para SLES 15. El contenido del perfil puede cambiar con las actualizaciones de paquetes y las versiones de las pruebas de rendimiento DISA, por lo que conviene verificar la versión aplicable y los requisitos específicos del sistema antes de utilizar este procedimiento. Las imágenes de la terminal ilustran los comandos y no muestran la salida real del análisis.

1. Confirmar el objetivo y el punto de referencia actual.

Para empezar, registra el Service Pack SLES del host, su propósito, su función de red y las aplicaciones. Alex anota qué servicios deben permanecer disponibles, cómo se conectan los administradores y el método de recuperación si un cambio de seguridad interrumpe el acceso. Este alcance es importante: un servidor de base de datos y un servidor de propósito general pueden tener excepciones aprobadas diferentes, incluso si ambos utilizan el mismo perfil STIG del sistema operativo.

Compruebe la versión instalada antes de seleccionar el contenido:

cat /etc/os-release
hostnamectl

A continuación, obtenga la lista de verificación y la revisión de referencia STIG de SLES 15 correspondientes a través de la página oficial de descargas de DISA STIG . Compare la lista de verificación con la familia de sistemas y siga las instrucciones de evaluación de su organización. SUSE documenta la compatibilidad con el perfil SCAP “DISA STIG para SUSE Linux Enterprise 15”, pero esto por sí solo no determina qué versión requiere su autoridad ni certifica un host.

2. Instale y verifique el contenido de SCAP.

En un sistema SLES registrado con acceso a los repositorios adecuados, instale las utilidades de línea de comandos de OpenSCAP y el contenido de la Guía de seguridad de SCAP:

sudo zypper install openscap-utils scap-security-guide

Los nombres de los paquetes y la ubicación del flujo de datos de SLES 15 que se muestran a continuación están documentados en la guía de endurecimiento OpenSCAP de SUSE y en el procedimiento STIG de SUSE . Los repositorios de paquetes y las revisiones de perfiles pueden variar según el paquete de servicio y el nivel de actualización. Enumere los flujos de datos instalados e inspeccione el archivo candidato en lugar de asumir un nombre de archivo o perfil.

ls -1 /usr/share/xml/scap/ssg/content/ssg-*-ds.xml
oscap info /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Confirme que el flujo de datos SLES 15 esté presente y que la lista de perfiles incluya stig. Si falta el archivo o perfil, detenga la prueba y solucione la discrepancia entre el paquete o el repositorio; no sustituya la prueba de rendimiento de otro sistema operativo.

3. Establezca una línea de base y luego pruebe la remediación.

Cree un directorio de evidencia protegido antes de generar informes. Escanee primero, sin cambiar la configuración del sistema:

sudo install -d -m 0700 /root/stig-review
sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/baseline.xml \
  --report /root/stig-review/baseline.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

Abra el informe HTML y revise cada resultado, especialmente los fallos, errores y reglas que no se pudieron verificar. Conserve el XML y el informe como evidencia de configuración confidencial. Pueden revelar detalles del host y la postura de seguridad, por lo que debe almacenarlos o transferirlos únicamente a través de canales autorizados.

A continuación, clone o cree una instantánea del servidor en un entorno que no sea de producción. Valide el comportamiento de la aplicación, el acceso a la identidad, la red, la monitorización y la recuperación antes de aplicar los cambios automatizados. SUSE advierte a los administradores que prueben primero la corrección fuera de producción, ya que modifica la configuración del sistema. En el host de prueba, el método documentado sobre la marcha es:

sudo oscap xccdf eval --remediate \
  --profile stig \
  --results /root/stig-review/remediation.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

El resultado generado puede incluir un resultado de prueba previo y posterior a la corrección. Una regla marcada fixedindica que se aplicó su corrección automatizada y que la regla superó la evaluación; una errormarca significa que la corrección falló para esa regla. Ninguno de estos estados reemplaza las pruebas operativas ni la revisión del requisito subyacente.

4. Vuelva a escanear, resuelva las excepciones y conserve la evidencia.

Tras revisar el comportamiento de la prueba, ejecute un escaneo independiente con rutas de salida nuevas. Una evaluación que solo incluya el escaneo ayuda a distinguir el estado actual de la ejecución de corrección.

sudo oscap xccdf eval \
  --profile stig \
  --results /root/stig-review/final.xml \
  --report /root/stig-review/final.html \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

No espere que todas las reglas se puedan corregir automáticamente. Investigue los fallos comparándolos con el texto completo de verificación y corrección de la regla en la versión exacta de la lista de verificación DISA seleccionada para el sistema. Algunas reglas requieren una decisión deliberada del responsable del servicio, una configuración específica del sitio o evidencia manual. Si una regla no es aplicable o no se puede cumplir, documente la justificación y los controles compensatorios mediante el proceso formal de excepciones de la organización; modificar o adaptar un perfil no garantiza por sí solo que se cumpla el requisito.

Para la revisión de la lista de verificación, SUSE documenta la exportación de un archivo XCCDF que se puede importar al Visor DISA STIG. Genere el archivo con la opción compatible y luego impórtelo al Visor siguiendo las instrucciones de usuario vigentes:

sudo oscap xccdf eval \
  --profile stig \
  --stig-viewer /root/stig-review/results_stig.xml \
  /usr/share/xml/scap/ssg/content/ssg-sle15-ds.xml

El paquete de evidencia de Alex para el servidor ficticio registra la identidad del host y del paquete de servicio, la revisión de referencia, la versión del contenido SCAP, la fecha de escaneo, los informes de referencia y finales, las acciones correctivas, las verificaciones manuales y las excepciones aprobadas. Confirme que los archivos existen y que solo los revisores autorizados pueden leerlos:

sudo ls -l /root/stig-review

Antes de dar por finalizada la tarea, verifique que el informe final refleje un análisis realizado tras los cambios, que cada hallazgo restante tenga un responsable y una resolución, y que los servicios necesarios del servidor sigan funcionando. El cumplimiento de STIG es un estado evaluado vinculado a un punto de referencia y un alcance del sistema específicos; OpenSCAP respalda dicha evaluación, pero no otorga acreditación ni garantiza que se hayan cumplido todos los requisitos del sitio.

Fuentes

• SUSE: Refuerzo de la seguridad de SUSE Linux Enterprise con STIG
• SUSE: Refuerzo de SLES con OpenSCAP
• DISA: Descargas STIG