Secure Infrastructures

Device Placement

Every network is unique. A manufacturing facility runs industrial control systems and SCADA networks. A hospital runs FDA-regulated medical devices and EHR systems. A financial services firm runs trading platforms with microsecond latency requirements. Despite these differences, certain architectural patterns appear across nearly every secure network — because they solve fundamental security problems that arise regardless of industry.

The most foundational pattern is strategic device placement. Where a security device sits in the network determines what traffic it can inspect, what threats it can detect, and what it can block. A firewall placed at the wrong boundary enforces the wrong policy. A sensor placed on the wrong segment sees the wrong traffic. Placement is a design decision, not a configuration decision — it must be made during architecture, not improvised after deployment.

The primary device categories and their placement logic:

• Firewalls: The primary boundary control between zones. Firewalls filter incoming and outgoing traffic, enforce access control policies, and inspect packets for malicious activity. They are placed at every zone boundary — between untrusted and screened zones, between screened and trusted zones, and between zones within the trusted network. Proper firewall placement ensures that sensitive internal systems are shielded from external threats and that internal segments are isolated from each other.
• Honeypots: Decoy systems designed to attract attackers and generate intelligence about attack methods. A honeypot mimics a real production system but contains no real data. When an attacker interacts with it, every action is logged. Honeypots are placed in locations that make them plausible targets — inside the screened zone where a real server might exist, or inside the trusted network where a lateral-moving attacker might pivot to. Any traffic to a honeypot is inherently suspicious; there is no legitimate reason for a user to access a system that only exists to attract attackers.
• Jump servers: A jump server (also called a bastion host or privileged access workstation gateway) is the single controlled entry point for administrative access to internal systems. Instead of allowing administrators to SSH or RDP directly from their workstations to any server, all administrative sessions are routed through the jump server. The jump server enforces MFA, logs every session, and records all commands. This concentrates the attack surface for administrative access into a single, heavily monitored system.
• Load balancers: Distribute traffic across multiple backend servers to prevent any single server from becoming overwhelmed. From a security perspective, load balancers can integrate WAF functionality, terminate TLS connections, and hide the number and IP addresses of backend servers from external view. By sitting in front of backend servers, they reduce the directly exposed attack surface.
• Sensors: Network traffic sensors (IDS sensors, netflow collectors, packet capture probes) are placed at strategic points to monitor traffic. Sensors are typically placed at zone boundaries — where traffic crosses from one zone to another — to observe what is moving between network segments. Unlike firewalls, sensors are passive: they observe and report but do not block. Their placement determines what visibility the security team has into network activity.

Security Zones

A security zone is a logical segment of the network assigned a trust level. The critical distinction from simple IP subnets: a zone is defined by what it contains and how it is accessed, not by its address range. This flexibility allows security policies to be expressed as relationships between zones rather than as lists of IP addresses — which simplifies management significantly, especially in large environments where addresses change frequently.

The most basic zone model divides the network into two zones: trusted and untrusted. The internet is untrusted; the internal network is trusted. But a two-zone model creates a single binary: either traffic is allowed from outside to inside, or it is not. In practice, organizations need more granularity.

Common zone configurations:

• Untrusted (external/internet): Everything outside the organization's perimeter. Traffic from this zone is assumed to be hostile until verified. Inbound traffic from the untrusted zone passes through the firewall and is permitted only to the screened zone — never directly to trusted systems.
• Screened zone (DMZ — demilitarized zone): A semi-trusted zone that sits between the untrusted internet and the trusted internal network. Public-facing services — web servers, mail relay servers, DNS servers — live in the screened zone. These systems must accept connections from the untrusted internet, but they have no reason to access internal databases or directory servers. The screened zone limits the blast radius of a compromise: an attacker who breaches a web server in the DMZ cannot directly reach the internal network from that position.
• Trusted (internal): The internal network. Systems here are not directly accessible from the internet. Users, workstations, internal servers, and internal services live here. Traffic from the trusted zone to the untrusted zone is generally permitted (outbound) with inspection; traffic from untrusted to trusted is blocked or heavily restricted.
• Application-specific zones: Large organizations segment further — a dedicated servers zone, a databases zone, a management zone, a guest Wi-Fi zone. Each has different trust levels and access policies. A guest Wi-Fi zone might have internet access but no access to internal systems. A databases zone might accept connections only from the application servers zone.

Zone-based security policies are written as relationships between zones:

• Trusted → Untrusted: Permitted with inspection (outbound web browsing, email sending)
• Untrusted → Screened: Permitted for specific services (HTTP/HTTPS to web servers, SMTP to mail relay)
• Untrusted → Trusted: Blocked by default; any exception requires explicit justification and is a significant security decision
• Screened → Trusted: Restricted to specific application-layer calls (web server querying the database on a specific port with a specific service account)

The Attack Surface Defined

The attack surface is the complete set of points where an attacker could potentially enter a system or extract data. Just as a building can be entered through a door, a window, or a basement hatch, a network can be entered through an open port, an unpatched application, a weak authentication mechanism, or a misconfigured firewall rule. Every entry point is part of the attack surface, and the larger the attack surface, the more opportunities an attacker has to find one that can be exploited.

The exam defines four primary attack surface components:

