The "Excel Sheet" Compliance Strategy Is Dead

If your organization is still tracking server hardening using a shared spreadsheet named Server_Security_Final_v3.xlsx, you are already non-compliant. I say this not to be alarmist, but as a Technical Director who has sat across from auditors who asked for immutable logs and received blank stares in return. In the Norwegian market, where Datatilsynet (The Norwegian Data Protection Authority) does not view ignorance as a defense, reliance on manual configuration is a direct business risk.

The post-Schrems II reality has shifted the baseline. It is no longer enough to just secure the perimeter. You must prove, mathematically and programmatically, that your infrastructure adheres to strict standards like CIS Benchmarks or ISO 27001 constraints. And you need to do this while maintaining low latency to Oslo and keeping TCO reasonable.

Here is the hard truth: Compliance is code. If it isn't in a repo, it doesn't exist.

The Architecture of Automated Compliance

We are going to build a compliance pipeline that enforces the CIS (Center for Internet Security) Benchmark for Ubuntu 22.04 LTS (a standard sturdy choice for 2024 deployments). We will use OpenSCAP for scanning and Ansible for remediation. This is the exact stack we recommend for clients deploying on CoolVDS NVMe instances to ensure that the underlying high-performance hardware isn't compromised by a weak software layer.

1. The Baseline: Kernel Hardening

Before installing fancy tools, we must lock down the kernel. Most default VPS images—even the clean ones we provide at CoolVDS—are configured for compatibility, not paranoia. You need to change that.

Edit your /etc/sysctl.conf. We aren't just disabling IPv6; we are mitigating specific network attacks.

# /etc/sysctl.conf - Hardening Network Stack

# IP Spoofing protection
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Ignore ICMP broadcast requests
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Disable source packet routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Ignore send redirects
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Block SYN attacks
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_max_syn_backlog = 2048
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 5

# Log Martians
net.ipv4.conf.all.log_martians = 1

Apply these changes immediately without rebooting:

sysctl -p

Pro Tip: On a CoolVDS instance, because we utilize KVM virtualization, these kernel parameters affect your isolated kernel directly. On container-based hosting (like LXC/OpenVZ), you often cannot modify these flags because you share a kernel with the host. This is a critical distinction for compliance—true isolation requires KVM.

2. Automated Auditing with OpenSCAP

Don't guess if you are secure. Measure it. OpenSCAP is the industry standard for checking Linux systems against the Security Content Automation Protocol (SCAP).

First, install the toolset on your audit server:

apt-get install libopenscap8 scap-security-guide

Now, run a scan against the CIS Level 2 Server benchmark. Level 1 is for general use; Level 2 is for environments where security is paramount (e.g., handling Norwegian user data).

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

This command generates an HTML report showing exactly where you fail. Expect to see red. A lot of red. That is normal for a fresh deploy.

3. Remediation via Ansible

Never fix the findings manually. If you type a command into the terminal to fix a security hole, you have created a "Snowflake" server—unique and fragile. Use Ansible to enforce the state.

Here is a snippet from a remediation playbook that addresses SSH configuration, a common failure point in audits.

# ansible/roles/security/tasks/ssh_hardening.yml
---
- name: Ensure SSH protocol is set to 2
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^Protocol'
    line: 'Protocol 2'
    state: present

- name: Disable 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 or less
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^MaxAuthTries'
    line: 'MaxAuthTries 4'
    state: present
  notify: restart sshd

- name: Set SSH Idle Timeout Interval
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^ClientAliveInterval'
    line: 'ClientAliveInterval 300'
    state: present

- name: Set SSH Idle Timeout Count
  lineinfile:
    path: /etc/ssh/sshd_config
    regexp: '^ClientAliveCountMax'
    line: 'ClientAliveCountMax 0'
    state: present

The Immutable Logging Requirement

One specific requirement often cited by auditors is the integrity of logs. You need auditd configured to watch critical files. If a file changes, it gets logged. If the logs are tampered with, that must be detected.

Here is a configuration to watch the /etc/passwd file for write access:

# /etc/audit/rules.d/audit.rules

# Delete all existing rules
-D

# Buffer Size
-b 8192

# Failure Mode (2 = shutdown on failure, 1 = log)
-f 1

# Watch /etc/passwd
-w /etc/passwd -p wa -k identity
-w /etc/group -p wa -k identity
-w /etc/shadow -p wa -k identity
-w /etc/gshadow -p wa -k identity

Reload the audit daemon:

service auditd restart

Data Sovereignty and The "Cloud Act" Problem

We cannot discuss compliance in Norway without addressing the elephant in the room: Location.

You can harden your OS to military standards, but if that VM resides on a hyperscaler owned by a US entity, you are subject to the CLOUD Act. This creates a legal gray area for GDPR compliance, specifically regarding transfer mechanisms.

This is where infrastructure choice becomes a compliance tool. Hosting on CoolVDS means your data resides physically in Europe, on infrastructure owned by a European entity. There is no legal backdoor for foreign intelligence subpoenas. For a CTO, this simplifies the "Transfer Impact Assessment" (TIA) significantly.

Performance vs. Security: The Trade-off?

A common objection from dev teams is that security agents kill performance. "The antivirus makes the build slow."

In 2024, this is largely a resource allocation issue, not a software issue. Modern agents like Wazuh or Falco are lightweight, but they do consume I/O. This is why we standardized on NVMe storage for all CoolVDS tiers.

When your storage subsystem pushes 3GB/s, a background file integrity check doesn't register on the user's radar.

Conclusion: Sleep Better

Compliance is not about checking boxes; it is about resilience. By automating your hardening with Ansible and OpenSCAP, you remove human error from the equation. By choosing a sovereign infrastructure partner like CoolVDS, you remove geopolitical legal risk.

Don't wait for the audit letter to arrive. Spin up a compliant, hardened instance today. Test the latency from Oslo. Verify the NVMe throughput. Build your fortress on solid ground.

Next Step: Deploy a fresh Ubuntu 22.04 instance on CoolVDS and run the OpenSCAP scan provided above. See if you can get your compliance score to 95% within the first hour.