Security hardening: what it is, with a checklist per layer

Security hardening: checklist per layer

Security hardening means that you set up a system so that there is less to attack. You turn off what you do not use, you grant as few rights as possible and you record what happens. Cloud security hardening is the same, applied to servers, containers and services in the cloud. The settings of your cloud environment itself also belong to it.

This checklist goes through the layers, from the server to the user. Each point is an action you can check. The points follow common baselines such as the CIS Benchmarks. It is a tool, not a certification. At the bottom, you read which measures Noveu applies.

How to use this checklist

1. Choose one system or service at a time.
2. Go through the layers below and note per point: done, not applicable or still open.
3. For every point that is done, record how you check it. The auditor always asks for the evidence.
4. Schedule the open points, with an owner and a date.

The layers at a glance

• Network edge: DDoS protection, WAF and rate limiting.
• Network: segmentation, firewall and zero trust.
• Server: minimal installation, updates and kernel settings.
• Containers: no root, read-only and limits.
• Application and API: secure development and access control.
• Data: encryption, backups and key management.
• Identity: MFA, rights and password policy.
• Monitoring: logging and alerts.

Server and operating system

Checklist for Linux servers

• Install only the packages you need and remove the rest.
• Turn on automatic security updates, or schedule them at fixed times.
• Put SELinux or AppArmor in enforcing mode.
• Set the kernel parameters below.
• Turn on UEFI Secure Boot where the hardware supports it.
• Encrypt data volumes, for example with LUKS.
• Allow SSH only with keys, not with passwords and not as root.

Kernel settings (sysctl)

# /etc/sysctl.d/99-security.conf

# Network
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1
net.ipv4.icmp_echo_ignore_broadcasts = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0

# Kernel
kernel.randomize_va_space = 2
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

Containers and Kubernetes

Checklist for containers

• Run containers as a normal user, not as root.
• Make the file system of the container read-only where possible.
• Give each container a limit for CPU and memory.
• Scan images for vulnerabilities at every build.
• Restrict the traffic between pods with network policies.
• Keep an eye on the behaviour while running, for example with Falco.

Example: Pod Security Standards (restricted)

apiVersion: v1
kind: Pod
metadata:
  name: secure-pod
spec:
  securityContext:
    runAsNonRoot: true
    runAsUser: 1000
    seccompProfile:
      type: RuntimeDefault
  containers:
  - name: app
    securityContext:
      allowPrivilegeEscalation: false
      readOnlyRootFilesystem: true
      capabilities:
        drop:
          - ALL

Network

Checklist for the network

• Divide the network into zones: edge, application, data and management.
• Deny everything by default and only explicitly allow what is needed.
• Let management, such as SSH, run only via a management zone or jump host.
• Put a WAF and rate limiting in front of services that are on the internet.

Zones and access

Zone	Content	Access from
Edge (DMZ)	Load balancers, WAF	Internet
Application	Application servers	Only the edge
Data	Databases, storage	Only the application zone
Management	Monitoring, logging	Only jump hosts

Zero trust in brief

1. Check every request, also from inside the network.
2. Give every user and service as few rights as possible.
3. Assume that someone is already inside: segment and monitor.

Application and API

Checklist for secure development

• Scan every commit for secrets, for example with Gitleaks.
• Run static analysis (SAST) at every build.
• Scan container images, for example with Trivy, before you deploy.
• Test the running application with DAST, for example with OWASP ZAP.

Checklist for APIs

• Authenticate with OAuth 2.0 or OIDC.
• Authorise with roles and scopes.
• Set rate limiting per client and per endpoint.
• Validate input against a schema.
• Log requests so that you can find them again, without sensitive content.

Common vulnerabilities and what helps

Vulnerability (OWASP)	What helps
Injection	Parameterised queries, an ORM
Weak authentication	MFA, good session management
Exposed sensitive data	Encryption, masking
Broken access control	Roles, minimal rights
Misconfiguration	Fixed baselines, scanning
XSS	Output encoding, CSP
Vulnerable components	Scanning dependencies
Too little logging	Audit logs in the right places

Data and encryption

Checklist for data

• Encrypt traffic with TLS 1.2 or higher, preferably TLS 1.3, and turn on HSTS.
• Encrypt data at rest: volumes, databases and backups.
• Test restoring backups, not only making them.
• Keep keys separate from the data they protect.
• Record who can access the keys and replace them according to a fixed schedule.

Example: TLS configuration (nginx)

ssl_protocols TLSv1.3;
ssl_prefer_server_ciphers off;
ssl_session_timeout 1d;
ssl_session_cache shared:SSL:10m;
ssl_session_tickets off;
ssl_stapling on;
ssl_stapling_verify on;

# HSTS
add_header Strict-Transport-Security "max-age=63072000" always;

Identity and access

Checklist for accounts

• Make MFA mandatory, at least for administrator accounts.
• Choose passkeys or hardware keys (WebAuthn, FIDO2) over codes by text message.
• Where possible, let sign-in run via one central identity service (with OIDC), so that you revoke an account in one place.
• Give service accounts a certificate or a key that expires quickly.
• Require passwords of at least 14 characters and block after a few failed attempts.

Monitoring and logging

Checklist for logging

• Log sign-ins, changes in rights and administrative actions.
• Determine per type of log how long you keep it and record that.
• Send logs to a place where an attacker cannot erase them.

Alerts you want at a minimum

Alert	Severity	What you do
Many failed sign-ins	Medium	Review, block the account if necessary
Someone gets more rights	High	Investigate immediately
Unusual access to data	High	Check with the user
Change in configuration	Low	Record in the audit trail
Malware found	Critical	Isolate the system

What cloud security hardening additionally requires

In the cloud, you manage not only your own servers, but also the environment around them. That layer is often forgotten.

• Put the administrator accounts of your cloud environment behind MFA and do not use them for daily work.
• Check the default settings: public storage, open ports and roles that are too broad.
• Look at where your data and backups are physically located and under which law your provider falls.
• Keep track of which sub-processors and services can access your data.

That last point touches on sovereignty. Read what a sovereign cloud in the EU does differently from an EU region of an American provider.

Where Noveu stands

We record these measures publicly, in the data processing agreement and on the list of sub-processors:

• Your data and backups are stored in Germany, in a Hetzner data centre in Falkenstein. Backups are encrypted.
• External traffic goes over TLS 1.2 or higher, with HSTS.
• Signing in goes with one Noveu login via OpenID Connect, with TOTP and passkeys, optional for users.
• The API gateway does rate limiting and validates input.

How we approach security further, you read on the security page.