CompTIA Security+ SY0-801 Securing Infrastructure: Zones, Zero Trust, VPNs and Failure Modes

Device placement decides what a security device can see and whether it can stop anything; security zones decide which systems can talk to each other without passing a control. Both are the first questions to ask when you protect infrastructure: a well-configured device in the wrong place, or a perfect server inside the wrong zone, gives little protection.

Inline versus passive placement

A device can only block traffic that physically passes through it. Firewalls, an intrusion prevention system (IPS), a web application firewall (WAF) and web content filters are deployed inline: every packet crosses the device, so it can drop the bad ones. An intrusion detection system (IDS) sensor is usually passive: a SPAN (mirror) port or a network tap sends it a copy of the traffic, so it can alert but not block. An IPS connected to a SPAN port or tap is, in effect, an IDS.

Placement also limits visibility. A sensor sees only the segments it is attached to. Traffic between two servers in the same VLAN is switched locally (east-west traffic) and never crosses a perimeter link, so a sensor on that link misses it even when its signatures are perfect. If a detection works in one location and silently fails in another, suspect placement before signatures or thresholds. Inline devices that must block internet threats belong where all inbound traffic passes, typically just behind the edge firewall; a WAF sits directly in front of the web applications it protects.

Security zones

A security zone groups systems with the same trust level and exposure, and the boundaries between zones are where firewalls and access rules are enforced. Hosts inside one zone can usually reach each other without passing that control, which is why the zone choice matters as much as the rules.

Two decisions combine when you design a flow between zones. First, sensitive back-end systems (for example the database behind a public web application) do not share the exposed zone, so a compromised front end does not land the attacker next to the data. Second, each inter-zone rule is scoped to the exact source, destination and port: "web server to database port" rather than "whole screened subnet to database". Getting only one of the two right still leaves a path open. Low-trust devices that share the employee zone become a launch point for scanning laptops; moving them to their own zone with narrow rules contains them while still letting them reach their management servers.

Reducing attack surface means removing exposure that is not needed; diversity means building layers that do not share the same weakness. Both are infrastructure decisions, and both are easy to confuse with controls that merely make an exposed system harder to attack.

Attack surface

The attack surface is everything an attacker can reach: listening services, interfaces, internet-facing appliances, open ports and standing accounts. A control that leaves the service reachable (MFA, an IPS signature, a firmware upgrade, a nonstandard port) may lower risk, but it does not shrink the attack surface. Typical reductions:

• Unbind or disable what nobody uses from that side: management portals and SSH on a gateway's public interface when administrators only manage it internally.
• Consolidate duplicate entry points: one central remote-access gateway instead of an appliance with a public address at every branch.
• Remove exposure that serves an occasional task and replace it with access granted on request, rather than an always-on path. A standing vendor VPN account is itself attack surface; an IP allowlist does not work when the vendor's locations change.

Moving a service to a nonstandard port hides nothing from a scanner, so it is not an attack-surface reduction.

Diversity

Layers only add protection if they fail independently. Diversity uses different vendors, technologies or controls for different layers, so one flaw or one evasion technique cannot defeat them all at once. Diversity is not the same as defense in depth:

Layers that share a common component have depth without diversity, and the shared part can be hidden: different brand names on the box do not help if both products embed the same underlying engine or library, because whatever defeats that component defeats every layer built on it. More copies of the same layer repeat the weakness, and redundancy protects against a device failing, not against a flaw common to every device. The price of diversity is operational: separate consoles, separate update cycles and separate skills, which is exactly what single-vendor consolidation would have saved. (Platform and site diversity for availability are covered in the resilience objective.)

A Zero Trust architecture grants each access request only after checking the user, the device and the requested application, every time, regardless of the network the request comes from. Network location earns no implicit trust: a request from the office is evaluated like one from a café. (Zero Trust principles are covered in objective 1.1; this objective is about applying them to protect infrastructure. The component that makes each decision is often called the policy engine, and the point that enforces it the policy enforcement point.)

User authentication

Zero Trust authenticates identity on every access request, not once at the network edge or when a VPN connects, and a source address range is never a substitute for user authentication. A policy that requires MFA only from outside the corporate IP range still trusts the internal network implicitly; the Zero Trust fix is strong authentication on every sign-in, on any network. Authentication strength alone is not enough either: a stolen session token carries the result of a past MFA check, so strengthening the initial sign-in does not stop token replay. Continuous evaluation of signals such as location, device and behavior during the session, with the ability to revoke tokens when they change, does.

Device management: health and inventory

