A security control is strong only when it interrupts a defined threat path without breaking the required task
Topic 1.3 identifies what the endpoint needs protected. Topic 1.4 turns that requirement into action. The strongest approach is not “enable every security feature.” It is to choose controls that address the specific exposure, configure them narrowly, preserve legitimate use, and verify the resulting state with evidence.
This model makes security testable. “I enabled the firewall” is a configuration statement. “The approved administrator subnet can reach SSH while the guest subnet remains denied” is a verified security outcome.
Layers are valuable because different controls fail in different ways
Patching removes known software weaknesses. Authentication protects account entry. Least privilege limits what an authenticated identity can do. A host firewall reduces network exposure. Encryption protects data under particular loss or interception conditions. Endpoint protection can detect malicious behavior. Backups support recovery. Physical controls reduce unauthorized possession or use.
These controls overlap, but they are not interchangeable. MFA does not patch a browser. Disk encryption does not block an inbound service. A firewall does not restore encrypted files after ransomware. Defense in depth works when each layer has a defined job and the remaining layers still reduce impact if one job fails.
Choose a control by asking which step in the attack path it changes
| Observed need | Control | Threat-path effect | Evidence to verify |
|---|---|---|---|
| Known vulnerable browser version | Patch/update | Removes the known vulnerable code condition | Installed version/build confirms fix |
| Password theft could expose privileged account | MFA | Makes password alone insufficient | Password-only sign-in fails |
| Routine user has excessive rights | Least privilege | Limits post-compromise capability | Restricted action requires controlled elevation |
| Unneeded inbound service is reachable | Host firewall | Removes unnecessary network path | Allowed flow works; prohibited source fails |
| Lost laptop could expose stored records | Disk encryption | Protects data at rest without unlock key | Encryption/key status is confirmed |
| Ransomware could destroy working files | Protected backup | Provides an independent recovery path | Restore test succeeds |
Swipe horizontally to see the full table.
“Update available” and “security fix installed” are different states
Operating systems, browsers, VPN clients, drivers, document readers, and management agents all expand the endpoint's software attack surface. When a security update addresses a known weakness, the useful evidence is not that an updater displayed a notification. The useful evidence is the resulting installed version, build, package state, or management status.
Patching also has an availability side. A high-impact endpoint may need staged deployment, compatibility testing, rollback planning, or a maintenance window. That does not make patching optional; it means the control must be implemented in a way that reduces vulnerability without creating an avoidable outage.
Protect the whole account-entry path, including recovery
Unique credentials reduce password reuse risk. Multifactor authentication can make a stolen password insufficient. Device certificates or managed identity systems can provide additional assurance where the environment supports them. But the authentication chain is only as strong as its bypass paths.
If account recovery can be hijacked through a weak email account, predictable questions, or uncontrolled help-desk procedures, a strong primary password may not preserve the intended assurance. Shared administrator credentials also weaken accountability and revocation because activity cannot be cleanly tied to one identity.
A privileged password is phished, but MFA changes what the attacker can do next
An administrator enters a password into a convincing fake sign-in page. Without another factor, the stolen credential may immediately provide account access. With properly configured MFA, the attacker still lacks an additional required proof.
The control has not made phishing impossible. It has interrupted one threat path by changing the condition for successful authentication. Verification should confirm an authorized user can complete MFA and that the password alone cannot satisfy the sign-in requirement.
This is also an evidence boundary: an unexpected MFA prompt can be a warning sign, but it does not by itself prove the password was stolen. The event should be investigated rather than treated as automatic proof of compromise.
Reduce the blast radius after authentication or code execution succeeds
Least privilege does not prevent every compromise. It changes what happens afterward. A routine user who cannot modify protected system settings gives malicious code fewer immediate capabilities than a user performing everyday browsing and email as a permanent local administrator.
Privilege should follow the task. If an approved networking lab utility needs a specific elevated action, controlled elevation or a narrow capability is stronger than granting unrestricted administrator rights indefinitely. Separate administrative identities can also keep high-risk routine activity away from privileged sessions.
Write rules around required flows, not around frustration
A host firewall can filter traffic using network profile, application, protocol, port, source, destination, and direction. The strongest starting question is therefore: what exact communication must succeed? A management service required only from an administrator subnet should not become reachable from every network merely because an “allow” rule is easier to write.
Required flow: source: approved admin subnet destination: managed endpoint service: SSH / TCP 22 profile: managed network Verification: ✓ approved source connects ✗ guest/unapproved source remains denied
The syntax differs by operating system, but the reasoning does not: authorize the required path and retain the rest of the boundary.
Disabling the firewall fixes the app—and proves only that policy is relevant
A classroom application cannot receive a required inbound connection. A temporary controlled test with the host firewall disabled restores the application. That is valuable diagnostic evidence because the firewall state changes the outcome.
It does not justify leaving the firewall off. The next step is to identify the executable, protocol, port, source, destination, or profile the application actually requires. Create the minimum authorized exception, restore normal firewall operation, test the application from the approved source, and test an unapproved source to confirm the broader boundary still exists.
Disk encryption changes the consequence of physical possession
Full-disk encryption is designed to protect stored data when an unauthorized person obtains a locked or powered-off device but lacks the unlock secret or managed key. It does not make the device invulnerable. If malware runs after the legitimate user unlocks the disk, the active account may still be able to read the files.
Key management matters just as much as the encryption switch. Organizations need a controlled recovery method so hardware failure, forgotten credentials, or personnel changes do not turn confidentiality protection into permanent data loss. Verification should therefore include encryption state and appropriate recovery-key management.
Protect the traffic path without confusing encryption with trust
HTTPS uses TLS to protect web traffic in transit and, when certificate validation succeeds, helps authenticate the server identity. SSH provides encrypted remote administration. Approved VPN technologies can protect traffic across untrusted networks when organizational policy requires them.
Encryption alone does not prove the destination is safe. A phishing site can use HTTPS. A certificate warning can indicate a name, trust, or interception problem. Teaching users to click through certificate warnings destroys evidence and weakens the identity check that secure transport is supposed to provide.
Link protection, application protection, and network trust are separate layers
Managed Wi-Fi should use the organization's intended authentication and encryption mode, such as an appropriate WPA2 or WPA3 deployment. That protects the wireless link according to the selected configuration, but secure applications still need protocols such as HTTPS or SSH.
On public Wi-Fi, reduce local sharing exposure, avoid automatically joining look-alike networks, and follow organizational VPN requirements. A familiar SSID string is not proof that the access point is the intended network. Network identity and authentication matter.
Detection complements prevention; it does not erase the need for prevention
Anti-malware tools can identify known malicious files, suspicious behavior, or unwanted software. Application allowlisting can restrict execution to approved programs in tightly managed environments. These mechanisms can be powerful, but they should not become excuses to run unsupported software, grant unnecessary privilege, or ignore known vulnerabilities.
An alert is evidence to investigate. Repeatedly dismissing protection or creating broad exclusions simply to make an application run can remove both a control and a source of diagnostic evidence.
A backup is not proven until restoration works
Backups can preserve availability after ransomware, accidental deletion, corruption, or hardware failure. But a copy that is always writable from the compromised endpoint may be damaged by the same event. Synchronization can also reproduce deletions or encrypted files rather than provide a historical recovery point.
A useful recovery design asks whether the copy is recent enough, sufficiently independent from the original failure, protected against unauthorized modification, and actually restorable. A periodic restore test turns “backup completed” into evidence that recovery can succeed.
Cloud synchronization succeeds perfectly—and preserves the ransomware damage
A laptop synchronizes its working folder to a cloud service. Ransomware encrypts the local files, and the synchronization client uploads the changed encrypted versions. The sync status reports success.
This is a counterexample to the assumption that synchronization automatically equals backup. The security requirement is recoverability from an earlier trustworthy state. Version history, protected backups, offline or logically separated copies, and tested restoration can address that requirement depending on the environment.
Protect both the device and the authenticated session
Screen locking reduces misuse of an unattended active session. Secure storage, inventory, room or cable controls, and lost-device procedures reduce unauthorized possession and improve response. Mobile management may support remote actions according to organizational policy.
Physical controls and encryption solve different parts of the same problem. Physical safeguards reduce the chance or duration of unauthorized possession; encryption reduces data exposure if possession is lost. Neither makes the other unnecessary.
Every meaningful control should have evidence, a positive test, and a negative test
| Control | State evidence | Positive test | Negative/security test |
|---|---|---|---|
| Firewall SSH rule | Rule is active on intended profile | Approved admin source connects | Guest source remains denied |
| MFA | Account policy shows required factors | Authorized user completes sign-in | Password alone is insufficient |
| Disk encryption | Volume reports protected state; recovery managed | Normal authorized unlock works | Unauthorized offline access lacks plaintext data |
| Patch | Installed build/version includes fix | Required application still operates | Old vulnerable version is no longer present |
| Least privilege | Routine account lacks admin membership | Normal task succeeds | Protected change requires authorized elevation |
| Backup | Protected recovery point exists | Restore retrieves usable data | Working-copy deletion does not erase all recovery options |
Swipe horizontally to see the full table.
A security change passes the blocked test but fails the user
A new firewall policy successfully blocks an unwanted inbound service. The administrator records the negative test as a success and closes the change. Later, users discover that a required management application also fails because its legitimate traffic used the same overly broad blocked path.
The security control was not fully verified. A negative test proved restriction, but no positive test proved authorized availability. The repair is to narrow the rule around the intended service and sources, then rerun both directions of verification. Security is stronger when the boundary is precise rather than simply restrictive.
Do not claim more than the security evidence proves
App works when firewall is off
Policy is relevant. It does not prove the correct final state is “firewall disabled.”
MFA is enabled
It strengthens authentication but does not prove phishing, malware, or session theft is impossible.
Disk is encrypted
Protects a specific at-rest condition; it does not protect data already accessible in an unlocked session.
Updater says current
Useful, but installed version/build and policy evidence may provide stronger confirmation.
Backup job succeeded
Does not prove the copy is independent, recent enough, or restorable.
Site uses HTTPS
Does not prove the site's content or operator is trustworthy.
24 Topic 1.4 securing-my-device flashcards
Practice control selection, mechanism boundaries, narrow configuration, and verification instead of memorizing a disconnected list of security features.
Preserve evidence before making broad security changes
Security troubleshooting can destroy its own evidence. Rebooting, clearing logs, deleting certificates, disabling protection, resetting policy, or uninstalling an endpoint agent may make a symptom disappear while erasing the information needed to understand why it happened.
Record the starting state when practical: affected user, network profile, relevant rule or policy, application/version, alert text, certificate details, update status, and exact failing task. Then change one justified variable. This makes the result interpretable and reduces the chance of replacing one problem with several hidden changes.
Use this sequence when an AP Networking scenario asks how to secure an endpoint
- Requirement: State the security need identified in Topic 1.3.
- Mechanism: Choose a control that interrupts the relevant threat path.
- Scope: Apply the minimum permissions, traffic, software, identity, or data boundary needed.
- State evidence: Identify what proves the control is actually active.
- Positive verification: Prove the authorized task still works.
- Negative verification: Prove the unauthorized behavior remains blocked.
- Recovery: Know how to reverse or recover from the change if it causes an unintended failure.
A complete answer connects the security need to mechanism and verification
Need: a management service should be reachable only from the approved administrator network. Control: apply a host firewall rule limited to the required service and approved source range. Mechanism: the rule removes unnecessary inbound paths while retaining the authorized management path. Positive verification: connect from the approved administrator source. Negative verification: attempt the same connection from an unapproved network and confirm it remains denied.
This is stronger than “enable the firewall” because every part of the answer is tied to the original requirement and produces observable evidence.
Security and connectivity must both survive the final verification
A secure endpoint still needs correct addressing, gateway reachability, DNS, and application connectivity. A perfectly connected endpoint can still expose unnecessary services or excessive privileges. Return to Topic 1.1 when a control creates a connectivity symptom, review the security requirement in Topic 1.3, and use the Unit 1 Practice Test to apply the full chain to unfamiliar scenarios.