Royal Army College

Lesson Overview

A system can be hosted well, run in well-built containers, patched, and backed up, and still be wide open, because how a system is configured, the settings it runs with, the defaults left in place, the doors left open, is a separate matter from whether it is up to date, and a large share of real compromises come not from unpatched flaws but from systems that were simply set up insecurely. This lesson is about configuration and hardening: setting up systems so they are secure by their settings, closing the doors that need not be open, changing the dangerous defaults, and reducing each system to the minimum it needs to do its job. Where patching (Lesson 04 and CIS 201) fixes the flaws in software, hardening fixes the flaws in how the software is set up, and the two are different defences against different gaps, both essential. For those who help administer a small, self-hosted estate, hardening is among the most valuable disciplines, because it closes a category of risk that updates alone never touch.

The governing idea is that a system is only as secure as its configuration, and the safe default is to close what you do not need. Software often arrives configured for convenience or generality rather than security, with default passwords, open services, broad permissions, and features enabled that a given deployment does not need, and every one of those is a door an attacker can try. Hardening is the disciplined work of going through a system and closing those doors: changing default credentials, turning off what is not needed, restricting access to the minimum, and choosing the secure setting wherever there is a choice. The principle that organises it is minimisation, the same principle that ran through the comsec course, applied to systems: the smaller the system's exposure, the fewer features, services, accounts, and permissions it carries, the less there is to attack, so a hardened system is a reduced system, stripped to what it needs and no more. The member who hardens by this principle closes most of the configuration gaps attackers exploit; one who leaves systems at their convenient defaults leaves those doors open.

This is the knowledge layer; the practice of configuring and hardening real systems is done under those who administer the estate, with elevated access following appointment (Lesson 10). It rests on the recognised hardening foundations, the secure-configuration controls that are consistently among the most effective, and is wholly defensive. Read this to understand hardening; the practice comes under guidance.

By the end you will be able to explain why configuration is a distinct and major source of risk, change dangerous defaults and close unneeded doors, apply minimisation and least privilege to a system's setup, use secure defaults and known-good configurations, and understand hardening as an ongoing discipline.

Key Terms

Configuration: the settings a system runs with, which determine much of its security independently of whether its software is up to date.
Hardening: the disciplined work of configuring a system to be secure, closing unneeded doors, changing dangerous defaults, and reducing exposure.
Secure default: a setting chosen for safety rather than convenience; "secure by default" means a system is safe in its initial state, not only after extra work.
Default credentials: the username and password a system ships with, which are publicly known and must be changed before the system is exposed.
Attack surface: the sum of a system's exposed features, services, ports, accounts, and permissions, all the ways it could be attacked; hardening reduces it.
Minimisation: the principle of reducing a system to the minimum it needs (features, services, accounts, access), so there is less to attack.
Least privilege: giving each account, service, and component only the access it needs, so a compromise yields as little as possible (from CIS 220).
Open port / service: a way into a system left listening and reachable; unneeded open ports and services are closed in hardening.
Baseline (known-good configuration): a defined, secure standard configuration for a kind of system, against which deployments are set up and checked.
Configuration drift: the gradual divergence of a system's configuration from its secure baseline over time, which hardening discipline detects and corrects.

Why configuration is a distinct, major risk

It is tempting, once a system is hosted, containerised, patched, and backed up, to think it is secure, but this misses a whole category of risk: how the system is configured. Patching fixes flaws in the software itself; configuration is about how that software is set up to run, the settings, the defaults, the doors, and a system can be perfectly patched and still be wide open because it was configured insecurely. The two are genuinely separate: an attacker who finds no unpatched flaw may simply walk through a default password, an open service, or an over-broad permission that the configuration left in place. Real-world compromises are full of systems that fell not to clever exploits of software flaws but to insecure configuration, the default credential never changed, the service exposed that should have been closed, the permission left far too broad, which is why hardening sits alongside patching as an essential, distinct defence.

The reason configuration is so often the weak point is that software frequently arrives configured for convenience and generality, not for security. To work out of the box for as many users as possible, software often ships with permissive defaults: default usernames and passwords (publicly known), services and features enabled that many deployments do not need, broad permissions, and settings chosen to make the software easy to start rather than safe to expose. These convenient defaults are doors left open, and they are open on every freshly-installed system until someone closes them. An attacker scanning for systems left at their defaults, default-credentialled, broadly-exposed, finds a steady supply, because so many systems are deployed and never hardened, left exactly as they arrived. The gap between how software ships and how it should be configured to be safe is the gap hardening fills.

This makes hardening one of the highest-value disciplines for those who run systems, because it closes a large, common, and entirely preventable category of risk that updates never touch. A member who patches diligently but leaves systems at their convenient defaults has secured one category of gap and left another wide open; one who also hardens, closing the doors and changing the defaults, secures both. For a small, self-hosted Principality, where the members who deploy systems are also the ones who must secure them, the discipline of hardening every system as it is set up, rather than leaving it at its shipped defaults, is a direct and major contribution to the estate's security.

