How to place security controls by layer
By the end of this module you will be able to:
- Identify the OSI layer where a specific threat action takes place and state which control type belongs there
- Explain the difference between Layer 2 port security, Layer 3 ACLs, Layer 4 stateful inspection, and Layer 7 application filtering
- Describe what zero trust architecture adds beyond a perimeter firewall, citing NIST SP 800-207
- State why a control placed at the wrong layer either fails to stop the threat or creates unnecessary friction
Real-world incident · December 2020
SolarWinds SUNBURST: when a trusted update became the attacker's entry point
In late 2020, security researchers at FireEye discovered that SolarWinds Orion software updates, trusted and signed by SolarWinds themselves, contained a backdoor named SUNBURST. Attackers had inserted malicious code into the build pipeline months earlier. The resulting DLL was distributed to roughly 18,000 organisations, including US government agencies and major technology companies.
The initial access did not require exploiting a vulnerability in the traditional sense. The update was legitimate. The signature checked out. Perimeter firewalls allowed the traffic because it looked exactly like authorised Orion telemetry. Once installed, the implant waited two weeks before phoning home to blend in with normal traffic patterns and avoid sandbox analysis.
The breach demonstrated a failure not of individual controls but of the assumption that the perimeter is the primary defence boundary. Many victims had no controls on east-west (internal) traffic, no microsegmentation between the Orion server and sensitive systems, and no anomaly detection on privileged identity behaviour. A perimeter firewall cannot stop what it cannot see as malicious. Understanding which layer a threat action occurs at is what determines which controls are relevant.
Every perimeter firewall said the traffic was clean. So why did thousands of organisations not know they had been breached for nine months?
Controls belong where the risk is visible
A control placed below the attack cannot see the payload; a control placed too high may miss the path.
Place each control at the layer where the threat action is visible. A WAF cannot see a port scan; an ACL cannot see a SQL injection; both must be present, each at its own layer.
TLS everywhere is necessary but not sufficient
Encrypted traffic can still carry authorised misuse, vulnerable requests, and lateral movement.
TLS protects bytes between two endpoints. After decryption, the application owns authorisation; east-west traffic between services is where lateral movement spreads if you stop at 'TLS everywhere'.
17.1 The principle: controls belong at the layer where the risk forms
Module 16 closed with a repeatable troubleshooting method. This module applies the same layered thinking to security, asking a different question: at which layer does a given threat actually do its damage? Placing a control at the wrong layer is not neutral; it either fails to intercept the threat, or it intercepts benign traffic and creates friction that leads engineers to disable it.
A port scanner operates at Layer 3 and 4: it sends IP packets to discover open TCP or UDP ports. Blocking it with a Layer 7 Web Application Firewall (WAF) is ineffective because the WAF only parses HTTP. A SQL injection attack arrives inside an HTTP request at Layer 7. Blocking it with an IP-layer ACL is impossible because the ACL has no visibility into the payload. The threat layer determines the defence layer.
Defence in depth does not mean placing every control type at every layer. It means placing the most effective control at the layer where the risk forms, and supplementing with adjacent controls that catch what slips through. The goal is complementary coverage, not redundant blocking.
Ask: "At which layer does the attacker perform the action I want to prevent?" Then ask: "What is the lowest layer at which a control can see that action?" Those two answers define where the control belongs.
The principle is clear. Layer 2 threats are the first category where it applies, and they are often the most overlooked.
17.2 Layer 2: port security and 802.1X authentication
Layer 2 threats include rogue device attachment, ARP (Address Resolution Protocol) spoofing, MAC (Media Access Control) address flooding, and VLAN hopping. These attacks work below the IP layer, which means Layer 3 firewalls have no visibility into them at all.
Port security on a managed switch limits how many MAC addresses can be learned on a given port, and can shut the port down if an unknown device connects. This is a simple but effective control against rogue hardware. 802.1X (IEEE 802.1X-2020) is the port-based network access control standard: a supplicant (the device) must authenticate to an authenticator (the switch port) using credentials verified by an authentication server before any network traffic is forwarded.
The practical limitation of Layer 2 controls is their scope: they protect the local broadcast domain only. A VLAN boundary is also a Layer 2 boundary. Traffic crossing a router is already at Layer 3 and beyond the reach of Layer 2 controls. For a distributed network, 802.1X must be deployed at every edge port to be effective.
Layer 2 controls stop attacks at the physical access point. Layers 3 and 4 controls extend that boundary to include all routed traffic between segments.
17.3 Layer 3 and 4: ACLs, routing controls, and stateful firewalls
Layer 3 controls operate on IP source and destination addresses. Access Control Lists (ACLs) on routers and Layer 3 switches can permit or deny packets based on source IP, destination IP, and protocol. They are stateless: each packet is evaluated independently, with no memory of what came before. Stateless ACLs are fast and scale well, but they cannot reason about connection state.
Stateful firewalls add Layer 4 awareness. A stateful firewall tracks the state of TCP connections: it knows whether a packet belongs to an established session, is initiating a new one, or appears out of context. A return packet (ACK from server to client) is allowed automatically because the firewall knows the corresponding outbound SYN was permitted. Without state tracking, you would need separate rules for every direction of every permitted flow.
The weakness of Layer 3 and 4 controls is that they have no view of application content. A firewall permitting TCP port 443 cannot distinguish between legitimate HTTPS and a command-and-control channel tunnelled over HTTPS. That distinction requires Layer 7 inspection.
Stateless ACLs answer: "Should this packet be forwarded based on its address?" Stateful firewalls answer: "Does this packet belong to a permitted session?" Application-layer firewalls answer: "Is the content of this session within policy?" Each question requires more processing but provides more precision.
Layers 3 and 4 controls reason about addresses, ports, and connection state. Layer 7 controls go further by reading the content of what is being sent.
17.4 Layer 7: WAF, IDS, and IPS
Layer 7 controls inspect the content of application protocols. A Web Application Firewall (WAF) parses HTTP requests and responses, looking for SQL injection payloads, cross-site scripting (XSS) patterns, malformed headers, and other attack signatures. It can block a request that arrives on a permitted IP address over a permitted port because its decision is based on payload content, not transport characteristics.
An Intrusion Detection System (IDS) observes traffic and raises alerts; an Intrusion Prevention System (IPS) can also block it inline. Both operate on signatures (known attack patterns) and anomaly detection (deviations from a baseline). An IDS is a sensor; an IPS is a sensor with an enforcement action attached. Deploying an IPS inline on a path with high-volume legitimate traffic requires careful tuning: a false positive that blocks legitimate requests is an availability incident, not a security win.
Deep Packet Inspection (DPI) is a general term for any control that parses above Layer 4. It comes with a computational cost and a privacy consideration: the inspecting device must be able to read the payload. On TLS-encrypted sessions, this requires TLS interception (sometimes called SSL inspection), which has legal and trust implications that must be addressed before deployment.
Individual layer controls address specific attack vectors. Zero trust and microsegmentation provide the architectural model that ties all of these layers together into a coherent posture.
17.5 Zero trust and microsegmentation
Zero trust is a security model, not a product. NIST SP 800-207 centres the idea that trust should not be granted just because a user or device is inside a particular network location or owned by the organisation. A device inside the corporate network perimeter is not trusted by virtue of being inside. Every access request, regardless of source, is authenticated, authorised, and verified against policy before being granted.
Microsegmentation extends this to east-west (internal) traffic. In a microsegmented environment, workloads can only communicate with the specific other workloads they are authorised to reach, even if they are on the same physical host or subnet. This contains lateral movement: if one workload is compromised, the blast radius is limited by what that workload is permitted to reach from its own segment.
Microsegmentation is therefore not the definition of zero trust. It is one network enforcement pattern that helps implement zero trust policy for east-west traffic. Identity, device posture, application context, logging, and continuous policy evaluation are equally important parts of the architecture.
The SolarWinds breach illustrated the cost of absent east-west controls. Once the implant was present, it could use the Orion server's existing network permissions to reach Active Directory, internal APIs, and sensitive data stores. Microsegmentation and least-privilege network access would have restricted that reach regardless of whether the initial compromise was detected.
“No implicit trust is granted”
NIST SP 800-207 - Section 2, Zero Trust Basics
NIST SP 800-207 (published August 2020) is the US government's formal definition of zero trust architecture. The quoted principle is the core departure from perimeter-based security: location on the network is not a trust signal. This directly addresses the failure mode shown in the SolarWinds case study.
Common misconception
“A perimeter firewall provides thorough network security.”
A perimeter firewall controls north-south traffic: packets entering or leaving the network boundary. It has no visibility into east-west traffic between systems that are already inside the perimeter. Once an attacker is inside, a perimeter-only model provides no further containment. Defence in depth requires controls at multiple layers, including internal segmentation, endpoint controls, and identity verification that do not depend on network location.
An attacker connects a rogue laptop to an unmonitored switch port in a conference room. Which control would prevent that device from sending traffic on the network?
A security team wants to block SQL injection attacks targeting their web application. Which control type is most directly suited to this?
After a breach investigation, an organisation discovers that an attacker moved from a compromised web server to the internal database server over standard database ports. Which architectural change would have constrained this most?
An organisation wants to implement zero trust architecture. Their first step is to require multi-factor authentication for all remote users. A colleague says: 'That is not zero trust; zero trust means no network at all.' Who is correct, and why?
Core distinctions
- Place a control at the layer where the threat action occurs: Layer 2 controls cannot stop Layer 7 attacks, and Layer 7 controls cannot stop Layer 2 threats.
- IEEE 802.1X provides port-based access control at Layer 2, preventing unauthenticated devices from joining the network before any IP traffic is forwarded.
- Stateful firewalls track connection state at Layer 4; WAFs and IPS inspect application content at Layer 7. Each adds precision but also computational cost.
- A perimeter firewall only controls north-south traffic. East-west (internal) lateral movement requires internal segmentation controls such as microsegmentation.
- NIST SP 800-207 defines zero trust as eliminating implicit trust based on network location. Every access request is authenticated and authorised regardless of where it originates.
- Defence in depth means complementary controls at multiple layers, not duplicating the same control type everywhere.
Standards and sources cited in this module
NIST SP 800-207, Zero Trust Architecture
Section 2, Zero Trust Basics; Section 3, Logical Components of Zero Trust Architecture
The US government's authoritative definition of zero trust. Section 2 provides the quoted core principle (no implicit trust from network location) and Section 3 maps the logical control plane and data plane components referenced in the microsegmentation discussion.
IEEE 802.1X-2020, Port-Based Network Access Control
Clause 1, Overview; Clause 6, Port Access Entity
The normative standard for 802.1X authentication. Clause 1 defines the supplicant/authenticator/authentication-server model. Referenced in section 17.2 on Layer 2 port security.
NCSC, Network Security Fundamentals: Defence in Depth
Guidance section: Implementing defence in depth
The UK's National Cyber Security Centre guidance on layered network security, including the principle that no single control is sufficient and controls must be placed where the threat is visible.
Published December 13, 2020
The FireEye/Mandiant disclosure of the SolarWinds SUNBURST campaign used in the opening case study. Describes the initial access mechanism, the two-week dormancy period, and the lateral movement techniques that microsegmentation would have constrained.
CompTIA Security+ SY0-701 Exam Objectives
Domain 3.0: Security Architecture, Objective 3.2: Security controls by type
Defence in depth, firewall placement, and WAF vs stateful inspection are tested in the Security Architecture domain and directly relevant to this module's content.
You can now place controls at the right layer. Module 18 asks a harder question: which observability signals actually help, and how to avoid dashboard theatre where everything looks green while users suffer.
Module 17 of 21 · Practice-Strategy