Device placement, security zones and attack surface

Objective 3.2 in this course covers enterprise infrastructure — CompTIA's scope note for it applies security principles to infrastructure considerations, control selection and secure communication and access. This lesson takes placement and zones; the appliances themselves are the next lesson, and secure communication the one after.

Why this matters

A control in the wrong place is not a weaker control — it is often no control at all. An IPS that cannot see the traffic it is supposed to inspect, a firewall downstream of the path an attacker actually uses, a sensor on a switch port that receives no mirrored traffic: each of these looks correct in an inventory and does nothing.

The exam builds scenarios exactly here. You are given a described network and a requirement, and asked where something should go. That is answerable mechanically once you know the three questions to ask.

The lesson

Placement, security zones, and what a screened subnet is actually for

A security zone is a region of the network whose members share a trust level and are separated from other zones by a control point. The classic set:

• Untrusted — the internet, and anything you do not administer.
• Screened subnet — CompTIA's current term for what was long called a DMZ. It holds services that must be reachable from the internet: web servers, mail gateways, reverse proxies, VPN concentrators.
• Internal/trusted — user devices, internal applications, file services.
• Restricted/management — domain controllers, backup infrastructure, device management interfaces, the SIEM. Higher trust than general internal.
• Guest and IoT/OT — lower trust than internal, deliberately isolated.

The purpose of the screened subnet is precise and worth stating exactly: it is where you put a service that must accept connections from an untrusted network, so that compromising that service does not give the attacker a position inside the trusted zone. Traffic from the internet reaches the screened subnet; traffic from the screened subnet into internal is tightly restricted and usually initiated the other way round.

The design failure the exam tests: a web server placed on the internal network and simply port-forwarded to. It works, it serves pages, and the first vulnerability in it puts an attacker on your internal network with no further effort.

The three questions that answer any placement question:

1. What traffic must this device see? A control can only act on traffic that passes through it — or is copied to it.
2. What is on each side of it? A device between two zones enforces the boundary between those zones and no others.
3. What happens to traffic if it fails? Which is the next section.

Connectivity, failure modes, and fail-open versus fail-closed

Every inline device has a behaviour when it fails, and choosing it is a security decision that the exam states as a trade between availability and confidentiality.

• Fail-open (fail-safe for availability): traffic continues to flow when the device fails. The service stays up; the control is absent while it is down.
• Fail-closed (fail-secure): traffic stops when the device fails. The control is never bypassed; the service is down.

Which is correct depends entirely on what the device protects. A firewall in front of a payment system should generally fail closed — passing uninspected traffic to a cardholder environment is worse than an outage. An inline IPS in front of a hospital's clinical systems may need to fail open, because the availability of the system is itself a safety property.

The same language appears for physical controls, and the vocabulary flips in a way that catches people out: an electrically controlled door that is fail-safe unlocks on power loss (safe for the people inside), and one that is fail-secure locks (secure for the assets). Fire regulations usually dictate the answer for egress doors, which is a good example of a non-security requirement deciding a security control.

Related connectivity choices: redundant paths so a single link failure does not isolate a zone, and out-of-band management, where administration happens on a physically or logically separate network. Out-of-band management matters twice — it lets you reach a device when the production network is down, and it keeps management interfaces off the network users are on, which is where most attacks against them come from.

Active versus passive monitoring, and inline versus tap

Two pairs that get conflated. Keep them separate.

Inline versus out-of-band (tap/SPAN) is about where the device sits:

• Inline — traffic physically passes through the device. It can block. It can also fail and take the link with it, and it adds latency.
• Tap or SPAN port — the device receives a copy of the traffic. It cannot block, only observe and alert. It cannot break the link, and it adds no latency.

This is the technical reason an IPS must be inline and an IDS need not be: prevention requires being in the path.

Active versus passive is about whether the device generates traffic of its own:

• Passive monitoring observes what is already there. Safe for fragile devices, which is why it is the answer for OT and ICS.
• Active monitoring probes — scans, queries, synthetic transactions. It produces richer and more current data, and it can disrupt sensitive equipment.

A tap placement that people get wrong: placing a sensor inside the firewall sees only what the firewall already permitted, so it will never show you what was blocked; placing it outside sees the full internet noise and will bury you. Many designs use both, for different questions.

Device attributes, and choosing where a control belongs

CompTIA asks you to weigh device attributes when selecting and placing controls:

• Inline or tap/monitor — decided by whether it must block.
• Active or passive — decided by whether probing is safe here.
• Failure mode — decided by whether availability or confidentiality wins.
• Throughput and latency — an inspection device that cannot handle the link speed becomes the bottleneck, and decryption in particular is expensive.
• Visibility into encrypted traffic — most traffic is encrypted, so an inspection device sees metadata only unless it terminates TLS, which has privacy, performance and certificate-management consequences.

A worked example of the reasoning, which is the shape of the exam question: "We need to block exploitation attempts against our public web application, without risking an outage if the appliance fails, and we must see the request bodies." Blocking requires inline. Seeing bodies over HTTPS requires TLS termination, which points to a reverse proxy or WAF rather than a network IPS. Avoiding an outage on failure points to redundant appliances rather than to fail-open, because fail-open would defeat the blocking requirement. The answer is a pair of WAFs in front of the application in the screened subnet.

Drawing the zone diagram the exam question describes in words

A method that turns a paragraph into an answer:

1. List the actors. Internet users, remote staff, internal staff, partners, administrators, the devices themselves.
2. List the assets and give each a trust level. Public web app, internal application, database, domain controller, backup store, OT devices.
3. Draw the required flows — who must reach what, in which direction, and who initiates.
4. Put a boundary wherever two different trust levels meet, and decide what the control at that boundary is.
5. Check the reverse direction. The commonest real finding is a zone that correctly restricts inbound traffic and permits anything outbound, which is exactly what C2 and exfiltration need.

Two principles to apply as you go. Defence in depth: more than one control between an attacker and an asset, so that one failure is not total — a firewall and host hardening and least privilege and monitoring, not any one of them. And least privilege applied to the network, meaning flows are permitted explicitly rather than denied explicitly, because a deny list of known-bad destinations is default-allow and cannot keep up.

If a scenario mentions a database reachable from the user network, an administrative interface exposed to the internet, or unrestricted outbound traffic from a server segment, those are the findings the question is about.

What to take into the exam

• The screened subnet exists so that compromising an internet-facing service does not put the attacker inside the trusted zone.
• IPS must be inline because blocking requires being in the path; IDS can sit on a tap or SPAN.
• Passive monitoring is the safe choice for fragile OT devices; active probing can knock them over.
• Fail-open preserves availability and drops the control; fail-closed preserves the control and drops the service. Choose by what the device protects.
• For physical doors, fail-safe unlocks and fail-secure locks — the opposite intuition from network devices.
• Unrestricted outbound traffic is the boundary failure people forget, and it is what C2 and exfiltration rely on.