Network Security Architecture: Zero Trust, Defense in Depth, Segmentation

A flat network is one where every device can reach every other device: laptops, servers, printers, and cameras all sit in one big open space. Flat networks are easy to build and easy to attack. The attacker's problem is only getting in once; after that, nothing stands between the first compromised machine and everything else.

Consider a concrete scenario. An employee at a small firm opens a phishing attachment and malware lands on her laptop. On a flat network, that laptop can reach the finance server, the HR database, the backup system, and the building's security cameras directly, because nothing in the network's design says otherwise. The attacker scans, finds an unpatched file server, and within hours holds the company's data. The initial phish was the entry; the flat network did the rest. This spreading from an initial foothold to other systems is called lateral movement, and limiting it is the central goal of network security architecture.

Network segmentation answers this by dividing the network into smaller zones and controlling the traffic allowed between them. If workstations, servers, and cameras live in separate segments, the compromised laptop can no longer reach the finance server directly: its traffic must cross a control point, where policy can deny it and monitoring can see the attempt. Segmentation does not prevent the first compromise; it contains the blast radius so one infected laptop stays one infected laptop.

It helps to sort controls by the stage of an attack they act on, because each answers a different question. Segmentation is a containment control, and it is neither a prevention control nor a recovery control:

Offline backups, for example, do nothing to stop malware spreading from the infected laptop; they let the organization restore what the malware damaged. Training and login hardening at the entry point act mainly before the foothold; once an attacker is inside, what limits the spread is containment, although strong authentication on internal systems also makes moving between them with stolen credentials harder. The rest of this lesson covers the tools that create segments, from firewall zones to VLANs to micro-segmentation, and the design philosophies, Defense in Depth and Zero Trust, that decide how strictly the boundaries are enforced.

The classic way to segment with a firewall is to define zones: groups of networks that share a trust level, with rules governing what may pass between them. The simplest design has two zones: the trusted internal network, containing your users and systems, and the untrusted external world, meaning the internet. The default posture is that inside may initiate connections out, while unsolicited traffic from outside is denied.

That two-zone design breaks as soon as you run a public service. Your web server must accept connections from strangers on the internet, but placing it inside the trusted zone means every stranger's connection terminates next to your internal systems. The answer is a third zone: the DMZ, or demilitarized zone, a buffer segment between the untrusted internet and the trusted internal network where public-facing servers live.

The logic to remember: if an attacker compromises the web server, they are standing in the DMZ, not inside your network. The firewall still blocks them from reaching internal systems, so the breach is contained in the buffer zone.

That containment holds only if the rules from the DMZ toward the internal network are narrow. Public servers often need something internal: a mail relay in the DMZ, for example, must hand incoming messages to the internal mail server. Apply least privilege to the firewall rule itself. The exception should name only the relay as the source, only the internal mail server as the destination, and only the mail-delivery port, with everything else from the DMZ denied. Every part of the rule you leave broad (more sources, more destinations, more ports) is a path a compromised DMZ host can use. And the fix for an awkward rule is never to move sensitive internal systems or data into the DMZ: that places them in the zone that strangers on the internet can already reach, which defeats the reason the DMZ exists. Exam stems that mention hosting a public-facing server or a segment between the internet and the internal network are describing the DMZ.

A VLAN (virtual local area network) segments a network logically rather than physically. A managed switch can be configured so that some of its ports belong to one VLAN and other ports to another; devices in different VLANs cannot talk directly at Layer 2 even though they are plugged into the same physical switch. Each VLAN is its own broadcast domain, and traffic between VLANs must pass through a router or firewall, which is exactly where you place the rules.

The value is separation without new hardware. A company can put finance on one VLAN, general staff on another, guest Wi-Fi on a third, and its IP cameras and printers on a fourth, all running over the same switches and cables. The guest VLAN can be allowed to reach only the internet; the camera VLAN can be allowed to reach only its recording server. Without VLANs, achieving that separation would require physically separate switches and cabling for each group.

Three cautions keep the concept honest. First, a VLAN is a Layer 2 construct: it separates broadcast domains, and its security value comes from forcing inter-VLAN traffic through a control point that enforces policy. If the router simply passes everything between VLANs unfiltered, you have organized the network but not secured it. Second, VLANs are configuration, so a misconfigured switch can leak traffic between segments. Third, a VLAN separates traffic by tagging it; it does not encrypt it. Frames inside a VLAN cross the shared switch in the clear, so confidentiality still needs encryption. A related practical point: because VLANs are a switch setting, creating or changing them needs no new cabling: moving a device between VLANs is a port reassignment, not a rewiring job.

