Operating system hardening is the systematic reduction of an OS attack surface via configuration, patch management, service minimization and privilege hardening. It includes baselines, policies and automation to ensure consistent, repeatable state across deployments. The goal is to increase system security and reduce exposure to exploits.
Use this profile to understand the building block briefly, place it in the model, and switch to the 360° assessment when needed.
Theoretical construct: explains a term, principle, or mental model.
What organizes, connects, or makes decisions possible.
Operating system hardening deliberately reduces an operating system’s attack surface and configuration weaknesses through technical and organizational safeguards.
Hardening grew from securing multi-user systems where unnecessary services, broad privileges, and unsafe defaults opened paths to attack. Guidance such as CIS Benchmarks and automation projects such as dev-sec collect configuration practices developed from that work.
Treat a system like a building: close unused doors, limit keys, strengthen the outer walls, record entries, and regularly check whether renovations opened new routes.
Reachable services, interfaces, and functions form possible entry and abuse paths.
Accounts and services receive only the permissions their task requires.
Documented target values make configuration testable and deviations visible.
Hardening lowers the likelihood and potential impact of common attacks on servers, workstations, and images. Controls must fit operations, availability, and maintenance; overly restrictive settings can impair legitimate functions or recovery.
Where this building block is located in the topic model.
No structure path available.
Explore how this building block connects to concepts, methods, technologies, and tools.
These sources establish the term and its professional meaning.
All direct connections of the current building block in a compact text view.
This classification shows where the building block typically matters, how demanding it is, and what kind of impact it has in the model.
The level within the organization (enterprise, domain, team) at which the AssetBlock is applied.