Systems hardening

It is the process of reducing the attack surface of a system through configuration: disabling unnecessary services and protocols, applying robust authentication policies, restricting privileges to the minimum necessary, enabling logs that allow incident investigation, separating management planes from production planes, and verifying everything against a recognised guide (CIS Benchmarks, DISA STIG or vendor equivalent). It is not patching vulnerabilities — that is patch management — nor installing antivirus. It is making sure that, even with patches up to date and EDR on top, the system does not expose weak, exploitable configurations.

We combine several by platform. As a baseline we use CIS Benchmarks (Center for Internet Security) because they cover the broadest catalogue and stay continuously updated. For defence, government and critical environments we add DISA STIG where the client requires it by contract. Microsoft Security Baselines for anything Microsoft 365 and Windows Server. Vendor recommendations for vSphere, NetApp, Cisco, F5, Palo Alto and similar. For cloud, the Well-Architected Framework (AWS/Azure/GCP) cross-referenced with CIS Cloud. The criterion: the strictest guide the business can absorb without breaking operations.

Because EDR and firewalls are reactive detection and containment layers. Hardening reduces the number and severity of paths an attacker can traverse before the EDR sees anything. Typical cases: SMBv1 enabled, NTLMv1 allowed, LM Hash stored, local passwords reused across hundreds of machines, RDP exposed without NLA, weak TLS configuration, S3 bucket permissions too broad, privileged accounts used for routine tasks. None of those is fixed by a patch nor automatically flagged by an EDR as active issue. And all of them are what an attacker exploits before touching anything that would trigger an alert.

Whatever the client uses. Operating systems: Windows Server 2016/2019/2022, Windows 10/11 client, Linux (RHEL, Ubuntu Server, Debian, SUSE, Amazon Linux). Virtualisation: VMware vSphere/ESXi, Hyper-V, Proxmox, Nutanix. Containers: Docker, Kubernetes (kubeadm, EKS, AKS, GKE, Rancher), containerd/CRI-O runtime. Cloud: AWS, Azure, GCP — account, IAM, network, storage, compute, management. Productivity: Microsoft 365, Google Workspace. Databases: SQL Server, Oracle, PostgreSQL, MySQL, MongoDB, Redis. Network: Cisco IOS/NX-OS, Juniper, Fortinet, Palo Alto, F5, Aruba. Identity: Active Directory, Entra ID, Okta, Keycloak. If the client works with very vertical platforms, we assess them in the walkthrough.

It depends on scope. Hardening a fleet of 30-80 Windows Servers or equivalent: 3-6 weeks with 1-2 engineers, indicative cost €14-32k. Multi-platform project for a mid-sized organisation (servers + virtualisation + cloud + M365 + network): 8-16 weeks, 1-3 engineers, €40-110k. Before quoting we run a technical walkthrough to understand the real inventory, operational dependencies and appetite for disruptive change. Without it, any figure is a guess. Subsequent operation (drift monitoring, onboarding new systems, benchmark updates) is delivered as a monthly subscription.

That is the right question, and the reason the process always includes testing in a replica environment before touching production, scheduled maintenance window, documented rollback plan, and gradual rollout (canary deployment: 5% → 25% → 100% with validation windows). Every change is documented as code (Ansible, DSC, Terraform, scripts) so it is reproducible, auditable and reversible. Controls the business cannot absorb get documented as justified exceptions with deadline and compensating control; we do not apply controls dogmatically.

Yes, it degrades again — it is called drift — and that is why hardening is not a one-off project but a continuous practice. After the initial phase we deliver: configuration as code (idempotent, in a versioned repository), drift detection rules in SCAP/OpenSCAP, AWS Config, Azure Policy, GCP Forseti, Kubernetes Gatekeeper or whatever applies per platform, a compliance dashboard per system, operational alerts in the SIEM when a critical control changes. If continuous operation is contracted, we take over monitoring with monthly reporting cadence and quarterly client review.

ENS requires documented and verifiable security configuration (op.pl.2, op.pl.5, mp.s.2 mp.eq.4 among others) and hardening is the natural mechanism to deliver it. ISO 27001:2022 (A.8.9 Configuration management) explicitly covers secure configuration management. NIS2 art. 21.2.e requires cyber hygiene and secure configuration measures. DORA art. 9 + RTS on ICT management cover this under technical controls. The documentation package we deliver — baseline, evidence of application, exception management, review plan, drift monitoring — is designed to support external audit without additional client effort.

Whatever fits best. If you already have Ansible, Puppet, Chef, Terraform or DSC modules, we work on what is in place: we add new roles/modules, extend the current ones, integrate into your CI/CD. If there is nothing, we build it as a deliverable — preferably Ansible for operating systems and Terraform or Bicep/ARM for cloud — in the client's repository, with documentation, validation pipeline and training for the operations team. We do not impose tooling: we adapt to what the team will maintain without friction.

A 30-minute call to understand the approximate inventory (how many systems, what platforms, where they run), the reason (compliance, post-incident, modernisation, client requirement) and the appetite for disruptive change. If it fits, a 1-3 hour technical walkthrough with a sysadmin or platform engineer. From there we issue a firm proposal in 48-72 hours: scope, window, team, deliverables and fixed price. No commitments until signature. If we see the project should be split into phases or combined with vulnerability management, we will say so honestly.