Automating Security Compliance: Surviving Schrems II with IaC and OpenSCAP

If you are manually editing /etc/ssh/sshd_config on your production servers in 2024, you have already failed. In the current regulatory climate—specifically here in Norway with Datatilsynet watching and the shadow of Schrems II looming over every data transfer—security compliance is not a quarterly checkbox. It is an operational necessity that must be codified.

As a CTO, I have watched teams burn weeks preparing for audits, frantically patching vulnerabilities that should have been addressed in the provisioning phase. The reality is simple: compliance that relies on human memory is compliance that will fail. The only way to ensure your infrastructure remains secure and legally sound is to treat your security posture as code.

This guide details how to automate Center for Internet Security (CIS) Level 1 benchmarks on Linux infrastructure using Ansible and OpenSCAP. We will move beyond theory and implement a pipeline that actively rejects non-compliant configurations.

The "Schrems II" Headache and Data Sovereignty

Before touching the terminal, we must address the legal architecture. The Schrems II ruling effectively invalidated the Privacy Shield framework, making data transfers to US-owned cloud providers legally perilous for European companies handling sensitive data. This is where the physical location of your bits matters.

Pro Tip: Encryption at rest is useless if the hypervisor owner can be compelled by a foreign court to snapshot your memory. Hosting on sovereign Norwegian infrastructure—like CoolVDS—removes the jurisdiction risk entirely. We built our Oslo datacenter specifically to mitigate this legal exposure.

Automating Hardening with Ansible

We do not patch servers; we rebuild them or converge them to a desired state. Using Ansible, we can enforce CIS benchmarks across an entire fleet of NVMe storage instances in minutes. The goal is to disable unused filesystems, harden SSH, and restrict network access by default.

Here is a practical Ansible task list targeting an Ubuntu 22.04 LTS server (the standard production workhorse as of April 2024). This snippet enforces SSH hardening:

- name: Secure SSH configuration (CIS 5.2)
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol is set to 2
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present

    - name: Disable SSH Root Login
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^PermitRootLogin'
        line: 'PermitRootLogin no'
        state: present
        notify: Restart SSH

    - name: Ensure SSH MaxAuthTries is set to 4 or less
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^MaxAuthTries'
        line: 'MaxAuthTries 4'
        state: present

  handlers:
    - name: Restart SSH
      service:
        name: sshd
        state: restarted

This is basic but critical. However, compliance requires more deep-system changes. You must also disable unused filesystems like CramFS or SquashFS to prevent unauthorized mounting of storage.

- name: Disable unused filesystems (CIS 1.1.1)
  community.general.modprobe:
    name: "{{ item }}"
    state: absent
    persistent: present
  loop:
    - cramfs
    - freevxfs
    - jffs2
    - hfs
    - hfsplus
    - squashfs

Continuous Verification with OpenSCAP

Applying configuration is half the battle; proving it is the other. OpenSCAP is the industry standard for verifying configuration against XCCDF profiles. It is lightweight, open-source, and integrates perfectly into a CI/CD pipeline.

First, install the necessary tools on your VPS Norway instance:

sudo apt-get update
sudo apt-get install libopenscap8 scap-security-guide -y

Once installed, you can run a scan against the CIS Level 1 profile. This command generates an HTML report that you can hand directly to an auditor or your DPO (Data Protection Officer).

oscap xccdf eval \
 --profile xccdf_org.ssgproject.content_profile_cis_level1_server \
 --results scan-results.xml \
 --report scan-report.html \
 /usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml

Automating the Report

Running this manually is tedious. Below is a bash script wrapper that runs the scan, checks for failures, and only alerts you if the compliance score drops below a threshold. This is perfect for a nightly cron job on a CoolVDS management node.

#!/bin/bash
# Security Compliance Scanner Wrapper
# Date: 2024-04-19

PROFILE="xccdf_org.ssgproject.content_profile_cis_level1_server"
CONTENT="/usr/share/xml/scap/ssg/content/ssg-ubuntu2204-ds.xml"
REPORT="/var/www/html/security/report-$(date +%F).html"
THRESHOLD=90

echo "Starting OpenSCAP Scan..."

# Run the scan
oscap xccdf eval --profile $PROFILE --report $REPORT $CONTENT
SCORE=$(grep -oP '(?<=score>)[^<]+' $REPORT | head -1)

# Convert to integer for comparison
INT_SCORE=${SCORE%.*}

if [ $INT_SCORE -lt $THRESHOLD ]; then
    echo "CRITICAL: Compliance score $SCORE is below threshold $THRESHOLD."
    # Insert your mail command or Slack webhook curl here
    # mail -s "Security Compliance FAIL" admin@example.com < $REPORT
else
    echo "PASS: System compliance is $SCORE."
fi

Network Level Defense: The Forgotten Layer

Host-based hardening is futile if your network edge is porous. While CoolVDS provides robust ddos protection at the datacenter level, you must configure local firewalls to limit rate. Do not rely solely on security groups if you are managing raw KVM instances; use nftables or ufw locally.

Here is a strict ufw configuration setup. Note the limiting of SSH to prevent brute-force attempts before they even hit the auth log.

ufw default deny incoming
ufw default allow outgoing
ufw limit ssh/tcp
ufw allow 443/tcp
ufw allow 80/tcp
ufw enable

Why Infrastructure Choice Dictates Compliance Cost

There is a hidden cost to compliance: performance overhead. Enabling full audit logging (auditd) and running real-time intrusion detection systems (HIDS) like OSSEC consumes I/O cycles. On shared hosting or oversold VPS providers, this "security tax" can degrade application performance by 15-20%.

We designed the CoolVDS platform with this specifically in mind. By using KVM virtualization with dedicated resource allocation and high-throughput NVMe storage, the I/O overhead of compliance logging is negligible. You do not have to choose between a secure server and a fast server.

Conclusion: The Zero-Trust Mindset

In April 2024, the "secure perimeter" is a myth. The only valid strategy is defense in depth, where every single node is hardened, audited, and monitored as if it were directly exposed to the internet. By combining Ansible for consistent configuration and OpenSCAP for continuous verification, you create a self-healing compliance loop that satisfies both the technical requirements of CIS and the legal requirements of the GDPR.

Compliance is hard, but bad infrastructure makes it harder. Stop fighting against noisy neighbors and unpredictable latency.

Ready to audit your stack? Deploy a compliant-ready Debian or Ubuntu instance on CoolVDS today and see the difference dedicated NVMe makes to your scan times.