← Back to domain
Domain 5 Module 5.2

System Hardening

5.2 System Hardening

Navigation

What Hardening Means

System hardening is the process of reducing attack surface so a system has fewer ways to be exploited. A hardened machine has only the services, ports, accounts, permissions, and software that are actually required.

The easiest way to understand hardening is to think of a house:

  • A normal house may have many doors and windows.
  • A hardened house locks every entry point, removes unused access, and alarms the important rooms.

Security hardening applies the same logic to operating systems, applications, network devices, databases, and cloud workloads.

1. Configuration Management

Configuration management is the discipline of documenting, controlling, and maintaining a known-good setup. Without it, systems drift over time as administrators make one-off changes and forget to record them.

Core terms

| Term | Meaning | |---|---| | Baseline | Approved standard configuration | | Benchmark | A recommended secure configuration target | | Drift | Unplanned deviation from the baseline | | Standard | Repeated configuration requirement | | Exception | Approved deviation from the standard |

CIS Benchmarks and DISA STIGs

| Guide | Description | Typical Use | |---|---|---| | CIS Benchmarks | Community security configuration guides | General enterprise hardening | | DISA STIGs | Department of Defense hardening standards | High-security and government environments |

These guides are useful because they turn vague advice like "secure the server" into specific steps like "disable unused services," "require strong authentication," and "restrict remote administration."

Why baselines matter

Without a baseline, security teams cannot tell whether a change improved security, weakened security, or simply altered the environment. A baseline gives you something to compare against.

2. Hardening Principles

Hardening is built on simple principles.

| Principle | Meaning | |---|---| | Least functionality | Install and enable only what is needed | | Default deny | Block by default, allow by exception | | Minimal attack surface | Remove unnecessary entry points | | Secure by default | New systems should start with safe settings | | Defense in depth | Use multiple controls, not a single safeguard |

Exam-friendly logic

If a question asks for the safest general posture, think:

  • default deny
  • least privilege
  • least functionality
  • secure baseline

3. Hardening Steps

Typical hardening work includes:

1. Remove unnecessary software and services. 2. Close unneeded ports. 3. Disable unused accounts and change defaults. 4. Patch the operating system and applications. 5. Enable logging, alerting, and auditing. 6. Restrict administrative access. 7. Enforce strong authentication. 8. Verify the configuration against a baseline.

Why these steps work

Every service, account, and open port is a potential foothold. Removing what you do not need reduces the number of paths an attacker can take.

Real-world example

If a web server only needs HTTPS, there is no reason for Telnet, FTP, database admin tools, or remote desktop to be exposed on that host. Reducing services lowers risk immediately.

4. Patch Management

Patch management is the structured process of keeping software up to date so known vulnerabilities are closed.

Patch lifecycle

| Step | Action | |---|---| | Monitor | Watch for vendor advisories and vulnerability announcements | | Assess | Determine impact and relevance | | Prioritize | Rank based on risk and exposure | | Test | Validate in a non-production environment | | Deploy | Apply the patch to production | | Verify | Confirm the patch worked and did not break systems |

Patch types

| Type | Meaning | |---|---| | Security patch | Fixes a vulnerability | | Bug fix patch | Fixes software defects | | Hotfix | Emergency out-of-cycle fix | | Service pack | Bundle of fixes and improvements |

Patch strategy example

Suppose a critical browser vulnerability is announced. The team reviews exposure, tests the patch on a pilot group, deploys it in phases, and verifies version numbers and behavior afterwards.

Why testing matters

Patching is a security control, but a bad patch can break production. Hardening is not just about security. It is also about stability and repeatability.

5. CVSS and Risk Prioritization

CVSS stands for Common Vulnerability Scoring System. It gives a score from 0 to 10 to help indicate severity.

| Score Range | Meaning | |---|---| | 0.0 | None | | 0.1-3.9 | Low | | 4.0-6.9 | Medium | | 7.0-8.9 | High | | 9.0-10.0 | Critical |

Important note

CVSS tells you severity, not business impact. A low-CVSS issue on an internet-facing production system may matter more than a higher score on an isolated lab machine.

Example

Two vulnerabilities exist:

  • One affects a public-facing VPN appliance with a high CVSS.
  • One affects a test system with medium CVSS.

The VPN vulnerability should usually be prioritized first because exposure increases real-world risk.

6. Operating System Hardening

OS hardening focuses on the host itself.

Common OS hardening actions

  • Remove unnecessary packages
  • Disable guest or anonymous access
  • Turn off legacy protocols
  • Enforce strong password or MFA policy where applicable
  • Restrict local admin use
  • Enable host firewall rules
  • Apply audit logging
  • Enable secure boot and disk encryption when appropriate

Windows-specific examples

  • Disable unnecessary services such as old file sharing features
  • Use Group Policy to enforce settings
  • Limit local administrator membership
  • Use Windows Defender and firewall controls
  • Enable event auditing

Linux-specific examples

  • Remove unused daemons
  • Harden SSH configuration
  • Use sudo instead of shared root access
  • Set file permissions carefully
  • Log authentication and privilege events

OS hardening analogy

Hardening an OS is like closing every window in a building except the ones required for daily business. The fewer openings, the fewer ways in.

7. Application Hardening

Applications often fail because of insecure defaults or unnecessary features.