Health and inventory are separate checks, and a scenario usually tells you which one failed by holding everything else constant. An enrolled laptop with endpoint protection switched off fails health; a personal tablet with a clean scan and a correct MFA code fails inventory. To recognize enrolled devices wherever they connect, the policy engine needs an identity it can verify on each request, normally a device certificate whose private key is protected on the device. MAC addresses, hostnames and DHCP-assigned IP addresses are spoofable or meaningless across the internet.

Because the device is evaluated separately from the user, a lost or stolen laptop is handled by revoking that device's enrollment and certificate: it is denied everywhere, while the user keeps working from a replacement. Acting on the user instead stops legitimate work, and acting on network identifiers targets something the thief can change. A device that fails health does not have to be cut off entirely: Zero Trust policy is per resource, so a noncompliant device can be denied sensitive applications while still reaching patching and remediation services, which lets users fix it themselves.

Application access control

Zero Trust connects a user to the specific applications they are authorized for, usually through a Zero Trust network access (ZTNA) broker or proxy, rather than to the network segment where they run. A remote-access VPN, even with tight firewall rules, still gives the device a network-level connection to internal subnets; ZTNA brokers a session to the published application only, so an unmanaged contractor laptop can reach one ticketing application without ever joining the internal network. A per-application scope also explains why a ping to the application's server fails and why another application on the same subnet is unreachable: those were never published to that user.

A virtual private network (VPN) builds an encrypted tunnel across an untrusted network, either from one remote device (remote access) or between two sites (site-to-site), and the tunnel's configuration decides what traffic is protected and inspected.

Remote access and site-to-site

A remote-access VPN connects one user's device to the organization through a VPN client (often IPsec or TLS) or a clientless TLS portal that publishes selected web applications in the browser. A site-to-site VPN joins two networks gateway to gateway and is invisible to users; it does not route an individual remote worker's traffic. Remote access also covers remote desktop and jump servers. Remote desktop services are a frequent attack target, so they are not exposed directly to the internet; they are reached through the VPN, a remote desktop gateway or a hardened jump server that enforces strong authentication and logs each session. Whichever method is used, the remote session should land on as little of the network as the user needs (see the next section).

Full tunnel versus split tunnel

If browsing must pass an on-premises proxy, only a full tunnel delivers it there. When a concentrator is saturated and no hardware can be bought, a split tunnel helps, but what you exclude matters: high-volume traffic to a trusted external service that already protects itself in transit is the reasonable candidate to send direct, while traffic to internal resources must stay in the tunnel. Tuning the tunnel itself does not reduce how much traffic it has to carry.

Tunneling protocols

IPsec has two security protocols and two modes, and each choice controls something different:

So confidentiality requires ESP, and hiding internal addresses also requires tunnel mode. A capture showing a verified integrity check but readable payloads points to AH. IKE negotiates the keys and security associations but carries no data. GRE encapsulates almost anything, including multicast and routing-protocol traffic, inside unicast packets, but it encrypts nothing. Policy-based IPsec tunnels match unicast traffic, so routing updates that use multicast are carried as GRE inside IPsec ESP: GRE carries the multicast, ESP encrypts the GRE packets. L2TP also provides no encryption by itself and is normally paired with IPsec. TLS-based tunnels (SSL/TLS VPNs) are common for remote users because TLS passes through most firewalls and proxies.

Secure remote access is only as good as the accounts behind it, so every remote user, employee or third party, gets individual access scoped to what they need and only for as long as they need it.

Least privilege for remote users has two dimensions, and a scenario often gets only one of them wrong:

• Scope: access reaches only the systems the job involves, not the whole segment around them and not every internal network.
• Time: access ends when the job ends, so a time-boxed task gets access that expires with it rather than standing access with no end date.

User management keeps those limits true over time. Contractor and partner accounts should expire automatically on the contract end date, because removing access by memory fails and leaves dormant but valid accounts behind. MFA, password expiry and session timeouts protect an account that is still valid; none of them removes access from someone who is no longer entitled to it. Shared vendor accounts remove individual accountability and are never the least-privilege choice.

When one VPN profile lets every user reach every subnet, access can be narrowed without new hardware by applying role-based access policies on the existing VPN, tied to directory groups, so each user reaches what their own role needs. The policy has to be as fine-grained as the roles: grouping by a coarser unit still over-grants when people in that unit need different systems. Authentication strength decides who connects, not what they can reach afterwards.

End-to-end encryption means only the communicating endpoints hold the keys, and secure file transfer means credentials and file contents travel encrypted; both protect data in transit, but in different ways and with different trade-offs.

End-to-end encrypted messaging

In an end-to-end encrypted (E2EE) messaging platform, messages are encrypted on the sender's device and decrypted only on the recipients' devices. The provider's servers relay and store ciphertext they cannot read.

