System Hardening & Security Baselines

Operating systems and applications ship with default configurations optimised for compatibility and usability – not security. Windows Server enables numerous services by default that are not required in most environments. Linux systems come with open ports, insecure SSH default configurations, and unnecessary packages. Cloud resources are frequently provisioned with public access and minimal access controls.

System hardening refers to the systematic reduction of the attack surface: unnecessary services are disabled, insecure protocols switched off, restrictive file system permissions set, audit logging activated, and security features enabled that are inactive by default. The result is a system with only the capabilities needed for its function – and therefore a significantly smaller attack surface.

Recognised reference frameworks structure this work: CIS Benchmarks (Center for Internet Security) provide platform-specific, community-validated configuration recommendations for Windows Server, Linux, macOS, containers, and cloud services. DISA STIGs (Defense Information Systems Agency Security Technical Implementation Guides) are US government standards and are particularly relevant in regulated and high-security environments. BSI SiSyP addresses specific German government requirements.

We begin with a hardening assessment: your existing systems are measured against a relevant CIS Benchmark and a compliance score is established. Typically, unhardened systems achieve 20–40% of CIS requirements; after our hardening project, 80–95% is the target. The assessment simultaneously reveals which deviations represent the greatest risk and which need to be adapted for your specific environment.

Not every CIS recommendation is directly applicable to every environment. Some settings that make sense in a dedicated server role can cause service disruptions in another. We review each recommendation for applicability and document justified exceptions – because blind CIS compliance without understanding the context is counterproductive. The result is an environment-specific baseline, not a generic template.

Implementation is carried out using Infrastructure-as-Code approaches: Ansible playbooks, PowerShell DSC, or GPOs that declaratively describe the hardening configuration and apply it reproducibly to all systems. This ensures new systems automatically receive the baseline and no manual errors arise. At the same time, the configuration is versioned, traceable, and rollback-capable if needed.

System hardening is not a one-off project but an ongoing process. Configurations drift: administrators change settings for debugging, applications require specific ports, updates change configuration defaults, new systems are provisioned without a hardening process. Without continuous monitoring, the baseline quickly loses its effectiveness.

We implement continuous compliance checks that detect and report hardening drift. Tools such as OpenSCAP, CIS-CAT, or Microsoft Defender for Cloud regularly verify the compliance score of each system and generate reports that make deviations from the defined baseline visible. Critical deviations are automatically ticketed and escalated for remediation.

For cloud environments (Azure, AWS, GCP), Cloud Security Posture Management (CSPM) tools such as Microsoft Defender for Cloud, AWS Security Hub, or GCP Security Command Center provide continuous hardening monitoring with immediate alerts on insecure configuration changes. This integration is particularly important in dynamic cloud environments where resources are created by script and configurations can easily be changed accidentally.

Windows Server and Windows Client present different hardening requirements. For Windows Server, CIS Benchmarks recommend disabling unnecessary roles and features (SMBv1, NetBIOS over TCP/IP, LLMNR, WPAD), restrictive configuration of Windows Defender Firewall, activation of audit policies with clearly defined event categories, and enforcement of strong credential policies combined with Protected Users and Authentication Policy Silos. For Windows clients, Windows Defender Application Control (WDAC) or AppLocker is additionally relevant – mechanisms that block the execution of unauthorised software at the OS level.

Linux operating system hardening covers the system itself as well as all installed services. Core measures: reducing installed packages to the operational minimum, hardening the SSH daemon (PermitRootLogin no, PasswordAuthentication no, AllowTcpForwarding no, MaxAuthTries 3), configuring Mandatory Access Controls via SELinux (RHEL/CentOS) or AppArmor (Debian/Ubuntu), activating kernel hardening parameters via sysctl (enable ASLR, disable core dumps, disable IP forwarding), and configuring the packet filter firewall via nftables or firewalld. For production systems we additionally recommend enabling auditd for complete system activity logging.

Cloud workloads on Azure, AWS, and GCP require a distinct hardening perspective: virtual machines do not automatically inherit the security configuration of the cloud provider. On-guest operating system hardening (CIS Benchmarks for the respective distribution) is required alongside cloud-level configuration: security groups, network ACLs, IMDSv2 (AWS Instance Metadata Service), Azure Policy, and CSPM integration. We combine both perspectives and ensure that neither the OS configuration nor the cloud layer contains gaps.

Operating system hardening is explicitly required by several regulatory frameworks. ISO 27001:2022 Annex A.8.9 (Configuration Management) requires that configurations of hardware, software, and services are documented, implemented, monitored, and regularly reviewed. NIS2 Article 21 mandates hardening measures as part of the minimum technical security requirements for essential and important entities. The BSI IT-Grundschutz Compendium contains platform-specific building blocks – SYS.1.2 (Windows Server), SYS.2.2 (Windows Client), and SYS.1.3 (Linux Server) – with detailed hardening requirements.

NIST Special Publication 800-70 defines the National Checklist Program (NCP) and provides hardening checklists for all common operating systems. CIS Benchmarks are recognised as NCP-compliant and are therefore equally applicable in regulated environments in Germany and across Europe. For KRITIS operators, alignment with BSI IT-Grundschutz is frequently mandatory; CIS Benchmarks can be used as supplementary technical implementation guidance without undermining the Grundschutz evidence.

Blackfort documents all hardening measures in audit-ready form: for each measure the hardening concept contains the normative reference (CIS Benchmark ID, BSI building block reference, ISO control), the state before hardening, the implemented configuration, and the verification result after implementation. This document forms the reliable basis for subsequent audits under ISO 27001, NIS2, or BSI IT-Grundschutz.