Hardening Techniques

Trick 1 · EDR Is Not Just "Better Antivirus" — It's a Different Architecture

Antivirus detects known threats by signature. EDR detects unknown threats by behavior. They address different scenarios.

The exam will present scenarios where a novel malware variant with no existing signature evades antivirus — then ask which technology would have detected it. The distractor is "better antivirus" or "more frequently updated signatures." Neither is the correct answer for unknown malware, because the fundamental limit of the signature model is not currency — it is that a brand-new malware variant cannot be in any signature database until it is discovered and analyzed.

The correct answer is EDR using behavioral analysis. EDR does not need to know about a specific malware variant to detect it. It detects the attack technique — the sequence of actions the malware performs (Office spawning PowerShell, PowerShell downloading an executable, executable modifying run keys) — regardless of the payload's identity. The technique is consistent across many malware families; behavioral rules that detect the technique provide broad coverage against variants that share the same attack pattern.

When the exam presents the three-phase EDR model, know which phase does what:

Detect: Behavioral analysis catches novel threats — this is the answer for "AV missed it"
Investigate: Root cause analysis — this is the answer for "how did the attack start?"
Respond: Isolation + quarantine + rollback — this is the answer for "how is the threat contained without a technician?"

Exam distractor: "A novel ransomware variant with no antivirus signature infected 40 workstations. The organization should deploy an enterprise antivirus solution with a larger signature database updated every hour to prevent future incidents of this type."

Correct: Updating signature frequency does not address the fundamental limitation — novel malware has no signature in any database regardless of update frequency. The correct solution is EDR with behavioral analysis: ransomware exhibits a distinctive behavioral pattern (mass file enumeration, rapid read-encrypt-write of diverse file types) that EDR detects and terminates before significant data is encrypted, regardless of whether the specific ransomware family has ever been observed.

Trick 2 · "Remove Unused Software" Beats "Patch Unused Software" Every Time

If the software has no business function, the correct hardening action is removal — not patching, not restricting, not monitoring.

The exam presents vulnerability scenarios for software that is installed on systems but not being used. The distractor answer is patching — "update to the latest version to close the CVEs." Patching is correct for required software. For unused software, removal is the stronger hardening action because:

Removal permanently eliminates the attack surface — no current CVEs and no future CVEs can affect removed software.
Patching maintains ongoing risk: the next version of the software will have new CVEs requiring more patching.
Patching requires ongoing maintenance effort for software that provides zero business value.
The purpose of patching is to keep required software secure — it is not a substitute for removing unnecessary software.

The exam also uses this in reverse: it will present "unnecessary software found on a system" and ask what the first action should be. "Patch it to the current version" is wrong. "Remove it" is correct. Know this rule cold: if it's unused, remove it; if it's used, patch it.

Exam distractor: "A vulnerability scanner identifies a critical CVE in Java 8 installed on 300 workstations. The Java runtime was installed as a dependency of a billing application decommissioned 2 years ago. No users have used Java since the migration. The security team should immediately deploy the latest Java runtime to all 300 workstations to remediate the CVE."

Correct: The billing application is gone — Java is unused. The correct action is to uninstall Java from all 300 workstations. Patching would close the current CVE but would require ongoing Java maintenance on systems that derive no business value from it, and Java will accumulate new CVEs in the future. Removal eliminates the attack surface permanently and reduces the patching team's ongoing workload. Only patch software that the organization actually requires.

Trick 3 · Host-Based Firewall ≠ Network Firewall — They See Different Things

A network firewall controls traffic between segments. A host-based firewall controls which processes on the endpoint can communicate — and it sees inside TLS because it sits on the OS.

Exam questions compare these two firewall types and test whether candidates understand the unique capabilities of each. The most common confusion is treating them as functionally equivalent — "both block unwanted traffic." They are not equivalent.

The critical distinctions:

Process visibility: A network firewall sees packets — it knows source IP, destination IP, and port. It cannot determine which application on the source endpoint generated the packet. A host-based firewall knows exactly which process created the connection — this enables per-process rules (permit chrome.exe but block unknown.exe on the same port) that a network firewall cannot enforce.
Encryption visibility: A network firewall cannot inspect TLS-encrypted traffic without a separate decryption proxy. A host-based firewall sits on the OS, between the application and the network stack — it sees the data before the application encrypts it for transmission (outbound) and after the OS decrypts it upon receipt (inbound). No TLS decryption infrastructure required.
Unknown process detection: When a new process (malware) first tries to initiate a network connection, the host-based firewall detects it as an unknown process and can block or flag it. A network firewall just sees a new packet from the endpoint — it has no way to know the originating process is malicious.