The control point also defines what a VLAN cannot see. Traffic between two hosts in the same VLAN is switched directly at Layer 2 and never travels to the inter-VLAN router or firewall. That firewall therefore can neither block nor log it, and an intrusion prevention system at the network edge never sees it either. An intrusion detection sensor placed on the link between VLANs has the same blind spot: a compromised host scanning its own VLAN produces no traffic on that link, so the sensor raises no alert, not because the scan was harmless, but because the sensor never saw it. Filtering or monitoring traffic inside a VLAN needs a control at the hosts themselves, which is what micro-segmentation provides. For the exam, the recognition line is: VLANs provide logical segmentation at Layer 2, letting one physical switch behave as several isolated networks, with policy enforced only where traffic crosses between them.

Micro-segmentation takes the segmentation idea to its finest granularity: policy per individual workload, meaning each server, virtual machine, or application gets its own rules about exactly which other systems may talk to it, on which ports. Where zones separate the network into a few large regions and VLANs into groups of devices, micro-segmentation draws the boundary around each machine.

The problem it solves is traffic inside a segment. In a traditional design, two servers in the same data center segment can usually reach each other freely, so an attacker who compromises one server can move laterally to its neighbors without ever crossing a firewall. With micro-segmentation, the web server is allowed to reach the application server on one specific port, the application server may reach the database on another, and every other combination is denied, including web server directly to database. The compromised web server now has almost nowhere to go. Micro-segmentation is typically enforced in software, through host-based firewalls or the virtualization and cloud platform, rather than by a physical appliance, which is what makes per-workload policy practical at scale.

Keep the ladder in mind: zones, then VLANs, then micro-segmentation, each step smaller and stricter. Micro-segmentation also reappears later in this lesson as a key enabler of Zero Trust.

Defense in Depth is the principle of layering multiple, independent security controls so that no single control's failure exposes the asset. Any one control can fail: a firewall can be misconfigured, a user can be phished, an antivirus signature can miss new malware. Defense in Depth accepts that and arranges controls in series, so an attacker must defeat layer after layer, and each layer they hit is another chance to stop them, slow them, or at least detect them.

A typical layered stack, from the outside in: policies and security awareness training shape user behavior; physical security controls who can touch the equipment; the perimeter firewall filters what enters the network; segmentation limits movement inside it; endpoint protection defends each device; authentication and least-privilege access control who can use each application; and encryption protects the data itself. The layers are deliberately of different kinds, mixing technical, physical, and administrative controls, because unrelated controls do not share the same weaknesses.

Depth needs layers that differ in kind and in position. Duplicating one control at one position is redundancy, not depth. A second firewall in series at the network edge adds little depth. It filters the same traffic at the same point using the same kind of rule, so it is mostly redundancy: it covers a device failure, and a different vendor also avoids a single shared software flaw, but an attacker whose traffic the first firewall's policy allows is allowed by the second one too. An in-line intrusion prevention system at the same edge is partly different: it inspects the content of permitted traffic and can stop a known exploit arriving on an allowed port. It still sits at the same position, so it cannot stop an attacker who logs in with valid stolen credentials, or traffic that moves between internal systems and never crosses the edge. Redundancy protects against a device failing; depth protects against a control being bypassed. To add depth to an asset that already sits behind edge firewalls, add a different kind of control at a different position, such as authentication and authorization at the asset itself, encryption of its data, or monitoring of its activity.

Play the earlier phishing scenario against this stack. Awareness training reduces the chance the employee clicks; if she does, endpoint protection may catch the malware; if it does not, segmentation stops the laptop from reaching the finance server; if the attacker still reaches the database, encryption makes the stolen files unreadable, and monitoring has been generating alerts at every step. No layer was perfect; the depth was the defense. On the exam, stems that say no single point of failure, layered security, or multiple overlapping controls are describing Defense in Depth.

The traditional security architecture is often called castle-and-moat: build a strong perimeter around the network, inspect everything at the gate, and treat everything inside as trusted. The firewall is the moat; once a user or device is inside, whether physically in the office or connected by VPN, it moves largely unchallenged. Trust, in this model, is a function of network location: inside means trusted, outside means untrusted.

Three developments broke the model. First, the perimeter dissolved. Applications moved to the cloud, employees work from homes and coffee shops, and partners and contractors need access from everywhere, so inside stopped being a meaningful place: the resources are no longer inside, and neither are the users. Second, insiders and stolen credentials defeat a location-based defense by definition. A malicious employee is already past the moat, and an attacker who phishes a valid password and connects through the VPN is indistinguishable from a legitimate insider. Third, lateral movement: because the interior is trusted, one compromised endpoint gives an attacker a soft, open network to explore, which is exactly the flat-network failure from the start of this lesson.

The lesson to carry forward is precise: the perimeter model's fatal assumption is implicit trust based on network location. Every weakness above is that assumption failing in a different way. Zero Trust, next, is the architecture built by deleting that assumption, and exam questions frequently hinge on spotting it: any answer option that grants access because the request comes from the internal network is the castle-and-moat mistake.

Zero Trust is a security architecture built on one core principle: never trust, always verify. No user, device, or connection is trusted implicitly because of where it sits on the network. Being inside the corporate network, on the VPN, or in the data center earns nothing; every request for access must be verified before it is granted, every time.