• Application code: Every line of code deployed on a server or device is part of the attack surface. A SQL injection vulnerability in a web application, a buffer overflow in a network service, or a logic error in authentication code is an exploitable entry point. Code that is never deployed cannot be attacked. Code that is patched closes that specific entry point.
• Open ports and network services: Every port that a server listens on is an entry point. A server running a web server, an SSH daemon, an SNMP agent, and a legacy management interface has four times the network attack surface of a server running only the web server. Ports that are open but not actively used for a business purpose are purely additional attack surface with no offsetting benefit.
• Authentication mechanisms: Every authentication interface — login pages, API authentication, VPN portals, administrative interfaces — is an entry point. Credential-based attacks (password spraying, credential stuffing, brute force) target authentication interfaces. Weak or missing authentication on any interface is a direct attack surface exposure.
• Human error: The largest and most persistent component of the attack surface. A firewall rule misconfigured to allow traffic that should be blocked. An administrator who grants excessive permissions. A developer who hardcodes credentials in code. A user who clicks a phishing link. Human error cannot be patched or closed — it must be managed through training, process controls, and architectural decisions that limit the blast radius of mistakes.

Minimizing the Attack Surface

Attack surface reduction is the discipline of eliminating every entry point that does not serve a documented business purpose. The goal is not to reach zero attack surface — that is impossible in any functioning system — but to ensure that every element of the attack surface is there because it needs to be, not by default or neglect.

The four primary strategies:

• Code auditing: Regular review of application code to identify vulnerabilities before they are exploited. Static analysis tools scan code for known vulnerability patterns. Penetration testing attempts to exploit the running application. Bug bounty programs expand the pool of testers. Code that is never audited accumulates vulnerabilities silently.
• Block ports and disable services: Every unnecessary service running on a server is a liability. The principle: if a service is not required for the system's function, disable it. If a port is not required for legitimate traffic, block it at the firewall. A hardened server running only what it needs has a fraction of the attack surface of a default installation with all optional services enabled.
• Strict access control: Every authentication interface should enforce the minimum necessary access. Principle of least privilege — users and services get only the permissions required for their function. MFA on all externally accessible authentication interfaces. Account lockout and login attempt monitoring on all authentication systems.
• Real-time traffic monitoring: Monitoring does not reduce the attack surface directly — it reduces the time between when an attacker exploits an entry point and when the organization detects the intrusion. A SIEM correlating logs from across the environment, IDS sensors at zone boundaries, and anomaly detection on endpoint behavior together create the visibility necessary to detect attacks-in-progress before they complete their objectives.

Physical Layer Security

Security begins at the physical layer. The network cabling that connects devices is the literal path over which all data flows — and it is often completely unprotected. In many facilities, network cables run through open cable trays, around conference rooms with unlocked wall jacks, and through areas accessible to visitors or contractors. An attacker with physical access to a network cable or a live wall jack can install a passive tap and capture all traffic traversing that segment.

Physical connectivity protections:

• Secure the drops: Network wall jacks in publicly accessible areas (conference rooms, lobbies, visitor areas) should be disabled at the switch port when not in use, or should connect to a restricted guest VLAN rather than the internal network. An active network port next to a conference room chair is an open invitation to an attacker with a laptop.
• Protect cable runs: Cabling between network equipment — particularly backbone cabling between floors or buildings — should run through locked conduit or secured cable trays. Outdoor cabling runs must be in conduit that resists cutting or tapping.
• 802.1X port authentication: Rather than trusting any device plugged into a network port, 802.1X requires the connecting device to authenticate before network access is granted. An unauthorized device plugged into a conference room jack is denied access regardless of whether the port is active.

Application-Level Encryption

Application-level encryption protects data at the application layer — ensuring that even if an attacker successfully captures network packets (whether through a physical tap, a VLAN misconfiguration, or a compromised switch), the captured data is unreadable. The attacker can see that traffic occurred but cannot read its contents.

The dominant application-level encryption technology is TLS (Transport Layer Security), which replaced SSL. TLS secures:

• HTTPS (web traffic): TLS wraps HTTP, making web sessions confidential
• SMTPS, IMAPS, POP3S: email protocols secured with TLS
• FTPS, SFTP: file transfer over encrypted channels
• Database connections: client-to-database connections can be TLS-encrypted

The security benefit of application-level encryption is that it protects data end-to-end between the application and the user — regardless of what the network infrastructure does or does not do. Even in an environment with no network-level encryption, TLS-encrypted web traffic is protected against interception. The cabling can be tapped; the data remains confidential.

Network-Level Encryption

Network-level encryption protects entire communication channels — typically between network locations rather than between individual applications. Where application encryption (TLS) protects specific application sessions, network-level encryption protects everything that flows over a network link.

The two primary technologies:

• IPsec tunnels (site-to-site VPN): IPsec encrypts traffic at the IP layer, creating an encrypted tunnel between two network locations — typically two office sites, or an office site and a data center. All traffic flowing through the tunnel is encrypted, regardless of whether the applications using it are themselves encrypted. A file transfer over SMB (which is unencrypted by default) flowing through an IPsec tunnel is protected. IPsec is transparent to the applications — they have no awareness that their traffic is being encrypted at the network layer.
• VPN concentrators (remote access VPN): A VPN concentrator is a dedicated device that accepts VPN connections from remote users. When a user connects from home or a hotel, the VPN client establishes an encrypted tunnel to the concentrator, and all traffic is routed through that tunnel as if the user's device were physically on the internal network. The concentrator handles authentication, enforces access policies, and logs all sessions. Remote connections over untrusted networks (coffee shop Wi-Fi, hotel networks) become secure through the tunnel.

Defense in Depth — The Integrated Approach

Secure infrastructure is not achieved through any single control. It is the product of multiple layered controls, each compensating for the limitations of the others. The layers of a defense-in-depth architecture:

Each layer compensates for weaknesses in adjacent layers. An attacker who defeats the perimeter firewall encounters zone segmentation. An attacker who pivots through a compromised system encounters access controls and monitoring. An attacker who captures traffic encounters encryption. No layer is impenetrable — but requiring an attacker to defeat multiple independent controls in sequence is the foundation of secure infrastructure design.