Automating Security Compliance: Surviving the Safe Harbor Fallout

The recent invalidation of the Safe Harbor agreement by the ECJ (European Court of Justice) has sent shockwaves through the IT departments of every Norwegian enterprise. If you are a CTO relying on US-owned cloud giants, you are currently operating in a legal grey area. The upcoming EU General Data Protection Regulation (GDPR), currently in its final trialogue negotiations, promises to tighten these screws even further.

But legal compliance isn't just about where your data sits—though data sovereignty is critical. It is about how you manage that data. As we move into 2016, the era of manual server hardening is dead. If you are still editing /etc/ssh/sshd_config by hand, you are already non-compliant. Human error is the single biggest threat to system integrity.

In this analysis, we will look at how to move from "security by policy" to "security by code" using Ansible and OpenSCAP, and why hosting on domestic infrastructure like CoolVDS is the pragmatic choice for mitigating regulatory risk.

The Myth of the "Secure" Cloud

We recently audited a client migrating from a generic VPS provider. They believed they were secure because they had a firewall. However, a junior sysadmin had temporarily flushed the iptables rules to debug a connection issue and forgot to restore them. The server was exposed for six days. In a compliance audit by Datatilsynet (The Norwegian Data Protection Authority), "I forgot" is not a valid defense.

To avoid this, infrastructure must be immutable and self-healing. We need to define the state of our infrastructure in code, not in a wiki document that nobody reads.

Step 1: Compliance as Code with Ansible

Configuration management tools like Puppet and Chef have been around, but Ansible (currently version 1.9) has emerged as the lightweight favorite for operations teams because it requires no agent. It uses SSH, which you already have.

Here is a pragmatic Ansible playbook that enforces SSH hardening standards. This ensures that no matter who deploys the server, Root login is disabled and Protocol 2 is enforced. This is the baseline requirement for any system handling PII (Personally Identifiable Information) under Norwegian law.

---
- hosts: secure_nodes
  vars:
    ssh_port: 22
  tasks:
    - name: Ensure SSH Protocol 2 is used
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: '^Protocol'
        line: 'Protocol 2'
        state: present
      notify: restart ssh

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

    - name: Disable Password Authentication (Keys Only)
      lineinfile:
        dest: /etc/ssh/sshd_config
        regexp: '^PasswordAuthentication'
        line: 'PasswordAuthentication no'
        state: present
      notify: restart ssh

  handlers:
    - name: restart ssh
      service: name=sshd state=restarted

Running this playbook takes seconds. Doing it manually across 50 servers takes hours and guarantees mistakes.

Step 2: Automated Auditing with OpenSCAP

Configuring the server is half the battle. Proving it is secure is the other half. For this, we use the OpenSCAP scanner. It compares your system against the SCAP (Security Content Automation Protocol) standards, such as the PCI-DSS profile or the RHEL7 Security Technical Implementation Guide (STIG).

On a CentOS 7 instance (standard on CoolVDS), you can install the scanner easily:

Once installed, you can run a compliance scan against the PCI-DSS profile to see if your e-commerce setup is actually secure:

oscap xccdf eval \
  --profile xccdf_org.ssgproject.content_profile_pci-dss \
  --results /tmp/pci-dss-results.xml \
  --report /tmp/pci-dss-report.html \
  /usr/share/xml/scap/ssg/content/ssg-centos7-xccdf.xml

Pro Tip: Do not ignore the "fail" results. OpenSCAP is pedantic. It will flag you if /tmp is not on a separate partition. On a CoolVDS KVM instance, you can easily partition your virtual disk to meet this requirement without re-installing the OS.

Step 3: Network Hardening & Encryption

With the POODLE vulnerability behind us, SSLv3 must be banished. If you are running Nginx, your configuration must explicitly exclude old protocols. Furthermore, with the rise of HTTP/2 (released earlier this year), optimizing your cipher suites is mandatory for both security and performance.

A compliant nginx.conf snippet for 2015:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; # Dropping SSLv3
ssl_prefer_server_ciphers on;
ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';
ssl_session_cache shared:SSL:10m;
add_header Strict-Transport-Security "max-age=63072000; includeSubdomains; preload";

The Data Sovereignty Advantage

Technical hardening is useless if the legal jurisdiction undermines your data privacy. The US Patriot Act allows US agencies to access data stored by US companies, regardless of where the server is physically located. This is the core conflict that destroyed Safe Harbor.

For Norwegian businesses, the safest path is domestic hosting. When you deploy on CoolVDS, your data resides in Oslo. It is governed by the Norwegian Personal Data Act (Personopplysningsloven). There is no third-party data transfer to the US.

Furthermore, local hosting offers superior technical metrics:

Performance is a Security Feature

Availability is a key pillar of the CIA (Confidentiality, Integrity, Availability) triad. DDoS attacks are becoming more frequent. By utilizing CoolVDS's local peering at NIX (Norwegian Internet Exchange), we reduce the network hops where traffic can be intercepted or bottlenecked.

We also utilize KVM (Kernel-based Virtual Machine) virtualization exclusively. Unlike OpenVZ containers used by budget providers, KVM offers true hardware isolation. A kernel panic in a neighbor's VM cannot crash your compliance logs. For high-I/O workloads, such as database encryption, we offer access to early-adoption NVMe storage tiers, which drastically reduce the overhead caused by on-disk encryption.

Conclusion

The regulatory landscape in Europe is shifting. The "wait and see" approach to data location is no longer viable for a CTO. You must ensure your data stays within legal boundaries and that your servers are hardened against an increasingly hostile internet.

Automate your security with Ansible. Audit it with OpenSCAP. And host it where the law protects you.

Secure your infrastructure today. Deploy a KVM instance on CoolVDS in Oslo and gain full control over your data sovereignty.