Endpoint & Network Protection.

Convert your defense design into enforceable protections.

In Lesson 05: Defense in Depth, you learned that protection depends on different layers rather than one perfect product. Now we'll work out how to implement those layers conceptually around endpoints, network traffic, administrative access and recovery without assuming vendor-specific commands.

We start with an asset and its business purpose, add software and network protections, then test both what should be permitted and what should be denied. No production systems or configuration access are needed: all scenarios use fictional Northstar Services systems.

You cannot protect an endpoint you do not know exists.

Start with ownership, importance, software and exposure.

An endpoint is a device or workload that communicates with the environment: a laptop, a server, a virtual machine or a kiosk. Asset inventory records what exists, who maintains it, what applications run and how critical it is. A switch or firewall is infrastructure rather than a user endpoint, but it also needs an owner, a current configuration and maintenance.

Inventory is not simply a list of hostnames. Ask whether a device is managed, whether it still receives updates, what sensitive information it holds, and whether the business relies on it. Unknown systems can miss protective policies and create unexamined paths to important assets.

Hardening reduces unnecessary ways a system can be abused.

A secure baseline describes what a normal approved configuration should look like.

Hardening means removing unnecessary functionality and configuring the remaining system to reduce avoidable exposure. Examples include disabling unused services, restricting local administrator membership, enforcing appropriate screen locks, configuring logging and limiting software installation. A security baseline is the documented, tested starting configuration for a class of systems.

A baseline needs exceptions, owners and validation; one rigid setting does not fit every device. Changes to server services or endpoint policies can interrupt workflows, so technicians should evaluate operational requirements and use approved change controls instead of disabling unknown services on sight.

Patch the vulnerabilities that matter, with evidence and rollback.

Risk-based patching combines exploitability, exposure and business consequences.

A vulnerability is a weakness that could be exploited under certain circumstances. A software patch can correct such a weakness; firmware updates can address a device's lower-level software. A published severity score is useful context but does not automatically identify which device should be patched first. Consider internet exposure, the vulnerability's real exploitability, asset criticality and available compensating controls.

Safe patching includes inventory, a test group, maintenance approval, expected reboot or downtime, a recovery plan and verification after deployment. A reported 'patch installed' status may not prove the service restarted or the vulnerable component is no longer active. If a critical system cannot be patched immediately, document the owner, exposure, temporary restrictions and scheduled remediation.

Application control blocks unauthorized execution paths.

Allowlisting and least privilege complement endpoint detection.

Application allowlisting is a policy that permits only approved executables, scripts or code under defined conditions. This can stop an unfamiliar program before it runs. It is different from traditional malware detection, which attempts to recognize potentially harmful behavior or artifacts. The controls complement one another; neither eliminates the need to manage authorized software.

A strict allowlist can block legitimate tools, including administrative scripts, and must be piloted with audit-only observations before broad enforcement when supported. Pay attention to signed software, approved automation, controlled exceptions and an emergency recovery path. A program being 'signed' does not automatically mean it is safe or authorized.

Endpoint monitoring helps responders understand activity.

Detection is evidence to investigate—not a guarantee a compromise occurred.

EDR (Endpoint Detection and Response) collects endpoint information such as processes, file modifications, network activity and prevention actions. A security agent may block known malicious code, flag suspicious behavior or isolate a host when authorized. Antivirus and EDR products overlap in some capabilities, but detection and investigation are not the same as successful prevention.

Verify an alert's action before declaring impact: was a file detected, blocked, quarantined, executed or merely observed? Check coverage and agent health. An offline device or disabled sensor can create a visibility gap. The responsible team should plan response authority because isolating a workstation or production server can affect essential services.

Segmentation separates paths between different systems.

A VLAN label is not automatically a security barrier.

Network segmentation separates groups of assets and applies routing and access policies between them. A virtual LAN (VLAN) is a logical Layer 2 grouping. Inter-VLAN routing may still let devices communicate; meaningful segmentation requires appropriately enforced access rules at the boundary, along with validation of both permitted and prohibited flows.

East–west traffic is communication between systems within an organization, such as a workstation reaching a file server. North–south traffic commonly describes communication crossing the network perimeter. Segment policies should restrict unnecessary lateral paths while preserving approved dependencies; a misconfigured rule can either expose backup systems or prevent an essential application from working.

A firewall rule permits or denies defined traffic.