Exam distractor: "A host-based firewall and a network perimeter firewall provide equivalent security — both block unwanted inbound and outbound connections based on port and IP rules."

Correct: They are not equivalent. The host-based firewall's unique capabilities are: (1) per-process rules — enforcing which specific application may use which network connection; (2) pre/post-encryption visibility — inspecting application-layer data without a separate TLS decryption infrastructure; (3) unknown process detection — identifying new processes attempting network communication. These capabilities require the firewall to be on the OS itself. A network firewall cannot replicate them because it operates at the network boundary, not inside the endpoint.

Trick 4 · Hardening Is Attack Surface Reduction, Not Threat Elimination

Each hardening technique closes specific attack vectors. None eliminates all risk. The exam tests whether you know which technique addresses which scenario.

A common exam trap is presenting a hardening technique and asking whether it would prevent a specific attack — with the correct answer being "no, it would not prevent that specific attack." Hardening techniques have well-defined threat models, and applying the wrong technique to the wrong scenario is a trap:

FDE prevents physical drive theft → It does NOT prevent account compromise. If the question asks "what would have prevented an attacker who logged in with stolen credentials from accessing encrypted files," FDE is wrong — EFS would protect specific files, but FDE is transparent to authenticated sessions.
Least privilege limits post-compromise damage → It does NOT prevent initial compromise. If the question asks "what would have prevented a user from clicking a phishing link," least privilege is wrong — user training, email filtering, and sandboxing address delivery.
EDR detects malware execution → It does NOT prevent phishing email delivery. If the question asks what controls the email gateway, EDR is wrong — email security gateway, spam filtering, and sandboxing address that layer.
Port closure reduces the attack surface → It does NOT protect open required ports. Closing ports 21/23 on a server does not protect the database service on port 1433 if that service has an unpatched vulnerability.

When answering hardening scenario questions: identify the attack vector, then identify which technique's threat model matches. Defense in depth means you deploy multiple techniques — but each technique protects against its specific threat model only.

Exam distractor: "Enabling full disk encryption on all workstations would have prevented the ransomware attack that resulted from a user opening a phishing email attachment."

Correct: FDE would not have prevented the ransomware attack. FDE protects against physical drive theft — it is transparent to running software on an authenticated session. Ransomware executes in the user's session after the OS has decrypted the FDE volume; it can read and encrypt files just as any other user-mode application can. The controls that would have addressed this scenario are: EDR behavioral analysis (detect the attack chain), least privilege (prevent ransomware from stopping security services and installing persistence), and network segmentation (limit spread to other systems). FDE's threat model is physical theft, not malware execution.

Performance Task

You are the security engineer responsible for hardening the infrastructure of a 500-employee professional services firm. The following three scenarios require hardening design decisions. For each scenario, identify the controls required, explain your reasoning, and describe what failure mode each control addresses.

Scenario 1

A penetration test of the organization's network reveals the following findings on a single file server: (A) SSH is accessible on port 22 from any IP address on the corporate network; (B) FTP is running on port 21 in addition to SSH; (C) a web-based file management interface is accessible on port 8080 using default credentials (admin/admin); (D) the server is running Apache, PHP, and MySQL in addition to the file-serving role, all installed years ago by a former administrator and not currently used by any application. Design the complete hardening remediation for this server, including specific controls for each finding.

Click to reveal answer

Finding A — SSH accessible from entire corporate network:

SSH (port 22) is required for administration but should not be reachable from all 500 corporate workstations. Remediation: Apply a host-based firewall rule restricting SSH access to the management VLAN only (e.g., PERMIT src: 10.0.40.0/24 dst: this server TCP dst-port: 22; DENY ALL ELSE). Only administrators connecting from the management VLAN or through the jump server should be able to initiate an SSH session. An attacker who compromises a user workstation in the corporate VLAN should not be able to reach the server's SSH port at all.

Finding B — FTP running on port 21:

FTP transmits credentials and file contents in cleartext — there is no scenario in which FTP is acceptable on a production server. Remediation: Stop and disable the FTP service entirely. If file transfer capability is needed, SFTP over the existing SSH service (port 22) provides the same functionality with encryption. Since SSH is already hardened to management VLAN access, SFTP inherits that restriction. Disable and uninstall the FTP daemon — do not just firewall the port; a running service is still a running process that could be exploited via memory corruption even without external network access.

Finding C — Web management interface with default credentials:

Two hardening failures are present simultaneously: default credentials and an exposed management interface. Remediation: (1) Immediately change the admin credentials to a strong, unique password. (2) Restrict port 8080 to management VLAN access only (same rule as SSH above). (3) Enable MFA on the web management interface if the software supports it. (4) Consider whether this web management interface is needed at all — if the server can be administered via SSH and command line, the web interface adds attack surface without adding capability. If it is not needed, uninstall it.

Finding D — Apache, PHP, MySQL installed but unused:

This is a textbook unnecessary software scenario. Three services are running on a file server that has no web application function. Each is a potential vulnerability source. Remediation: Stop, disable, and uninstall Apache, PHP, and MySQL entirely. Do not patch them; patch is the correct action for required software. These services provide no business function on a file server and should not exist on it. After removal, verify with Nmap that ports 80, 443, and 3306 are no longer open. Document the removal in the change management system. Run a vulnerability scan to confirm no related CVEs remain exploitable.

Post-remediation verification: Run Nmap against the server after all changes. Expected open ports: TCP 22 (SSH) — accessible from management VLAN only. All other ports: closed. The Nmap result is the hardening evidence and should be retained as documentation.

Scenario 2

The SOC reports that three ransomware incidents occurred in the past year. In each case, the attack chain was identical: user opened a phishing email attachment (Office document with macro), the macro spawned PowerShell, PowerShell downloaded a payload, the payload executed, and the ransomware encrypted user files and spread to network shares. In all three incidents, the antivirus software on the endpoint did not detect the ransomware. The users in all three cases had local administrator privileges. The CISO asks you to implement controls that would have prevented or significantly limited all three incidents.

Questions: What two controls address the root causes? For each control, explain specifically which part of the attack chain it interrupts. Would either control alone have been sufficient?

Click to reveal answer

Control 1 — EDR with behavioral analysis (replaces or augments antivirus):

The attack chain described — Office spawning PowerShell, PowerShell downloading an executable, executable running and encrypting files — is a well-documented behavioral pattern that EDR rules flag as high-risk. The antivirus failed because it relies on signatures for known malware; all three variants were novel with no existing signatures. EDR behavioral analysis evaluates what the processes do, not what they are.

Specifically, EDR would have detected and blocked:

Process chain: WINWORD.EXE spawning POWERSHELL.EXE is a high-risk behavioral indicator (Office applications do not legitimately spawn script interpreters in normal use).
External download: PowerShell initiating an outbound connection to an external IP and downloading an executable — a clear C2/dropper behavior.
Encryption pattern: The ransomware itself exhibits a distinctive pattern: rapid enumeration of files, then mass read-write of each file with a renamed encrypted version. This pattern triggers EDR ransomware behavioral rules and results in process termination and endpoint isolation before significant data is encrypted.

EDR's automated response (isolate → quarantine → rollback) would have contained the incident to the initial workstation without spreading to network shares.

Control 2 — Least privilege (remove local administrator from user accounts):

In all three incidents, the ransomware was able to: install persistence mechanisms (scheduled tasks, run keys requiring admin rights), stop or modify endpoint protection services (requires admin rights), and spread to network shares (requires admin rights to access file servers from a malware context). These capabilities required the local admin rights the users had.

With standard accounts:

The macro executes (user-level — cannot prevent) and PowerShell runs (user-level — cannot prevent at this stage).
The ransomware executable runs (user-level — cannot prevent without additional controls).
The ransomware CAN encrypt files the user has access to in their own profile.
The ransomware CANNOT install kernel-level persistence, CANNOT stop the EDR/AV service, CANNOT write to system directories, and CANNOT access network shares requiring elevated permissions.

Least privilege does not prevent the ransomware from running, but it dramatically limits the blast radius: the infection is contained to user-accessible files on the single workstation, and the ransomware cannot disable the security tools that would detect and remediate it.