The supporting ideas flow from that principle. Verify explicitly: authenticate and authorize every request based on evidence such as user identity, device health, and location, not on network position; strong authentication, including multi-factor authentication, is fundamental here. Least privilege: grant each verified identity access only to the specific resources it needs, and nothing more, so even a fully verified user cannot wander. Assume breach: design as if an attacker is already inside, which means containing lateral movement, monitoring traffic between internal systems as well as at the edge, and never treating the interior as safe. Micro-segmentation is a key enabler: by drawing enforcement boundaries around individual workloads, it creates the many small checkpoints at which every request can be verified, replacing the single big checkpoint at the perimeter.

Two clarifications prevent common exam mistakes. Zero Trust is an architecture and a set of principles, not a single product you can buy; vendors sell components, but Zero Trust is how you design. And Zero Trust does not mean no one gets access; it means access is granted per request, based on verification, to the minimum resource needed. Trust is never assumed, it is established, and it is re-established continuously rather than granted once at login and kept forever.

In practice, a Zero Trust access decision is two separate checks, and both must pass: verification (is this really the claimed user, on a healthy device?) and entitlement (does this user's role need this specific resource?). Verification is necessary but not sufficient. A request that passes MFA and every device check is still denied when the resource lies outside the role's need, because proving who you are does not change what you are allowed to reach. Adding more proof of identity, or recording the access, does not change that outcome: neither grants a permission the role lacks. Entitlement is also per resource: being allowed to use an application does not extend to the server it runs on or to direct reads of its underlying database.

Continuous evaluation means access already granted is re-evaluated against current signals, ideally on each request and in practice at least whenever a signal changes, rather than trusted for the rest of the session. Suppose a user passed every check at sign-in, and then an administrator disables the account mid-session, or the endpoint security agent reports the device as unhealthy. The next request is judged on the new signals and is denied, even though the earlier sign-in succeeded. Trust earned at login is a starting point, not a pass for the session.

Assume breach translates into controls that keep working after an attacker already has a foothold inside. That means controls on east-west traffic, between internal systems: filtering between workloads (micro-segmentation) and monitoring of internal traffic, so lateral movement is both blocked and seen. Controls that act before or at the edge, such as perimeter firewalls, perimeter penetration tests, or login hardening, are valuable but address keeping the attacker out, which assume breach treats as already failed. Recovery controls such as backups matter too, but they restore systems after damage rather than containing an attacker who is moving.

AI workloads fit the same segmentation and Zero Trust principles as any other system: training data stores and the clusters that train or serve models are crown-jewel assets, so they belong in their own segment, and the AI services that act on the network are identities that must be verified like any user. The reason is integrity. If an attacker who has compromised an ordinary internal host can write to the training data, they can poison the training data (data poisoning, a form of model poisoning), quietly changing what the model learns and later outputs, without ever touching the model itself.

The control that removes this path is a boundary around the AI segment with default-deny rules: only the flows the workload genuinely needs are allowed, such as the data pipeline writing to the training data store and the training cluster reading from it, and everything else is denied, including outbound internet access from the cluster. A user workstation or a general application server then has no network path to the data at all. Segmentation does not cover every route to poisoning, such as a compromised pipeline, an insider with legitimate access, or tainted upstream data, so integrity checks and provenance on the data remain separate layers (Defense in Depth). Other controls protect against different threats and leave this gap open:

Zero Trust also applies to the AI systems themselves. Chatbots, AI agents, and model-serving services that call other systems are non-human identities: each of their requests is authenticated and authorized on its own, and they receive only the permissions their function needs. They are not trusted because they run inside the corporate network, and a human passing MFA to talk to an AI assistant does not extend that verification to the assistant's own calls to databases or APIs: the user's sign-in may limit what the assistant does on their behalf, but it never replaces the assistant's own verification and least-privilege entitlements. An AI service with broad standing access is a single point that, if misused or manipulated, reaches everything it is allowed to reach, which is exactly why its entitlements must be narrow.

The exam's favorite question in this sub-domain is a contrast: given a description of behavior, identify which model it belongs to. This table is the study object.

Note what Zero Trust does not discard. Firewalls, zones, and DMZs still exist and still do useful work; Zero Trust removes the implicit trust behind them, not the controls themselves. Defense in Depth is fully compatible: Zero Trust is arguably Defense in Depth applied to trust decisions, adding verification as a layer at every boundary instead of only at the outer wall.

Run the phishing scenario one final time under Zero Trust. The attacker controls the employee's laptop, but reaching the finance system requires a verified request: the system checks identity and device health, challenges with multi-factor authentication, and the attacker fails. Even with a stolen password and a position inside the network, location buys nothing, least privilege caps what the account could reach anyway, and micro-segmentation blocks the direct path between laptop and database. Compromise of one endpoint no longer implies compromise of the organization, which is the whole point of the architecture.