3 Hardening Systems and Networks

Purpose and scope of hardening

System and network hardening reduces an attack surface: the ways an attacker could gain access, increase privileges, move through a network, or disrupt operations. It can apply to operating systems, applications, servers, endpoints, network devices, cloud resources, and the connections between them.

Hardening does not mean applying every available security setting. Settings must suit the system’s role and operating environment: a control suitable for a general-purpose workstation could break a specialized server or network appliance. The aim is to reduce risk while preserving required functionality.

Reduce unnecessary exposure

A Secure configuration baseline is an approved, documented set of specifications for a system or component at a particular point in time. It describes the expected secure state and provides a reference for future builds, changes, and checks. Changes to an approved baseline should be managed through change control.

Start by inventorying installed software, enabled features, accounts, services, network interfaces, and listening ports. Remove or disable items not required for the system’s intended role. Unnecessary services and exposed ports can create additional opportunities for attack, so confirm the effects of a change before applying it to production, especially for specialized applications or operational technology.

For example, a database server should expose database access only to authorized application systems and administrators. If it also runs an unused file-sharing service, disabling that service can reduce exposure without affecting its intended database function.

Limit privileges and secure administration

Apply least privilege by giving users, administrators, and services only the permissions needed for their tasks. Use separate administrative accounts where appropriate, restrict remote administration to approved users and management paths, and periodically review privileged access. Run services with limited permissions rather than automatically granting them broad administrative rights.

Require strong authentication for administrative and remote access, and use multifactor authentication where supported. Limit management interfaces to trusted networks or designated management systems. Protect administrative sessions with encryption, and disable or restrict insecure or unnecessary protocols.

Configure hosts and network devices

Host protections depend on the platform and business requirements. Possible measures include:

• Apply supported operating-system, application, and firmware updates.

• Enable host firewalls and allow only required inbound and outbound traffic.

• Configure account, authentication, and lockout policies.

• Protect sensitive data with appropriate encryption.

• Enable security logs and ensure they can be collected and reviewed.

• Restrict execution of unapproved software or scripts where appropriate.

• Secure file permissions, boot settings, and recovery options.

Select and test measures for the specific product and environment; exact settings vary by platform and use case.

At the network level, use firewalls and access-control rules to permit only necessary communications. Network segmentation separates systems with different functions or sensitivity levels, limiting available paths for lateral movement if a system is compromised. For example, public-facing services can be placed in a separate network zone from internal user devices and sensitive databases.

Secure routers, switches, wireless access points, and firewalls by changing vendor defaults, restricting management access, disabling unused ports and protocols, and protecting configuration backups. Document intended network flows so firewall rules can be reviewed against business needs.

Choose and tailor a baseline

Use recognized configuration guidance as a starting point, such as a relevant CIS Benchmark, a DISA Security Technical Implementation Guide (STIG), or a checklist in NIST’s National Checklist Program. Match the guidance to the exact product, version, and operational context. A Security configuration checklist can help configure products, verify settings, and identify unauthorized changes; CIS Benchmarks provide technology-specific secure configuration recommendations.

A baseline should specify:

• Scope: the product, version, system role, and environments covered.

• Required settings: the secure values or behaviors to implement.

• Rationale and impact: why each requirement exists and any operational consequences.

• Verification method: how to check whether the requirement is met.

• Ownership and review: who approves the baseline and when it is reviewed.

• Exception process: how a necessary deviation is justified, approved, documented, and revisited.

Treat benchmarks as guidance rather than a substitute for judgment. Test settings in a representative environment before broad deployment. If a setting conflicts with a documented operational need, record the deviation, assess its risk, apply compensating safeguards where feasible, and obtain approval through the organization’s change process. Configuration management should manage and monitor configurations while supporting required business functionality.

Deploy, verify, and maintain configurations

A repeatable workflow helps prevent inconsistent builds and missed changes:

1. Identify assets and roles. Maintain an inventory of systems, software, versions, owners, and network connections.

2. Choose and tailor the baseline. Select authoritative guidance, document required settings, and approve justified exceptions.

3. Test changes. Apply them in a test or pilot environment and check functionality, security effects, and recovery procedures.

4. Deploy consistently. Where appropriate, use managed images, configuration-management systems, policy tools, or scripts. Restrict access to make changes.

5. Verify the result. Use configuration assessment tools, policy checks, manual inspection, and authorized network testing as appropriate. Check both system settings and services reachable over the network.

6. Record and remediate findings. Compare observed settings with the approved baseline, prioritize deviations by risk and operational context, correct unauthorized or unsafe differences, and document approved exceptions.

7. Monitor and review. Recheck systems after significant changes and on a defined schedule. Update baselines when products, threats, requirements, or approved architectures change.

For example, if a baseline requires a server’s remote administration interface to be reachable only from the management network, verification should check the server’s local configuration and use an authorized network test to confirm the interface is not reachable from unapproved network zones. A passed local setting alone does not prove that surrounding firewall rules are correct.

Scanners and automated checklists can assess many settings efficiently, but their findings need interpretation. A tool may report a setting as noncompliant despite an approved exception, or it may not check a requirement that matters in the local environment. Keep assessment results, exceptions, approvals, and remediation records together so changes are auditable.