Would either control alone be sufficient?

Neither is sufficient alone. EDR detects and contains the attack — but even EDR can be disabled if the malware runs with admin rights and targets the EDR service before EDR detects the threat. Least privilege limits blast radius but does not prevent the initial execution or detect the attack. Together, they provide defense in depth: EDR detects the behavioral pattern and responds automatically; least privilege prevents the malware from disabling EDR before it can act and limits spread if any malware does execute. The combination is far stronger than either control applied individually.

Scenario 3

The organization is deploying 50 new network switches across three offices. The IT team proposes to configure them remotely over the internet during off-hours: connect each switch to the network as shipped, access the management interface using the default credentials, make the necessary configuration changes, then change the credentials at the end of the session. A security review of this deployment plan is requested.

Questions: What is the security flaw in this deployment sequence? What is the correct deployment order? What additional hardening controls should be applied to the management interfaces of these switches after deployment?

Click to reveal answer

Security flaw in the proposed sequence:

The plan connects the switch to the production network before changing the default credentials. During the period between network connection and credential change — even if measured in minutes — the switch is accessible on the network with known, publicly documented default credentials. Any other device on the network (including compromised endpoints) can access the switch's management interface and modify its configuration before the IT team changes the credentials.

Additionally, accessing the management interface from "over the internet" using default credentials means those credentials are also transmitted over an internet path. If the management interface uses HTTP rather than HTTPS, the credentials are cleartext and readable by any network-path observer.

The specific risk: the IT team plans to configure the VLAN assignments, spanning tree, and access control settings on these switches — then change the credential. An attacker or compromised system on the network could access the switch during the configuration window (when default credentials still work), observe or modify the configuration, and potentially maintain persistent access even after the credential change (by creating a second account or backdoor configuration entry).

Correct deployment sequence:

Pre-stage the switch off-network. Before connecting to the production network, physically connect the switch via console cable and change the default credentials. The switch should never be on the production network with default credentials, even for one minute.
Configure before deployment. While still off-network (or on an isolated staging VLAN), apply the full configuration: VLAN assignments, ACLs, spanning tree, management VLAN binding, HTTPS enforcement, management access restrictions.
Connect to production only after fully configured and hardened. When all configuration including credential change and access restrictions is complete, move the switch to its production location and connect it.
Verify after deployment. Use Nmap and the management console to confirm the switch is operating as configured and that the management interface is accessible only from the management VLAN.

Additional hardening controls for the management interfaces post-deployment:

Restrict management access to the management VLAN only. The switch's web/CLI management interface should be accessible only from the dedicated management VLAN IP range. Apply an ACL on the management interface: PERMIT src: 10.0.40.0/24 (management VLAN); DENY ALL ELSE. A compromised workstation on the user VLAN should not be able to reach the switch's management interface at all.
Disable HTTP; require HTTPS only. Management traffic must be encrypted — cleartext HTTP over any network segment is unacceptable for device administration.
Enable RADIUS/TACACS+ authentication. Integrate the switches with the organization's centralized authentication infrastructure. This eliminates per-device local admin accounts, enforces password policy uniformly, provides centralized audit logging of all management access, and allows instant credential revocation when a member of the IT team leaves.
Disable unnecessary management protocols. Disable any management protocols not in use: SNMP v1/v2 (cleartext; use SNMPv3 with authentication if SNMP is needed), Telnet (cleartext; SSH only), CDP/LLDP (limit to management VLAN if used for topology discovery).
Enroll in SIEM log forwarding. Configure each switch to forward authentication logs and configuration change logs to the SIEM. Any configuration change to a switch outside of a scheduled maintenance window should generate an alert — unauthorized configuration modification is a major red flag.

Hardening Techniques — Exam Tricks

Antivirus detects known threats by signature. EDR detects unknown threats by behavior. They address different scenarios.

If the software has no business function, the correct hardening action is removal — not patching, not restricting, not monitoring.

A network firewall controls traffic between segments. A host-based firewall controls which processes on the endpoint can communicate — and it sees inside TLS because it sits on the OS.

Each hardening technique closes specific attack vectors. None eliminates all risk. The exam tests whether you know which technique addresses which scenario.

Performance Task