The security gain is also an operational constraint: no server, gateway or TLS-inspecting proxy in the path can read E2EE content, so server-side archiving, DLP scanning or proxy inspection stop working. Organizations that must archive or scan business messages (for regulators, for example) and will not weaken the encryption move those controls to the place where messages are readable: archiving and DLP agents on managed endpoints.

File transfer

The names mislead: SFTP is not FTP over anything. It is an SSH file-transfer protocol with its own commands, so a client that speaks only FTP (even one that can secure an FTP session with TLS) needs FTPS. Conversely, when a firewall permits a single inbound port and forbids extra data-port ranges, SFTP fits and FTPS does not. HTTP, FTP and TFTP all leave credentials and data readable in a packet capture.

Out-of-band (OOB) management is a separate path for administering network and server devices, such as a dedicated management network with console servers or a cellular link, that does not depend on the production network and is unreachable from user networks.

It solves two problems at once. Availability: when a core switch fails and production is down, in-band SSH, jump servers and site-to-site VPNs are all down with it, while an OOB path still reaches device consoles so engineers can restore service. Isolation: management interfaces are a high-value target, and a user VLAN should never be able to reach them, even with a stolen admin password.

The OOB network itself must be protected as a privileged zone: strong authentication, restricted access and logging, since anyone on it can reach every device console.

Security Service Edge (SSE) is a cloud-delivered bundle of security services, chiefly a secure web gateway (SWG), a cloud access security broker (CASB) and Zero Trust network access (ZTNA), often with firewall as a service (FWaaS) and DLP, enforced at provider points of presence close to each user.

• SWG: filters and inspects web traffic (URL filtering, malware scanning).
• CASB: gives visibility and control over SaaS use (shadow IT discovery, data controls in sanctioned apps).
• ZTNA: per-application access to private applications without a network-level VPN.

SSE exists because users and applications moved out of the data center: backhauling remote users' traffic to an on-premises firewall adds latency and a choke point, while SSE applies the same policy wherever the user is. Secure Access Service Edge (SASE) is SSE plus SD-WAN networking in one service.

So an organization that already runs SD-WAN and wants to keep it adds SSE, not full SASE. A standalone CASB covers SaaS control but not web filtering or private-application access, and branch firewalls miss users at home or travelling.

Identity management for infrastructure means service accounts whose passwords nobody handles, administrator accounts used only for administration, and permissions that are removed when they stop being needed.

Group Managed Service Accounts

Services need domain identities, and ordinary domain user accounts used for services tend to get passwords that are known to administrators and never changed, because changing them means updating every server that runs the service at once. A Group Managed Service Account (gMSA) is an Active Directory account whose long, random password is generated and rotated automatically by Active Directory (by default every 30 days) and can be retrieved only by the principals (usually a group of computers) authorized to use it. No administrator ever knows it.

A load-balanced service running on several servers under one identity is the classic gMSA case: an sMSA is limited to one computer, and per-server computer accounts would be several different identities.

Least privilege access accounts

Administrators get two accounts: a standard account for email, browsing and daily work, and a separate privileged account used only for administrative tasks. Email and the web are where malicious content arrives, and anything it launches runs with the signed-in account's rights, so admin rights must never be present in those sessions. Having the second account is not the control; using it only for administration is. Controls that harden or watch the sign-in do not remove admin rights from an everyday session. The privileged account itself is scoped: rights delegated for exactly the tasks the role needs on exactly the objects it manages (delegation on a specific organizational unit, for example) rather than Domain Admins membership or full control.

Privilege creep

Privilege creep is the gradual accumulation of permissions as people change jobs and keep their old access while gaining new access. It has a preventive fix and a detective one:

• Prevent: remove prior-role access as part of every transfer, and grant access through job-role security groups instead of individual one-off grants, so leaving the old role's group removes the old role's permissions.
• Detect and clean up: periodic access recertification, in which managers or resource owners confirm each user's current access and revoke the rest, finds creep that already exists.

A fix for privilege creep must actually remove rights from people who are still active: controls that only govern new grants, or only target dormant accounts, or only record or authenticate activity, leave existing excess access in place.

A failure mode is what a security control does when it breaks: keep the protected thing available without the control, or stop it to keep it protected. Neither is always right; the choice follows the business priority for that system.

Different systems in one organization can, and often should, use different modes: an inline control protecting an always-on service may fail open while one guarding regulated data fails closed. An inline device that stops passing traffic when its service crashes is failing closed; if management ranks availability above filtering and will not buy a redundant peer, the configuration change is to fail open. Taking a device out of line is not a failure mode at all: it stops enforcement permanently, not just during a fault. Two neighbouring terms are different ideas: fail-soft is graceful degradation (reduced function rather than total failure) and failover is switching to a redundant component, which removes the dilemma but needs extra hardware.