Changing defaults and closing doors

The most immediate hardening work is changing dangerous defaults and closing what need not be open, and a few items recur on every system. The first and most urgent is default credentials: many systems ship with a known default username and password, which are public knowledge, so a system exposed with its default credentials unchanged is effectively unlocked to anyone who knows them, which is everyone. Changing default credentials to strong, unique ones (the passphrase and secrets discipline of CIS 201 and CIS 220) before a system is exposed is the single most urgent hardening step, because an unchanged default credential is the commonest and easiest way in there is.

The second is closing unneeded open ports and services. Software often runs services and listens on network ports that a given deployment does not need, and every open, reachable service is a way in that an attacker can probe and attack. Hardening closes or disables the services and ports the system does not need for its job, so that only what is genuinely required is exposed, which directly shrinks the attack surface, the sum of ways the system could be attacked. A system exposing only the one service it must, with everything else closed, presents an attacker far less to work with than one running a dozen services it never uses.

The third is removing or disabling unneeded features, software, and accounts. Beyond ports and services, systems often carry sample content, unused features, extra software, and default or leftover accounts, each of which is potential attack surface. Hardening strips these away: removing software and features the system does not need, deleting or disabling default and unused accounts, and clearing sample or test content, so the system carries only what it requires. This is minimisation in action, and it is the organising principle: every feature, service, account, and permission a system does not need is removed, because what is not there cannot be attacked, which makes a hardened system a reduced one. Changing defaults, closing ports, and stripping the unneeded together close the great majority of the configuration doors attackers exploit.

   HARDENING: CLOSE WHAT YOU DON'T NEED  (minimisation)

   CHANGE DEFAULT CREDENTIALS   the #1 urgent step: shipped default
                                usernames/passwords are PUBLIC; an unchanged
                                default credential is an unlocked door
   CLOSE UNNEEDED PORTS/SERVICES every open, reachable service is a way in;
                                expose ONLY what the job requires
   STRIP THE UNNEEDED           remove unused features, software, sample
                                content, and default/leftover accounts
   LEAST PRIVILEGE              each account/service/component gets ONLY the
                                access it needs (a compromise yields little)
   SECURE DEFAULTS              wherever there's a choice, pick the SAFE
                                setting, not the convenient one

   The principle: every feature/service/account/permission you DON'T need
   is removed, because what isn't there can't be attacked. A hardened
   system is a REDUCED system.

Least privilege and secure defaults

Two further principles complete the hardening discipline. Least privilege, the access principle of CIS 220, applies directly to configuration: each account, service, and component is given only the access it needs to do its job, and no more, so that a compromise of any one yields the attacker as little as possible. A service that runs with broad, unnecessary permissions hands an attacker who compromises it those broad permissions; the same service run with only the minimal access it needs limits the damage of its compromise to that minimum. So hardening configures every component to the least privilege that lets it work: the database account that only the application needs, restricted to that application; the service that need not run as a powerful user, run as a limited one; the access that can be narrowed, narrowed. Least privilege in configuration ensures that even when something is compromised, the blast radius is small.

The complementary principle is secure defaults: wherever a configuration offers a choice between a convenient setting and a safe one, the safe one is chosen, and a system is set up to be secure by default, safe in its configured state rather than only after extra work. This is partly a matter of the administrator choosing safe settings, and partly of preferring software and configurations that are themselves secure by default, that ship safe rather than ship open. The ideal, increasingly the standard, is "secure by default": systems whose initial configuration is the safe one, so that safety is the starting point and convenience the exception that must be deliberately and knowingly enabled, rather than the reverse. Where a system is not secure by default, the administrator makes it so by hardening; where it is, the work is lighter, which is one reason to prefer secure-by-default software.

To make hardening consistent rather than ad hoc, mature practice uses a baseline, a defined, secure standard configuration for each kind of system, against which deployments are set up and checked. A baseline turns hardening from a thing each administrator does from memory, inconsistently, into a known-good standard applied uniformly, so every system of a kind is configured to the same secure state, and deviations are visible. The baseline also gives a reference against which to detect configuration drift, the gradual divergence of a system's settings from its secure baseline over time, as changes accumulate, which can quietly re-open doors hardening closed. For a small force, even a simple, written baseline, "this is how we securely configure this kind of system", raises the whole estate's configuration security and makes it checkable, which is why hardening to a baseline is better than hardening from memory.

Hardening as an ongoing discipline

A final and important point: hardening is not a one-time act at deployment but an ongoing discipline, because a system's configuration, like its software, can drift and degrade over time and must be maintained, not just set once and forgotten. After a system is hardened at deployment, changes accumulate, a setting altered for a quick fix and never reverted, a service enabled for a task and left on, a permission broadened and not narrowed again, and over time the system drifts from its hardened state back toward openness, the configuration drift the baseline exists to catch. So hardening continues through a system's life: configurations are reviewed against the baseline, drift is detected and corrected, and changes are made with security in mind rather than only convenience. A system hardened at birth and never maintained slowly re-opens its doors; one whose configuration is kept to its baseline stays hardened.