Least-privilege networking must be tested in both directions of policy.

A firewall policy commonly evaluates source, destination, protocol, port and direction, sometimes with application or identity context. For example, allowing a print server to accept a specific print protocol from staff networks is narrower than allowing every device to connect to every server. A rule that blocks one port does not guarantee an application cannot use another path.

Default deny limits paths unless specifically allowed, but a working service still needs the exact dependencies it uses: DNS, authentication, application endpoints, monitoring or time synchronization. Validate both a permitted flow and a forbidden flow after changes. A denied connection can also be caused by routing or name resolution, so a failure message alone does not prove the firewall is the enforcement point.

Management interfaces need stronger separation than ordinary users.

Restrict who can administer servers, switches and recovery systems.

Management access lets a principal change configurations, create accounts or affect recovery. Use dedicated management paths or administrative jump hosts where appropriate, require strong authentication, limit privileged roles and record approved changes. A jump host is a controlled system used by authorized administrators to reach sensitive systems, rather than allowing arbitrary user laptops direct management access.

A network rule that permits a connection is not the same as authorization in the target service. The destination still needs identity checks and appropriate resource permissions. Administrative exceptions should be documented, scoped and monitored; permanently unrestricted remote management makes a single compromised laptop much more consequential.

Protect recovery systems from the same attack paths.

Backup isolation and restore testing protect business continuity.

Backup repositories and recovery management consoles are high-value targets. If a compromised workstation can delete every backup, a single incident may become difficult to recover from. Controls may include separate administrative identities, immutable or offline copies, restrictive network paths, monitoring of backup changes and tested restore procedures.

A scheduled backup job reporting success is not proof that a restore will work. Check that the right data is protected, retained copies are usable, credentials and encryption keys are recoverable, and the service can be restored to an acceptable state. Backups address availability and integrity recovery; they do not undo a prior unauthorized disclosure.

Deploy controls safely with staged changes and rollback.

An effective security change must preserve required operations.

Before enforcing a new patch policy, allowlist or network restriction, identify the affected assets, owner, intended behavior and test cases. Use audit-only mode or a pilot group when supported, seek appropriate change approval, schedule validation and define a realistic rollback path. The process matters because a well-intended control that blocks critical traffic can become an availability incident.

A rollback should remove the accidental breakage without blindly deleting all protection. Record what changed, which tests passed, what failed and what monitoring will catch regressions. Distinguish a security event from a change-caused outage using timestamps, ownership and evidence rather than assuming every service interruption is an attack.

A dashboard claim is not the same as verified protection.

Use positive and negative tests to prove each control works.

A positive test confirms a required operation still works: payroll readers can view authorized reports, a print server reaches printers, or backups can be restored. A negative test confirms a prohibited operation fails: guest devices cannot reach internal admin interfaces, an ordinary user cannot edit switch configuration, or an unapproved executable is blocked. Both are necessary because security and availability depend on different outcomes.

Collect evidence from the right enforcement point. A 'connection failed' message is weaker proof of firewall isolation than matched rule logs and controlled connectivity tests, because a bad route or DNS failure could also explain it. Record the actor, affected asset, time, intended policy and outcome. Recheck after configuration changes or software updates.

Build an effective protection plan from a real requirement.

Protect important assets without breaking necessary operations.

The Endpoint & Network Protection Workbench uses fictional Northstar asset groups and access requirements. Choose an environment, inspect which flows are required and which paths expose sensitive systems, then select layered safeguards. The workbench shows specific covered risks and remaining limitations; it never configures a real firewall, endpoint, directory or backup platform.

The goal is not to turn every control on blindly. A good answer protects sensitive systems while preserving legitimate access, documents unresolved dependencies and names the tests that would validate the design. After the guided examples, Practice asks you to reason independently through different situations.

Secure the prohibited path. Keep the approved path working.

A guest network cannot reach a sensitive server. Is that because the firewall enforced a deny, or because DNS failed? A finance app will not start after allowlisting. Does that mean it is malicious, or does the policy need a scoped correction? Evidence from the real enforcement point and controlled positive and negative tests are how a defender tells the difference.

The following Identity & MFA Protection, Data Protection & Cryptography, and detection lessons build on these boundaries before you apply them in incident response.

Ground control choices in established guidance.

Everything required for Practice is taught here. The following official references offer additional context for platform configuration, maintenance and resilient infrastructure.