Hardening targets — SY0-701

WHAT IT IS

Hardening is "a process intended to eliminate a means of attack by patching vulnerabilities and turning off nonessential services" (NIST SP 800-152). Applied to a target — an operating system, application, network device, cloud workload, or container — it systematically shrinks the attack surface: "the set of points on the boundary of a system, a system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, component, or environment" (NIST SP 800-53 Rev. 5).

Mental model

Picture a medieval castle. Hardening is the act of bricking up unused gates, removing ladders left against outer walls, and replacing default iron keys that every castle already had. You are not building new defenses — you are taking away unnecessary handholds the attacker could use.

Three moves accomplish this in practice:

1. Remove what is not needed. Uninstall packages, disable services, and close ports that serve no operational purpose. Fewer entry points means a smaller attack surface (OWASP Attack Surface Analysis Cheat Sheet).
2. Restrict what remains to the minimum necessary. Least privilege holds that "each entity is granted the minimum system resources and authorizations that the entity needs to perform its function" (NIST SP 800-53 Rev. 5).
3. Keep it current. Patch management is "the systematic notification, identification, deployment, installation, and verification of operating system and application software code revisions, including patches, hot fixes, and service packs" (CNSSI 4009-2015 / NIST SP 800-137). Unpatched vulnerabilities directly contradict the hardening goal.

A baseline configuration anchors the result: "a documented set of specifications for an information system or configuration item that has been formally reviewed and agreed upon at a specific point in time, and which can only be changed through change control procedures" (NIST SP 800-128). Hardening without a documented baseline cannot be consistently enforced or audited.

When to use it

Hardening applies to every target category. The table below shows how the same three moves manifest differently depending on what is being hardened.

Target	Remove / Disable	Restrict	Patch / Update
Operating system	Unused services, open ports, default accounts	Filesystem permissions, user privilege levels	OS patches and hot fixes
Network device	Unused protocols, unneeded management interfaces	Access-control lists, management-plane access	Firmware updates
Application / web server	Unused modules, sample files, default credentials	Least-privilege service accounts, read-only mounts where feasible	Application patches, dependency updates
Container / cloud workload	Unnecessary packages and shells (e.g., distroless images)	Non-root execution, dropped capabilities, read-only filesystems	Base image updates, runtime patching
Mobile / endpoint	Unused apps, debug interfaces	Device management policies, storage encryption	OS and app updates

The common thread across all target types is reducing the attack surface before an incident, not responding to one.

COMMON MISCONCEPTION

The trap: Candidates sometimes treat hardening and patching as synonyms, or assume that applying available patches alone constitutes full hardening.

Patching is one component of hardening — it addresses known vulnerabilities in existing code. Hardening is broader: it also means removing services that are not needed at all, regardless of whether those services are patched. A fully patched service that is unnecessary still enlarges the attack surface (OWASP Attack Surface Analysis Cheat Sheet notes that attack surface analysis helps "identify … high-risk code areas needing defense-in-depth"). Removing the service eliminates that class of risk entirely; patching only reduces the severity of exploiting it.

A related misconception is equating hardening with perimeter defense. Hardening is applied to the target itself — the host, image, or application — not only to the network boundary around it. Configuration management (CM), defined by NIST SP 800-128 as "a collection of activities focused on establishing and maintaining the integrity of information technology products and systems, through control of processes for initializing, changing, and monitoring the configurations of those products and systems," is the ongoing discipline that sustains the hardened state over time.

How it shows up on the exam

Questions on hardening targets tend to test application rather than recall. A scenario will describe a system in its post-deployment state and ask which action reduces the attack surface, or it will list four security activities and ask which one constitutes hardening rather than monitoring, incident response, or access control.

Watch for scenarios that conflate adjacent operations:

• Hardening vs. monitoring: Hardening reduces the number of exploitable entry points; monitoring detects activity at existing entry points. The OWASP Attack Surface Analysis Cheat Sheet frames the distinction clearly — mapping entry/exit points is assessment; removing unnecessary ones is reduction.
• Hardening vs. patching: Patching is a means of hardening, not the whole of it. If a scenario describes only applying updates while leaving unused services enabled, that is incomplete hardening.
• Hardening vs. configuration management: Configuration management maintains the hardened state through change control and monitoring (NIST SP 800-128); the initial hardening act creates the secure baseline.

Candidates often underestimate how broadly "targets" is scoped. Container-specific controls — such as dropping capabilities, enforcing non-root execution, and using minimal base images — reflect the same hardening principles as OS-level hardening; the OWASP Docker and Kubernetes cheat sheets ground these as concrete applications of least privilege and attack surface minimization.

Related concepts

• Secure baselines — the documented configuration state that hardening works toward and configuration management preserves.
• Wireless security — wireless access points are hardening targets with their own attack surface considerations, including disabling unused protocols and changing default credentials.
• Mobile device management — MDM enforces hardening policies (app restrictions, OS update requirements, encryption) across a fleet of mobile targets at scale.