This connects hardening to the keeping-running discipline of Lesson 04 and to the documentation and automation of the next lesson. Maintaining configuration is part of keeping systems running well, alongside patching; and the documentation and automation of Lesson 09 are much of what makes consistent, drift-resistant configuration achievable for a small team, because a configuration that is documented and applied automatically is far more consistent and far less prone to drift than one hand-set and remembered. The member should hold hardening, then, not as a checklist done once but as a standing discipline: set systems up secure, to a baseline, by minimisation and least privilege and secure defaults; and keep them that way, reviewing against the baseline and correcting drift, over their whole life. Done so, hardening closes, and keeps closed, the large category of risk that insecure configuration represents, which is among the most valuable things those who run a small force's systems can do.

In Practice: Two Systems, One Hardened

A member of the Royal Kaharagian Army learning to support the Principality's systems compares two deployments of the same software, one left at its convenient defaults and one hardened, and the difference in their security is stark, though neither has an unpatched flaw. The lesson is that patching alone is not security, and that configuration is a distinct, decisive defence.

The un-hardened system was deployed and left as it arrived: its default credentials unchanged and publicly known, several services and ports it does not need left open and reachable, sample content and default accounts still present, and its components running with broad permissions for convenience. It is fully patched, but it is wide open: an attacker needs no clever exploit, only to try the public default password, probe the unneeded open services, or use the over-broad permissions, any of which the convenient configuration left available. It is a collection of open doors, secured against software flaws and defenceless against the configuration gaps that account for so many real compromises.

The hardened system runs the same patched software but was configured securely at deployment, to a baseline. Its default credentials were changed first of all, to strong unique ones; the services and ports it does not need were closed, so it exposes only the one service its job requires, shrinking its attack surface; the unused features, software, sample content, and default accounts were stripped away (minimisation); each component runs with least privilege, only the access it needs, so a compromise would yield little; and where settings offered a choice, the secure default was chosen. And because hardening is ongoing, the member sees that its configuration is reviewed against the baseline and drift corrected over time, so it stays hardened rather than slowly re-opening. An attacker finds, on this system, almost nothing to work with: no default credential, few open doors, minimal exposure, narrow permissions. Same software, same patches, opposite security, made entirely by configuration. That difference is what hardening is, and why those who run a small force's systems must harden every one.

Check Your Understanding

Explain why configuration is a distinct, major source of risk separate from patching, and why software so often ships configured for convenience rather than security. Why is hardening one of the highest-value disciplines for those who run systems?
Describe the immediate hardening work, changing default credentials (the most urgent step, and why), closing unneeded ports and services, and stripping unneeded features, software, and accounts, and how this applies the principle of minimisation to shrink the attack surface.
Explain least privilege and secure defaults in configuration, the value of a baseline (known-good configuration), and why hardening is an ongoing discipline that must detect and correct configuration drift over a system's life.

Reflection (write a short paragraph): This lesson argues that a system can be perfectly patched and still wide open because it was configured insecurely, and that many real compromises come from default passwords, open services, and over-broad permissions rather than from clever exploits. Why might a busy administrator deploy a system and leave it at its convenient defaults, and what does that leave open? Then consider the principle of minimisation, that a hardened system is a reduced system, stripped to what it needs: why is "what isn't there can't be attacked" such a powerful security idea, and how does keeping a system to a documented baseline over time prevent it slowly re-opening its doors?

Summary

How a system is configured is a distinct, major source of risk, separate from patching: a perfectly patched system can be wide open because it was set up insecurely, and many real compromises come from insecure configuration (default passwords, open services, over-broad permissions), not unpatched flaws. Software often ships configured for convenience, not security, so hardening fills the gap between how it ships and how it should be set up.
Hardening changes dangerous defaults and closes what is not needed: change default credentials first (publicly known, the easiest way in), close unneeded ports and services, and strip unused features, software, sample content, and default accounts. The organising principle is minimisation, every feature/service/account/permission not needed is removed, shrinking the attack surface, because what is not there cannot be attacked, so a hardened system is a reduced system.
Apply least privilege (each component gets only the access it needs, so a compromise yields little) and secure defaults (choose the safe setting; prefer secure-by-default software). Use a baseline (a defined, known-good secure configuration) so hardening is consistent and checkable rather than done from memory, and so configuration drift can be detected.
Hardening is an ongoing discipline, not a one-time act: configurations drift back toward openness as changes accumulate, so systems are reviewed against the baseline and drift corrected over their whole life. This connects to keeping-running (Lesson 04) and is made consistent and drift-resistant by the documentation and automation of Lesson 09.
This is the knowledge layer; configuring and hardening real systems is done under those who administer the estate, with elevated access following appointment (Lesson 10). The lesson is the distinct configuration defence alongside the patching of Lesson 04 and CIS 201, applies the least-privilege of CIS 220, secures the hosting and containers of Lessons 06 and 07, and is sustained by the documentation and automation of Lesson 09. Everything here is defensive.

Configuration, Hardening, and Secure Defaults