Application hardening steps

  • Patch the application and dependencies
  • Disable demo accounts and sample content
  • Remove unused plugins and modules
  • Change default credentials
  • Configure secure session handling
  • Restrict administrative consoles
  • Turn off verbose error messages in production

Why it matters

A perfectly hardened operating system can still be compromised if the application running on it exposes a weak admin panel, debug mode, or default password.

Example

A content management system is installed for a website. If the admin panel is accessible from anywhere and the default administrator account still exists, the system is not hardened even if the host OS is fully patched.

8. Network Hardening

Network hardening limits how systems communicate.

Common network controls

  • Close unused ports
  • Disable unused services
  • Use secure protocols only
  • Segment networks by function and sensitivity
  • Filter traffic with firewalls
  • Replace insecure management protocols with secure ones
  • Use VPN or secure tunnels for remote access

Typical insecure vs secure choices

| Insecure | Better Choice | |---|---| | Telnet | SSH | | FTP | SFTP or FTPS | | HTTP | HTTPS | | Unrestricted access | Firewall rules and segmentation |

Network hardening example

An internal database should not be reachable from the internet. It should listen only on the required internal subnet, and only the app servers should be allowed to connect to it.

9. Database Hardening

Databases hold sensitive information, so they need focused protection.

Database hardening actions

  • Change default admin credentials
  • Restrict remote access
  • Use least privilege database accounts
  • Separate read and write roles if possible
  • Encrypt sensitive fields and backups
  • Patch the database engine quickly
  • Enable detailed auditing for privileged actions
  • Restrict direct access to the database server

Example

If a payroll database account can also create other users, that is excessive privilege. A hardened configuration would limit that account to only the actions required for payroll operations.

10. Change Management and Hardening

Hardening changes should not be made casually. They need change control so the team can track impact and recover if something goes wrong.

Relationship to change management

Hardening often introduces:

  • new baseline settings
  • service removals
  • firewall changes
  • authentication changes
  • patch rollouts

These are configuration changes and should usually follow change management policy.

Why this matters

If a security admin disables a service without approval, the action might break business processes. Change management makes security work safer and more predictable.

11. Secure Configuration Practices

The exam often frames hardening through secure configuration principles.

| Practice | Meaning | |---|---| | Default deny | Deny by default, allow only what is required | | Least functionality | Keep only needed services and features | | Minimal install | Install only required components | | Secure defaults | Start with safe settings | | Logging | Keep records of access and changes |

Configuration drift

Configuration drift happens when a system gradually diverges from the approved baseline. It may occur because of manual changes, emergency fixes, or software updates.

Drift example

A hardened server is approved with one open management port. Over time, an administrator opens three more ports for troubleshooting and never closes them. That is drift.

Why drift is dangerous

Drift creates surprise. Security tools, auditors, and operators assume the baseline is still in place when in reality it is not.

12. Hardening and Monitoring Together

Hardening and monitoring are stronger when used together.

  • Hardening prevents many problems.
  • Monitoring detects what still gets through.

If you only monitor without hardening, the attack surface stays large. If you only harden without monitoring, you may miss evidence of compromise.

13. Hardening Across the Lifecycle

Hardening should be considered at every stage of the system lifecycle.

Before deployment

  • Choose approved hardened images
  • Remove unwanted packages before first use
  • Define baseline settings in advance
  • Prepare logging and monitoring

During deployment

  • Apply standard build scripts
  • Verify ports and services match the baseline
  • Confirm access controls and admin accounts

After deployment

  • Monitor for drift
  • Reassess after updates
  • Reapply baseline settings when needed
  • Review findings from audits and incidents

Why this matters

A system that is hardened once and then ignored will slowly become weaker. Security operations must treat hardening as a continuing control, not a one-time project.

14. Verification and Validation

Hardening is not complete until it is checked.

Verification methods

  • compare the system against the baseline
  • scan for open ports and exposed services
  • review account and group membership
  • inspect configuration files and policy settings
  • confirm logging is active and forwarding correctly

Validation methods

  • confirm the system still supports business tasks
  • test login, application access, and network access
  • run user acceptance checks after major changes

Why both matter

Verification proves the control is present. Validation proves the business can still operate. A secure system that breaks operations may be rejected, and a working system that is not hardened is risky.

Exam Tips

  • Hardening means reducing attack surface.
  • CIS Benchmarks and DISA STIGs are configuration guidance.
  • Patch lifecycle: monitor, assess, prioritize, test, deploy, verify.
  • CVSS is 0 to 10.
  • Least functionality and default deny are recurring test themes.
  • Configuration drift is deviation from baseline.

Practice Questions

1. What is the main goal of hardening? ✅ Reduce attack surface

2. Which document type provides secure configuration recommendations for many systems? ✅ CIS Benchmarks

3. What is the correct patch management order? ✅ Monitor, assess, prioritize, test, deploy, verify

4. What CVSS range is considered critical? ✅ 9.0 to 10.0

5. What principle means only necessary services should run? ✅ Least functionality

6. What should be done before deploying a patch to production? ✅ Test it in a non-production environment

7. What is configuration drift? ✅ Unplanned deviation from the baseline

8. What is a hotfix? ✅ An emergency out-of-cycle patch

9. Which protocol is more secure than Telnet for remote administration? ✅ SSH

10. Why is change management important for hardening? ✅ It controls and documents security-related configuration changes