Secure Baselines and Hardening

What the Exam Is Really Testing

Here is a mistake that shows up constantly in real environments: an administrator builds a new server, installs the application, connects it to the network — and never turns off the dozen default services that shipped with the OS. Telnet is running. FTP is listening. The default admin account still has its factory password. Three months later, that server is the entry point for a breach.

Every system ships with features you do not need — and every unnecessary feature is an attack surface.

Hardening is the process of reducing that surface to the minimum required for business function. Secure baselines are the documented, repeatable standards that define what "hardened" actually looks like in your environment. The exam tests whether you can identify what needs to be locked down, which framework drives the configuration, and why consistency across systems matters more than one-off heroics.

Secure Baselines: The Foundation

A secure baseline is a documented configuration standard that defines the minimum security posture for a system before it goes into production.

Think of it as a checklist that answers: what should every server, workstation, or device look like before it touches the network?

Baselines typically define:

• Which services and ports are enabled (and which are disabled)
• Which accounts exist (and which default accounts are removed)
• Password and lockout policies
• Patch levels and update configurations
• Logging and auditing settings
• Firewall rules and network configurations

CIS Benchmarks

The Center for Internet Security (CIS) publishes free, consensus-driven configuration benchmarks for operating systems, cloud platforms, network devices, and applications. These are the most widely referenced baselines on the exam.

CIS benchmarks provide two profile levels:

• Level 1 — Practical security settings that can be applied broadly without breaking functionality
• Level 2 — Deeper hardening for high-security environments, may impact usability

Other baseline sources include DISA STIGs (Department of Defense), vendor-specific hardening guides, and organizational internal standards.

Hardening Techniques

Hardening takes a default installation and strips it down to only what is necessary. The key categories tested on Security+ include:

Disabling Unnecessary Services and Ports

Every running service is a potential entry point. Default installations often enable services that are never used — FTP, Telnet, SNMP, print spoolers on servers that never print.

The principle is simple: if you do not need it, turn it off. If it must run, restrict access to it.

Removing Default Accounts and Credentials

Default accounts (admin/admin, root/toor, sa/blank) are the first thing attackers try. Hardening requires:

• Renaming or disabling default administrator accounts
• Removing guest accounts
• Changing all default passwords before deployment
• Removing sample applications and default web pages

Registry and Configuration Changes

On Windows systems, the registry controls thousands of security-relevant settings — from disabling LM hash storage to enforcing SMB signing. On Linux systems, configuration files in /etc control equivalent behaviors.

Key hardening configurations include:

• Disabling autorun and autoplay
• Enforcing NTLMv2 or Kerberos authentication
• Restricting anonymous enumeration
• Setting secure file permissions

Group Policy and Centralized Management

In Windows environments, Group Policy Objects (GPOs) enforce baselines across thousands of machines from a single console. This is the enterprise mechanism for consistent hardening.

GPOs can enforce:

• Password complexity and rotation
• Software restriction policies
• Firewall configurations
• Audit logging settings
• User rights assignments

SELinux and AppArmor

These are mandatory access control (MAC) frameworks for Linux:

• SELinux — Uses security labels and policies to restrict what processes can access, even if running as root. Common on RHEL/CentOS.
• AppArmor — Uses path-based profiles to confine applications. Common on Ubuntu/SUSE.

Both enforce the principle that even privileged processes should only access what they need.

Hardening by Target

Operating System Hardening

• Apply all current patches and updates
• Remove unnecessary roles, features, and software
• Configure host-based firewalls
• Enable full disk encryption
• Enforce secure boot
• Disable USB ports where not required

Application Hardening

• Remove default installations and sample files
• Disable unnecessary modules and plugins
• Apply application-level patches
• Configure input validation and error handling
• Use least privilege for service accounts
• Enforce secure communication (TLS)

Endpoint Hardening

• Deploy endpoint detection and response (EDR)
• Enable host-based intrusion detection
• Configure application whitelisting/allowlisting
• Enforce screen lock timeouts
• Disable Bluetooth and NFC when not needed
• Implement secure boot chain

Configuration Lockdown

Once a baseline is established, drift is the enemy. Configuration lockdown means:

• Documenting the approved baseline
• Automating deployment (images, scripts, Infrastructure as Code)
• Monitoring for drift with configuration management tools
• Alerting when systems deviate from baseline
• Re-imaging or remediating non-compliant systems

The goal is not just to harden once — it is to ensure hardening persists over time.

Pattern Recognition

When you see a question about secure baselines or hardening, look for these patterns:

• The answer that reduces attack surface wins over the answer that adds monitoring
• Consistent, documented baselines beat ad-hoc hardening by individual administrators
• CIS benchmarks and DISA STIGs are the go-to references for baseline configuration
• Group Policy is the Windows answer for enterprise-wide enforcement
• SELinux/AppArmor questions focus on restricting what processes can do, not what users can do

Trap Patterns

Watch for these common distractors:

• "Deploy a SIEM" — Monitoring detects problems but does not harden the system
• "Install antivirus" — Important, but not a substitute for reducing attack surface
• "Train the users" — Awareness helps, but baselines are technical controls
• "Update the firewall rules" — Network controls do not replace host-level hardening

If the question describes a default installation with unnecessary services running, the answer is hardening — not monitoring, not training, not network controls.

Scenario Practice

Question 1

A new server is deployed with the default operating system installation. An administrator discovers several unnecessary services running, including Telnet and FTP.

What should the administrator do FIRST?

A. Install a host-based intrusion detection system
B. Disable unnecessary services and apply the organization's secure baseline
C. Configure a network firewall rule to block Telnet and FTP traffic
D. Document the running services for future reference

Question 2

An organization wants to ensure that all Windows workstations enforce the same password policy, screen lock timeout, and firewall configuration.

What is the MOST effective approach?

A. Email the IT team a hardening checklist to follow manually
B. Deploy Group Policy Objects from Active Directory
C. Install third-party endpoint management on each machine individually
D. Conduct quarterly audits to verify compliance

Question 3

A Linux web server running Apache is compromised through a vulnerability in a module that was installed by default but never used by the application.

Which hardening principle was violated?

A. Principle of least privilege
B. Defense in depth
C. Removal of unnecessary components
D. Separation of duties

Key Takeaway

Hardening is not about adding security tools on top of a default installation — it is about removing everything that does not need to be there. The most secure system is the one with the smallest attack surface. Before any system goes into production, you should be able to answer four questions: Is there a documented baseline for this system type? Have all default accounts and credentials been removed? Are only required services and ports enabled? Is there a mechanism to detect and correct configuration drift? In the real world and on the exam, the hardened system with a documented baseline wins over the unmanaged system with extra monitoring bolted on.