15.3 Reducing Attack Surface on Endpoints, Servers, and Devices

Least Functionality Across Endpoints

Attack surface is the set of ways a system can be reached, used, or abused. Hardening reduces it without making the system useless — the principle of least functionality keeps what the business needs and removes what it does not. CC scenarios reward spotting unnecessary services, default accounts, broad access, legacy protocols, missing logging, and weak administration paths.

Endpoints are laptops, desktops, tablets, and managed mobile devices. Common endpoint hardening:

• Full-disk encryption (FDE) — protects data at rest if a powered-off device is stolen
• Host firewall and endpoint detection and response (EDR) / anti-malware
• Least privilege — users run without local administrator rights
• Screen lock, strong authentication / multi-factor authentication (MFA)
• Automatic updates, controlled software installation, secure browser settings, remote wipe

Worked example: a sales laptop is stolen from a car. FDE plus strong sign-in keeps customer files unreadable. Because the user has no local admin rights, malware that did run had fewer paths to install drivers or disable tools. Because the device reported logs and health, the security team can confirm whether it was compliant before the theft. Each control removes a class of risk rather than relying on one magic setting.

Server and Network Device Hardening

Servers should run only the roles they need. A database server should not also host stray file shares, test web apps, exposed remote desktop, and sample services — each extra service adds code, accounts, logs, and vulnerabilities. Server hardening includes minimal installation, patching, host firewall rules, protected management access, service-account least privilege, secure logging, time sync, backups, and removal of sample/default content.

Administration paths deserve special care: restrict remote admin to management networks, VPNs, jump hosts, or privileged access systems; avoid shared admin accounts (they destroy accountability); use secure protocols, not legacy ones.

Network devices — routers, switches, firewalls, wireless controllers — need the same discipline: change default credentials, disable unused management protocols, use SSH/HTTPS management, restrict admin by source network, disable unused physical interfaces, update firmware, back up configs securely, ship logs centrally, and use SNMPv3 if SNMP is required.

Memorize these insecure-to-secure swaps — the exam loves them:

Removing Unnecessary Services and Scenario Reasoning

Removing or disabling unneeded services is one of the clearest hardening actions. If a server does not need FTP, disable it. If a printer does not need internet-facing management, block it. If a workstation does not need a local web server, remove it. This cuts vulnerabilities, simplifies monitoring, and makes suspicious activity stand out.

Be careful with production dependencies. A service that looks unused may support backups, monitoring, licensing, or an old integration. Good hardening confirms ownership and purpose first, then documents the change and a rollback plan.

Worked scenarios

• A vulnerability scan finds Telnet enabled on several switches. The right response: disable Telnet, enable SSH, restrict admin access by source network, and verify administrators can still manage the switches through approved paths.
• A workstation gold image ships with games, trial software, local admin rights for every user, and no host firewall. The fix: remove unapproved software, enforce least privilege, enable protective controls, and validate the image before deployment.
• A switch port in a public lobby wires straight into the internal network. If unneeded, disable the port; if needed, apply network access control, a guest/quarantine VLAN, monitoring, and physical protection.

Common traps

• Picking "add another tool" when the cleaner answer is remove the unneeded service.
• Disabling a service without confirming an integration depends on it (no ownership check, no rollback).
• Hardening so aggressively that required business function breaks — least functionality, not zero functionality.

Application Allow-Listing, Default Accounts, and Special Device Classes

Beyond services and protocols, two endpoint hardening techniques appear repeatedly on the CC exam. Application allow-listing (also called whitelisting) permits only approved programs to run and blocks everything else by default — the opposite of a deny-list that tries to enumerate bad software. Allow-listing is powerful against unknown malware because an attacker's tool simply will not execute, but it requires real maintenance: every legitimate new application must be approved, or users are blocked. Disabling unused features within an application (macros, scripting, legacy file formats, remote add-ins) is a related, lower-effort win.

Default and orphaned accounts are a recurring scenario clue. Vendor systems ship with built-in administrator, guest, or service accounts; old projects leave behind test logins. Hardening means renaming or disabling default accounts, removing test accounts, enforcing unique named admin accounts (never shared), and pairing privileged access with MFA. Shared accounts destroy accountability — if everyone uses "admin," no log can tell you who made a change.

Hardening beyond traditional computers

The broad lesson the exam reinforces: hardening principles are technology-agnostic. Whether the target is a laptop, a printer, a smart sensor, or a cloud server, you still change defaults, remove what is not needed, restrict and protect administration, enable logging, and keep firmware or software current. Network segmentation deserves a special mention because it both reduces attack surface and limits blast radius — an exposed IoT device on an isolated VLAN cannot easily reach the finance servers.

When a question describes a fleet of cheap connected devices with hard-coded credentials, the strong answers are change-or-disable defaults plus segmentation, never "trust the vendor."