Device placement, security zones, diversity and failure modes

Objective 3.2 is a given a scenario objective: you are handed a described network and asked to manage its architecture so that it protects the infrastructure. It has three lessons. This one takes the infrastructure decisions -- where things go, how much is exposed, how alike the parts are and what happens when one fails. Secure communication and zero trust architecture are the next two.

Why this matters

A control in the wrong place is not a weaker control -- it is often no control at all. A prevention device that cannot see the traffic it is meant to inspect, a firewall downstream of the path an attacker actually uses, a sensor on a port that receives no copied traffic: each looks correct in an inventory and does nothing.

The exam builds scenarios exactly here. You are given a network in words and a requirement, and asked where something should go or what is wrong. That is answerable mechanically once you know which questions to ask.

The lesson

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

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

• Untrusted -- the internet, and anything you do not administer.
• Screened subnet -- the 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, remote access gateways.
• Internal -- user devices, internal applications, file services.
• Restricted or management -- directory servers, backup infrastructure, management interfaces, the SIEM. Higher trust than general internal.
• Guest and OT -- deliberately isolated from internal.

The purpose of the screened subnet is precise: 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 it into internal is tightly restricted.

The design failure the exam tests: a web server on the internal network, port-forwarded from the internet. It works, it serves pages, and the first vulnerability in it puts an attacker on your internal network.

Three questions answer most placement questions:

1. What traffic must this device see? A control can only act on traffic that passes through it. A device that must block has to sit inline; one that only observes can receive a copy of the traffic instead.
2. What is on each side of it? A device between two zones enforces that boundary and no other.
3. What happens to traffic if it fails? That is the failure-modes section.

A worked example: "Block exploitation attempts against our public web application, and inspect the request bodies." Blocking requires inline; reading bodies over HTTPS requires terminating TLS, which points to a web application firewall or reverse proxy in front of the application, in the screened subnet.

Attack surface as a number you can reduce, and how to state it

The attack surface is everything an attacker could interact with: exposed services and ports, internet-facing hosts, management interfaces, accounts that can log in remotely, APIs, wireless networks, third-party connections, and the people who can be phished. Treated as a vague idea it never shrinks. Treated as an inventory with counts, it can be managed:

• how many hosts and services are reachable from the internet;
• how many listening ports each server exposes beyond what its role needs;
• how many accounts hold administrative rights, and how many can log in remotely;
• how many management interfaces are reachable from the user network.

Reduction then follows familiar moves: remove what is not needed, disable unused services and default accounts, consolidate many exposed entry points behind one well-defended gateway, segment so that more of the estate is unreachable from where attackers start, and restrict management to a dedicated network.

The habit the exam rewards is stating it as a measurable change: "internet-facing services reduced from fourteen to three; administrative accounts from forty to nine". A number you can measure again next quarter is a control you can manage; "we hardened the perimeter" is not.

Diversity: why two vendors fail differently and one fails everywhere at once

Diversity means not building every layer from the same product. If both of your firewall layers come from one vendor and run the same software, a single vulnerability or one bad update defeats both at once -- a common mode failure. Two different vendors are unlikely to share the same flaw on the same day, so an attacker must defeat two different things, and a faulty update stops at one layer.

That is defence in depth applied honestly: layers only add protection if they do not all fail for the same reason.

The cost is real and the exam expects you to name it: two products mean two configuration languages, two patch cycles, two skill sets and two sets of vulnerabilities to track. Poorly run diversity is less secure than a well-run single platform, because the second product is the one nobody configures carefully. Diversity is most defensible where a failure would be total -- the outer boundary, identity, and the systems that recover everything else. Lesson 27 applies the same reasoning to platforms and resilience.

Failure modes: fail-open versus fail-closed, and who gets to decide

Every inline device has a behaviour when it fails, and choosing it is a security decision:

• Fail-open: traffic keeps flowing when the device fails. The service stays up; the control is absent while it is down.
• Fail-closed: traffic stops when the device fails. The control is never bypassed; the service is down.

Which is right depends on what the device protects. A firewall in front of a payment environment should usually fail closed -- uninspected traffic into cardholder systems is worse than an outage. An inline inspection device in front of clinical systems may need to fail open, because the system's availability is itself a safety property. Where neither outcome is acceptable, the answer is redundant devices, not a failure mode.

The same language applies to physical controls, and the intuition flips: a door that is fail-safe unlocks on power loss, protecting the people inside, and one that is fail-secure locks, protecting the assets. Fire safety rules usually decide this for exit doors.

Who gets to decide is part of the topic. It is not the engineer installing the device, and it should not be a vendor default nobody read. Choosing between an outage and an unprotected window is a risk decision, so it belongs to the owner of the system the device protects, informed by security and recorded so that it can be reviewed. A failure mode nobody chose is a finding.

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, directory server, 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 trust levels meet, and decide what the control at that boundary is and how it fails.
5. Check the reverse direction. The commonest real finding is a zone that restricts inbound traffic and permits anything outbound, which is exactly what command-and-control and data exfiltration need.

Apply least privilege to the network as you go: flows are allowed explicitly and everything else is denied, because a 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.
• A device that must block has to be inline; one that only watches can take a copy of the traffic.
• Attack surface is managed as counts you can measure and reduce: remove, disable, consolidate, segment, restrict.
• Diversity stops one flaw or one bad update defeating every layer, at the cost of running more than one platform well.
• Fail-open keeps the service and drops the control; fail-closed does the reverse. The system owner decides, and redundancy avoids the choice.
• Unrestricted outbound traffic is the boundary failure people forget.