Linux security for the Cyber Assessment Framework and the Bill

The short answer

Neither the Cyber Security and Resilience Bill (CSRB) nor the Cyber Assessment Framework (CAF) sets rules for Linux. The CAF describes outcomes and doesn't name operating systems, while the Bill's duties refer to appropriate and proportionate measures. So there's no such thing as a "CAF-compliant Linux build". You need to show that your Linux estate supports the relevant outcomes.

This page maps common Linux practices to CAF 4.0. The practices are our examples, not requirements, so adapt them to your systems and risk.

Mapping Linux practice to CAF outcomes

CAF outcome	What it asks	Linux examples
A3.a Asset management	Know your assets	An inventory of hosts, distributions, kernel versions and packages, including containers and appliances
A4.b Secure software	Secure, supported software	Signed packages from trusted repositories, an inventory of third-party components, support agreements where needed
B2.a Identity and authentication	Verify and authorise access	Central identity, SSH keys or certificates rather than passwords, multi-factor authentication for remote access
B2.c Privileged users	Manage privileged access	Named accounts with sudo, no direct root SSH, logged administrative sessions
B4.b Secure configuration	Consistent, minimal, documented builds	A hardened baseline, disabled unused services, configuration as code, drift checks
B4.c Secure management	Administer from trusted devices	Bastion hosts or privileged access workstations, restricted management networks
B4.d Vulnerability management	Track and fix known vulnerabilities	Tracked security advisories, a plan for end-of-life distributions, scanning plus independent testing
B5.c Backups	Resilient, tested backups	Offline or immutable copies, tested restores, rebuildable hosts
C1.a Logging sources	Right data for monitoring	auditd and system logs for authentication, privilege and key file changes
C1.b Securing logs	Protect log data	Forward logs off the host, restrict access, retain them for an agreed period
C2.a Threat hunting	Documented hunts	Hunts for unusual cron jobs, new SSH keys, persistence through systemd, unexpected outbound connections

Building a baseline you can defend

B4.b's "achieved" column asks that all platforms conform to your secure defined baseline, or to a latest known good configuration, and that you regularly check they still do.

Pick a published benchmark as a starting point. CIS Benchmarks cover major distributions, including Ubuntu. They're widely used and give you a documented reference. For Ubuntu, Canonical's Ubuntu Security Guide automates hardening and auditing against them, though it requires Ubuntu Pro. Distribution vendors and open-source tools offer similar options.

Record your exceptions. A benchmark isn't a CAF requirement. If you turn off a setting, write down why and what compensates. That reasoning is often more persuasive than a high benchmark score.

Keep it minimal. Remove unused packages and services, because each one adds patching work and attack surface. Use mandatory access control such as SELinux or AppArmor where your distribution supports it.

Deal with shared accounts. The CAF expects generic, default and built-in accounts to be removed or disabled, or their credentials changed where that isn't possible, and service accounts to be protected. On Linux, check service accounts, application accounts with shells, and default appliance credentials.

Automate drift checks. Configuration management tools and file integrity monitoring help you prove systems still match the baseline. The CAF asks for regular review and validation, not a one-time build.

Common gaps on Linux estates

• End-of-life distributions. Under B4.d, not mitigating unsupported systems, or not pursuing their replacement, points to "not achieved". Know every system's end-of-support date.
• Appliances and embedded Linux. Firewalls, storage devices and OT equipment often run Linux that your normal tools can't see or patch. Cover these in supplier conversations.
• Containers. Base images need the same attention to provenance and vulnerabilities as hosts. Check images in use, not only the build pipeline.
• Logs stored only locally. An attacker with root can alter them. Forwarding them elsewhere helps protect them.
• Too much sudo. Broad rules such as ALL=(ALL) NOPASSWD: ALL undermine privileged access control. Review them as part of your access reviews.

Preparing evidence for an assessment

For each mapped outcome, keep something you can show:

• the baseline and its exceptions
• drift reports over time
• patch and advisory records, including exposure of externally facing hosts
• privileged access reviews
• a sample of logs in your central platform, and alerts generated from them
• third-party test results

Then bring it into your wider CAF self-assessment. Linux will only be part of the score for any outcome that also covers Windows, network and cloud systems.

Does this differ for NIS2?

NIS2, the EU's rules, also avoids naming operating systems. Good Linux hygiene helps with both regimes, but the legal tests differ. See does NIS2 apply to UK companies?

Sources

• NCSC: Cyber Assessment Framework v4.0 (PDF)
• CIS Benchmarks: Ubuntu Linux
• Ubuntu: CIS benchmark support