Automating Security Compliance: From CIS Benchmarks to GDPR-Ready Infrastructure

If you are still manually editing /etc/ssh/sshd_config on your production servers in 2019, you have already lost the battle. I state this not to be alarmist, but because I have spent the last decade watching "secure" infrastructures crumble due to configuration drift.

We are nearly a year into the GDPR era. The Datatilsynet (Norwegian Data Protection Authority) is no longer sending warnings; they are preparing fines. For any System Architect or CTO operating in the Nordic market, the challenge is twofold: Technical Hardening and Legal Sovereignty.

This guide ignores the fluff. We are going to look at how to implement the Center for Internet Security (CIS) benchmarks automatically using Ansible, validate them with OpenSCAP, and why the underlying hardware location—specifically here in Norway—is the one variable you cannot patch via code.

The War Story: The "Gold Image" Fallacy

In 2017, I consulted for a fintech startup in Oslo. They had a "Gold Image" for their CentOS servers—a manually hardened VM template they cloned for every new deployment. It worked, until it didn't.

Six months later, a new vulnerability in Apache Struts appeared. Their Gold Image was static; their deployed fleet was drifting. Because they lacked a configuration management system enforcing security state, they had to manually patch 400 servers. They missed three. One of those three was the entry point for a breach that cost them a major partnership.

The Lesson: Compliance is not a checkbox; it is a continuous state. If it is not automated, it is effectively non-existent.

Phase 1: Automating Hardening with Ansible

We do not rely on manual checklists. We define infrastructure as code. Below is a practical example of how to enforce SSH hardening standards compliant with CIS Level 1 benchmarks using Ansible (compatible with version 2.7).

Do not just copy-paste. Understand that disabling root login and enforcing protocol 2 is the baseline, not the ceiling.

- name: Secure SSH Configuration (CIS Level 1)
  hosts: all
  become: yes
  tasks:
    - name: Ensure SSH Protocol 2 is set
      lineinfile:
        path: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
        notify: restart_sshd

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

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

  handlers:
    - name: restart_sshd
      service:
        name: sshd
        state: restarted

Pro Tip: When running this on CoolVDS instances, we recommend utilizing the private network interface for management traffic. Binding SSH strictly to the internal IP (ListenAddress 10.x.x.x) removes the attack surface from the public internet entirely.

Phase 2: Continuous Verification with OpenSCAP

Applying the config is half the job. Proving it is the other half. For this, we use the Open Security Content Automation Protocol (OpenSCAP). It allows us to scan a server against a specific profile (like PCI-DSS or CIS) and generate a report.

On a CentOS 7 system (common in enterprise environments today), you can install the scanner and the security guides easily:

Once installed, do not guess which profile to use. List them and select the one that matches your compliance requirements.

# List available profiles
oscap info /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

# Run a scan against the CIS Server Profile
oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_standard \
  --results /var/www/html/scan-report.xml \
  --report /var/www/html/scan-report.html \
  /usr/share/xml/scap/ssg/content/ssg-centos7-ds.xml

This command generates an HTML report showing exactly where you pass and fail. We script this to run weekly via Cron. If a SysAdmin manually changes a config and breaks compliance, OpenSCAP catches it.

The Physical Layer: Data Sovereignty & GDPR

You can have the most hardened iptables rules in the world, but if your VPS is hosted on a server physically located in a jurisdiction with invasive data laws, your compliance is theoretical at best. This is where the "Cloud" abstraction becomes dangerous.

Under GDPR, you are the Data Controller. You are responsible for where that data lives. Many budget providers silently shuffle VMs between datacenters in Frankfurt, London, or even across the Atlantic to balance load. This is a compliance nightmare.

Why Norway?

Norway occupies a unique sweet spot in 2019. We are EEA members, fully aligned with GDPR, yet outside the direct jurisdiction of some more aggressive surveillance apparatuses found elsewhere. Furthermore, the stability of the Norwegian power grid means we see uptime metrics that other regions struggle to match.

At CoolVDS, we treat data sovereignty as a feature, not a byproduct.

• Strict Residency: A VPS deployed in our Oslo datacenter stays in our Oslo datacenter. We do not migrate storage volumes across borders.
• Physical Security: Our facilities meet strict access control standards (ISO 27001 compliant procedures).
• Low Latency: Direct peering at NIX (Norwegian Internet Exchange) ensures that while your data is secure, it is also instantly accessible to your Nordic user base.

Putting It All Together

Security automation is not a luxury; it is the baseline for doing business in Europe today. By combining Ansible for configuration enforcement, OpenSCAP for audit verification, and a hosting partner that guarantees data sovereignty, you build a fortress.

Do not let your infrastructure be the reason you end up in a Datatilsynet report. Take control of your stack.

Ready to audit your setup? Deploy a fresh CentOS 7 instance on CoolVDS in under 55 seconds. Our NVMe storage ensures your OpenSCAP scans finish before you can even pour your coffee.