Hardening and auditing SLES 16: OpenSCAP, CIS context and SUSE Multi-Linux Manager

This lab article closes a practical gap in the SUSE series: it does not stop at installing SLES 16, but shows how a managed SLES 16 system behaves when OpenSCAP content, hardening profiles, remediation and SUSE Multi-Linux Manager lifecycle channels meet in practice.

The important finding is deliberately precise: CIS publishes a benchmark for SUSE Linux Enterprise 16, but the SUSE-provided scap-security-guide package in this lab exposes ANSSI, HIPAA, PCI-DSS and base profiles for SLE 16, not a ready-made CIS Level 2 profile. Therefore this article documents an ANSSI-BP-028 high run and explains how CIS Level 2 must be handled separately and honestly.

Why CIS, OpenSCAP and Hardening Matter

CIS Benchmarks are vendor- and community-maintained security baselines. They translate common operating-system hardening questions into concrete checks: password policy, SSH behavior, sudo restrictions, file permissions, audit rules, kernel parameters and logging. In practice they are useful because security teams, auditors and operations teams can discuss the same baseline instead of comparing vague hardening opinions.

OpenSCAP is tooling for evaluating machine-readable SCAP content. The oscap command can scan a system, generate an HTML report and, depending on the profile, create remediation in Bash or Ansible form. That makes hardening repeatable: first measure, then change deliberately, then scan again and document exceptions.

SUSE Multi-Linux Manager adds the operational layer around that workflow. Packages, profiles, remediation runs and evidence do not live on an isolated test machine, but inside the same lifecycle, proxy and channel model that also supplies updates to production servers. That is why this article checks the manager and channel path before looking at the score.

Concepts at a glance

Lab Setup

Systems used

mlm01.example.test

The SLES 16 client was reachable through the proxy, registered in SUSE Multi-Linux Manager and assigned to a production lifecycle channel. That is intentionally close to a customer rollout: the compliance workflow must work through the same package and proxy path that normal operations use.

Channel Readiness Before Hardening

The first check was not an OpenSCAP scan. It was package availability on the managed client. A hardening guide is not useful if the client cannot install the scanner and the security guide from its assigned lifecycle channel.

zypper refresh
zypper se -s openscap scap-security-guide
rpm -q openscap openscap-utils libopenscap33 scap-security-guide

In the lab, the production channel assigned to the client did not expose all OpenSCAP packages even though the manager already had them in other synchronized SLES 16 channels. This is a realistic lifecycle-management issue: cloned channels can be too narrow or stale. Fix the channel content before scheduling scans at scale.

Package readiness

Available SLES 16 Profiles

oscap info /usr/share/xml/scap/ssg/content/ssg-sle16-ds.xml

Profile result

Baseline Scan

mkdir -p /root/openscap-evidence/sles16-hardening-20261006
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --results /root/openscap-evidence/sles16-hardening-20261006/anssi-high-results.xml \
  --report /root/openscap-evidence/sles16-hardening-20261006/anssi-high-report.html \
  /usr/share/xml/scap/ssg/content/ssg-sle16-ds.xml

sles16-client01.example.test

Baseline result

Controlled Remediation

Before applying remediation, the VM was snapshotted. This is not optional for high-hardening profiles. Partitioning, sudo, audit, PAM, SSH and kernel settings can affect access and operations immediately.

virsh snapshot-create-as \
  --domain sles16-client01 \
  --name before-openscap-anssi-high-20261006 \
  --description "Before SLES16 OpenSCAP ANSSI high remediation evidence run" \
  --disk-only --atomic --no-metadata

oscap xccdf generate fix --fix-type bash \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --output anssi-high-remediation.sh \
  anssi-high-results.xml

oscap xccdf generate fix --fix-type ansible \
  --profile xccdf_org.ssgproject.content_profile_anssi_bp28_high \
  --output anssi-high-remediation.yml \
  anssi-high-results.xml

The remediation script completed, but the log also showed realistic limits: some packages could not be reinstalled from the assigned repositories, one SSSD PAM remediation was missing, and sudo was hardened with requiretty, noexec, use_pty and umask. That is exactly why remediation belongs into a tested maintenance workflow instead of a blind one-liner.

sles16-client01.example.test

Before and after

What This Means for CIS Level 2

Do not rename an ANSSI high scan to CIS Level 2. If a customer requires CIS Level 2 for SLES 16, the correct path is to obtain the CIS SLE 16 benchmark content, run it with CIS-CAT Pro or a validated tailored SCAP workflow, document local exceptions and keep the evidence tied to the actual benchmark version.

Technical acceptance

Operational Checklist

For production, treat this as a controlled change: verify channel contents, snapshot or backup first, run a baseline scan, review the generated remediation, apply in a maintenance window, re-scan, document exceptions and only then define whether the system is compliant enough for the intended workload.