Network architecture, read the way an analyst reads it

Why this matters

An architect looks at a network diagram and sees how traffic is meant to flow. An analyst looks at the same diagram and asks a different question: where would I see this, and where am I blind?

That question decides whether an investigation is possible at all. If the only sensor sits at the internet edge, an attacker moving between two servers in the same subnet is invisible to you no matter how good your analysis is. No amount of skill recovers data that was never collected.

CySA+ asks about architecture in exactly this framing. Expect scenarios where the right answer is "you would not see that from there".

The lesson

Segmentation, zones and why east-west traffic matters

Segmentation divides a network into zones that are only supposed to talk to each other in defined ways — user devices, servers, management, guest, card data, industrial systems.

Two directions are worth naming clearly:

• North-south traffic crosses a boundary, typically between the organisation and the internet, or between two zones.
• East-west traffic moves within a zone: server to server, workstation to workstation.

Historically, defences were built almost entirely on north-south, because that was where the boundary was. It produced networks that were hard to enter and trivial to move around inside once entered — and lateral movement is precisely what an intrusion consists of after the first foothold.

For the analyst this has a direct consequence: the traffic you most want to see during an incident is usually the traffic least likely to be monitored. When a scenario says an attacker moved from a compromised workstation to a file server, ask what would have recorded that hop. Often the honest answer is the endpoint agent and the file server's own logs, because no network sensor sat between them.

Segmentation also changes the meaning of an observation. A connection from the user zone to the management zone might be routine in a flat network and a five-alarm finding in a segmented one. Knowing which network you are looking at is part of reading the evidence.

Where a sensor sees traffic and where it is blind

Every network sensor has a vantage point, and its vantage point is its limit.

• A tap or SPAN port sees what crosses that specific link. Traffic that never crosses it does not exist as far as that sensor is concerned.
• An inline device — firewall, IPS, proxy — sees what it is in the path of, and can also block. It sees nothing that routes around it.
• A host agent sees what happens on that host, including traffic that never leaves the machine and traffic that is decrypted at the endpoint.
• Cloud flow logs see connections between cloud resources, usually as metadata only.

Blind spots that show up repeatedly:

• Intra-VLAN traffic on the same switch, where there is nothing between the two hosts.
• Encrypted payloads, unless traffic is decrypted somewhere you control.
• Anything before the sensor — a device that was compromised elsewhere and brought into the network already owned.
• Asymmetric routing, where a sensor sees one direction of a conversation and draws confident conclusions from half a picture.
• Cloud and remote workers whose traffic never touches the corporate network at all, which after the shift to remote work is a very large fraction of it.

The productive habit is to draw your sensors onto the diagram, not your firewalls. What you can see is a different map from what you can block.

North-south chokepoints: proxies, gateways, egress

Despite everything above, boundary chokepoints remain enormously valuable, because almost every intrusion eventually needs to talk to something outside.

The high-value collection points:

• Web proxies record requested URLs, user agents, methods, response sizes and — critically — which user or host made the request. A proxy log is often the single richest source in an investigation.
• DNS resolvers see name lookups, including ones that never result in a connection. Because almost everything resolves a name first, DNS is the closest thing to a complete index of intent.
• Email gateways see the most common delivery route for an initial foothold, along with attachments and links.
• Egress filtering points record what was allowed out and, more usefully, what was denied. Denied outbound traffic is one of the most under-read sources available.
• VPN and remote access concentrators tie a session to an identity and a source address.

The mental model: the boundary is where intent becomes observable. Command and control, exfiltration, tool download and licence checks all have to cross it. An attacker who avoids it entirely is limited to what is already inside.

Cloud network plumbing an analyst meets in logs

Cloud networking uses different words for familiar things, and the exam expects the vocabulary.

• A VPC (or VNet) is your private network in a provider's infrastructure — the cloud equivalent of your own address space.
• Subnets within it are public or private depending on whether they have a route to an internet gateway.
• Security groups are stateful filters attached to workloads; network ACLs are stateless filters attached to subnets. The distinction matters in practice: a stateless rule that allows outbound needs a matching inbound rule for the reply.
• NAT gateways let private resources reach out without being reachable — and collapse many workloads behind one source address, which makes attribution from an external log much harder.
• Load balancers terminate connections, so the backend sees the balancer's address unless a forwarding header preserves the original.
• Flow logs record connection metadata: source, destination, ports, bytes, accept or reject. Not payload.
• Private endpoints and service links carry traffic to managed services without traversing the public internet, which means it will not appear where you might expect.

Two traps worth internalising. First, NAT and load balancing destroy source attribution unless you correlate with application logs. Second, the control plane is separate from the network: an attacker who takes a cloud identity may never send an interesting packet at all, because they change the infrastructure through an API instead. Flow logs will show you nothing; the audit log is where that story lives.

Asset inventory as the thing detection depends on

Inventory sounds like an administrative concern and is in fact a detection dependency.

Consider what you cannot do without it:

• Prioritise an alert. "Suspicious process on SRV-4471" means nothing until you know whether SRV-4471 is a print server or the payroll database.
• Scope an incident. You cannot confirm that only three hosts were affected if you do not know how many exist.
• Notice absence. A host that stops sending logs is a finding — but only if something knew it was supposed to be sending them.
• Measure coverage. "EDR is deployed on 94% of endpoints" requires a denominator.

That last point is the one that bites. Coverage gaps are invisible from inside the tool: the console shows you the agents that exist, not the machines that lack one. The only way to find them is to compare against an independent list — which is exactly why inventory and detection are the same problem wearing two hats.

A workable inventory carries, at minimum: what the asset is, who owns it, what it does, how sensitive its data is, and whether it is exposed to the internet. Those five fields turn a raw alert into a prioritised one, and you will meet them again in the vulnerability management lessons, where they do the same job for a finding that they do here for an alert.

Topics this lesson owns

• [x] Segmentation, zones and why east-west traffic matters
• [x] Where a sensor sees traffic and where it is blind
• [x] North-south chokepoints: proxies, gateways, egress
• [x] Cloud network plumbing an analyst meets in logs
• [x] Asset inventory as the thing detection depends on