OSI and TCP/IP Models Guide: Layers and Attacks per Layer

Security teams talk about "layer 3 firewalls", "layer 7 attacks" and "layer 2 segmentation" every day, yet the models behind those labels are often half remembered, which leads to controls placed at the wrong layer and gaps nobody notices. The OSI model is a seven-layer reference model for describing how network communication is divided into functions; the TCP/IP model is the four-layer description of how the internet protocols are actually built. This guide explains both in plain terms, shows how data is wrapped as it moves down the stack, lists example protocols at each layer, and maps the main attacks and defensive controls to each layer in one table. It also places TLS, VPNs, web application firewalls and network detection and response on the model so you can see what each one can and cannot see. It is for analysts, architects and engineers who want a working model rather than an exam definition.

Key takeaways

OSI is a vocabulary, TCP/IP is the implementation. OSI (ITU-T X.200) gives seven layers for describing functions; RFC 1122 describes the internet in four layers: link, internet, transport and application.
Encapsulation explains visibility. Each layer wraps the one above, so a device that only reads outer headers cannot judge what is inside, and encryption at one layer hides everything above it.
Every layer has its own attacks. ARP poisoning at layer 2, spoofing and floods at layer 3, SYN floods at layer 4 and injection at layer 7 need different controls at different points.
Place each control on the model before buying it. A packet filter cannot stop SQL injection, a WAF cannot see ARP spoofing, and an NDR sensor sees TLS metadata but not encrypted payload.
Defence in depth means coverage at several layers. Identity-aware controls at the top, encryption in the middle and filtering and segmentation at the bottom together leave fewer gaps than any one layer done perfectly.

What the two models are, in plain language

Network communication is easier to reason about if it is split into layers, each doing one job and relying on the layer below. The OSI Basic Reference Model, published by the ITU-T as Recommendation X.200 (current edition 07/94, in force) and jointly with ISO as ISO/IEC 7498-1, defines seven layers. It was designed as a reference for building interoperable systems; the OSI protocol suite itself never displaced the internet protocols, but the model survived as a shared vocabulary.

The TCP/IP model grew out of the internet protocols themselves. RFC 1122, the requirements for internet hosts, describes four layers: the link layer (how a host talks on its directly connected network), the internet layer (IP, ICMP and IGMP), the transport layer (end-to-end services, mainly TCP and UDP) and the application layer, which RFC 1122 notes combines the functions of the OSI presentation and application layers.

OSI layer	What it does	TCP/IP layer (RFC 1122)	Unit of data	Example protocols and technologies
7 Application	Services used by applications	Application	Message or data	HTTP, DNS, SMTP, SSH, LDAP, SMB, RDP, MQTT
6 Presentation	Data format, encoding, encryption			Character encoding, data serialisation; TLS is often placed here informally
5 Session	Setting up and managing dialogues			Session management inside protocols such as SMB, RPC and TLS sessions
4 Transport	End-to-end delivery between processes, ports	Transport	Segment (TCP) or datagram (UDP)	TCP, UDP, QUIC (over UDP), SCTP
3 Network	Addressing and routing between networks	Internet	Packet	IPv4, IPv6, ICMP, IPsec, OSPF, BGP (carried over TCP)
2 Data link	Delivery on one local network, MAC addresses	Link	Frame	Ethernet, 802.1Q VLANs, Wi-Fi (802.11), ARP, 802.1X, MACsec
1 Physical	Signals on cable, fibre or radio	Link	Bits	Copper and fibre cabling, radio, transceivers

Real protocols rarely sit neatly on one layer. ARP links layer 3 addresses to layer 2 addresses; BGP is a routing protocol that runs over TCP; TLS sits between transport and application. Treat the layers as a way to ask "what does this control see?", not as strict boxes.

Encapsulation: how data moves down and up the stack

When an application sends data, each layer adds its own header in front of what it received from above, and the receiving host removes them in reverse order.

Application: a browser builds an HTTP request.
Security layer (if used): TLS encrypts the request and adds its record header. From here down, only the endpoints can read the HTTP content.
Transport: TCP adds source and destination ports, sequence numbers and flags (RFC 9293 lists CWR, ECE, URG, ACK, PSH, RST, SYN and FIN). UDP would add only ports, length and checksum (RFC 768).
Internet: IP adds source and destination addresses, Time to Live and the protocol number (6 for TCP, 17 for UDP), as set out in RFC 791. IPv6 uses a fixed 40-byte header with optional extension headers chained through Next Header (RFC 8200).
Link: Ethernet adds source and destination MAC addresses (and an 802.1Q VLAN tag if used) for the next hop only. Each router strips the frame and builds a new one for the next link.
Physical: the frame is sent as signals.

Three security consequences follow. First, MAC addresses only have meaning on the local link, so they never survive a router, and any control based on MAC addresses works only within one segment. Second, a device acts on the outermost headers it understands: a router reads layer 3, a stateful firewall reads layers 3 and 4, and only a proxy or inspection engine reads layer 7. Third, tunnels and VPNs are encapsulation inside encapsulation: an IPsec tunnel-mode packet carries a whole inner IP packet, so a filter on the outer header sees only the two tunnel endpoints.

Attacks and controls at each layer

The table maps common attacks to the layer they target, the MITRE ATT&CK technique where one exists, and the controls that work at that layer. Attacks often combine layers: a layer 2 man-in-the-middle is usually a step towards stealing layer 7 credentials.

Layer	Example attacks	ATT&CK	Controls that work here
1 Physical	Rogue devices plugged into open ports, cable taps, radio jamming, rogue Wi-Fi access points	None specific	Physical access control, disabling unused switch ports, 802.1X port authentication, wireless intrusion detection
2 Data link	ARP cache poisoning, DHCP spoofing, MAC flooding, VLAN hopping through trunk negotiation or double tagging	T1557.002 ARP Cache Poisoning, T1557.003 DHCP Spoofing	Dynamic ARP inspection, DHCP snooping, port security, disabling trunk auto-negotiation, unused native VLAN, 802.1X, MACsec
3 Network	Source address spoofing, volumetric floods, route hijacking, ICMP tunnelling, network scanning, bridging past boundary devices	T1498.001 Direct Network Flood, T1595 Active Scanning, T1599 Network Boundary Bridging	BCP 38 ingress and egress filtering, ACLs and packet filters, upstream DDoS scrubbing, IPsec, segmentation, RPKI for BGP
4 Transport	SYN floods, UDP reflection and amplification, port scanning, session hijacking	T1499.002 Service Exhaustion Flood, T1046 Network Service Discovery	Stateful firewalls, SYN cookies, rate limiting, closing unused ports, connection limits
5 and 6 Session and presentation	Session hijacking and replay, TLS downgrade, weak cipher negotiation, certificate impersonation	T1557 Adversary-in-the-Middle	TLS 1.3 or 1.2 with strong suites, certificate validation, HSTS, mutual TLS between services, short session lifetimes
7 Application	Injection and other web exploits, credential stuffing, HTTP floods, DNS tunnelling, command and control over web protocols	T1190 Exploit Public-Facing Application, T1071.004 DNS, T1572 Protocol Tunneling	WAF and API gateways, secure coding, strong authentication and MFA, protective DNS, proxies with inspection, application rate limits

Notes on the table

Layer 2 trust: RFC 826 defines no authentication for ARP replies, and hosts update their caches from the sender fields of incoming packets. That design is why switch-level controls are needed on any segment with untrusted devices. See the Wi-Fi Security Guide for the wireless equivalent.
Layer 3 spoofing: BCP 38 (RFC 2827) filters packets whose source address does not belong to the network they come from; it does not stop floods from real addresses, but it removes the anonymity that reflection attacks rely on.
Layer 4 floods: RFC 4987 describes SYN flooding as filling a server's backlog of half-open connections, and lists SYN cookies, ingress filtering, larger backlogs and firewalls or proxies that complete the handshake on the server's behalf as mitigations, noting that a larger backlog alone is not robust. See the DDoS Protection Guide.
Layer 7 is where most breaches land: stolen credentials and exploited internet-facing applications operate entirely at the top of the stack, where lower-layer filtering sees only an allowed connection to port 443.

Where TLS, VPNs, WAFs and NDR sit

Technology	Layer it operates at	What it protects or sees	What it cannot see
Packet filter or ACL	3 and 4	Addresses, ports, protocol	Application content, user identity
Stateful firewall	3 and 4, with connection state	Whether a packet belongs to an allowed connection	What is inside an allowed connection
Next-generation firewall	3 to 7	Application identification, user tags, some content inspection	Encrypted payload unless TLS inspection is enabled
TLS	Between 4 and 7 (needs a reliable, in-order stream beneath it)	Confidentiality, integrity and server authentication for application data (RFC 8446)	Addresses, ports, timing and volume stay visible; server name usually visible
IPsec VPN	3	Whole IP packets between gateways or hosts (ESP provides confidentiality and integrity, RFC 4301)	Nothing about who uses the tunnel beyond the authenticated peer
TLS or SSL VPN	Tunnels layer 3 traffic inside a layer 4 to 7 TLS session	Remote user traffic to the corporate network	Whether the authenticated user is still the right person, or the device healthy
Web application firewall	7 (HTTP)	Requests and responses to web apps and APIs, after TLS termination	Non-HTTP traffic, internal east-west traffic, layer 2 and 3 attacks
Network IDS/IPS	2 to 7, signatures on packets	Known attack patterns in cleartext traffic	Encrypted payloads, segments without sensors
NDR	2 to 7, behaviour and metadata	Flows, protocol metadata, TLS handshake details, anomalies	Encrypted content; traffic that never passes a sensor
ZTNA and identity-aware proxy	7	Per-application access tied to user, device and context	Network-level attacks below the application

TLS: TLS 1.3 always authenticates the server and optionally the client. Once in place, a network device sees the outer layers but not the content, which is the point. See the TLS Inspection Guide and the mTLS Guide.
VPNs: IPsec works at layer 3 and supports transport mode (protecting the payload between two hosts) and tunnel mode (wrapping the whole packet, required when an end is a security gateway). Remote access VPN appliances are themselves internet-facing layer 7 services with a long history of exploited flaws; see the VPN Security Guide.
WAFs: a WAF only works where it terminates or receives decrypted HTTP; see the Web Application Firewall Guide.
NDR: sensors parse traffic at several layers and are strongest at spotting behaviour (scanning, beaconing, lateral movement) rather than content; see the NDR Guide.

Choosing controls by layer: decision guidance

Start with the asset and the attacker's route: an internet-facing web app needs layer 7 controls first (WAF, authentication, patching), because layer 3 filtering must allow port 443 anyway. A flat office network needs layer 2 controls first, because the attacker is already on the link.
Network versus application enforcement: network controls (ACLs, segmentation) are coarse but cover everything, including unmanaged devices. Application and identity controls (ZTNA, mTLS) are precise but only cover what is integrated. Most organisations need both, with network controls as the backstop.
IPsec versus TLS VPN: IPsec suits site-to-site links between fixed gateways; TLS-based access suits roaming users and passes through restrictive networks more easily. Either way, the gateway becomes a high-value layer 7 target.
Inspect or trust encryption: decrypting traffic at the edge restores layer 7 visibility but creates a trusted man-in-the-middle with its own key and privacy risks. Where you cannot decrypt, invest in metadata and endpoint telemetry instead.
Small versus large organisations: a small organisation can cover most layers with a managed firewall, switch protections enabled on access ports, a cloud WAF in front of public apps, protective DNS and MFA everywhere. A large one adds segmentation gateways, NDR sensors at internal chokepoints, DDoS scrubbing and per-application access.

Using the model in practice: a step-by-step layer review

Pick one system or segment: for example a payment application or a branch office. Draw its traffic paths from client to server.
Walk the layers bottom up: for each layer, list the attack paths from the table that apply and the controls that are already in place.
Mark gaps and overlaps: a gap is a layer with a relevant attack and no control; an overlap may let you retire a redundant tool.
Test in audit mode first: enable new protections (DHCP snooping, ARP inspection, WAF rules, IPS signatures) in monitor or detect-only mode on a pilot segment, review what would have been blocked for one to two weeks, then switch to enforce.
Keep rollback simple: change one layer at a time, keep the previous configuration exported, and agree in advance who can revert a blocking rule and how fast.
Confirm visibility: make sure each layer's control produces logs that reach your SIEM, then repeat the review for the next system.

Detection and measurement by layer

Layer 2: DHCP snooping and ARP inspection violations, MAC address flapping between ports, 802.1X failures.
Layers 3 and 4: firewall denies from internal hosts, spoofed source addresses at the edge, scan patterns, SYN rates and half-open connection counts on public services.
Layers 5 to 7: TLS versions and cipher suites in use, certificate errors, WAF blocks by rule, authentication failures, unusual DNS query volumes per host.

Metrics that show the layered model is working:

Layer coverage: share of critical systems with at least one preventive and one detective control mapped at each relevant layer.
Access port hardening: percentage of user access switch ports with DHCP snooping, ARP inspection and 802.1X enabled.
Encryption in transit: percentage of internal service connections using TLS 1.2 or later, and the count of services still offering older protocols.
WAF enforcement: percentage of internet-facing web apps and APIs behind a WAF in blocking mode.
Sensor reach: percentage of east-west traffic between zones passing an NDR or IDS sensor.

Framework mapping

Layer focus	NIST SP 800-53 Rev. 5	NIST CSF 2.0
Layers 1 and 2: port control, local network protections	SC-7 Boundary Protection, CM-7 Least Functionality	PR.IR-01
Layers 3 and 4: filtering, flow control, DoS	SC-7, SC-7(5) Deny by Default, AC-4 Information Flow Enforcement, SC-5 Denial-of-service Protection	PR.IR-01
Layers 5 and 6: encryption and session integrity	SC-8 Transmission Confidentiality and Integrity, SC-23 Session Authenticity	PR.DS-02
Layer 7: name resolution, application protection	SC-20 Secure Name/Address Resolution Service, SI-4 System Monitoring	DE.CM-01
All layers: monitoring and logging	SI-4, AU-2 Event Logging, AU-12 Audit Record Generation	DE.CM-01

NIST SP 800-41 Rev. 1 covers firewall technologies and policy, and NIST SP 800-94 covers network-based, wireless, network behaviour analysis and host-based intrusion detection and prevention. In ISO/IEC 27001:2022 Annex A, 8.20 Networks security, 8.21 Security of network services and 8.24 Use of cryptography are the closest matches.

Common failure patterns

Expecting a lower-layer control to stop an upper-layer attack: a port 443 allow rule plus a "firewall" tick box does nothing against injection or stolen passwords arriving over HTTPS.
Forgetting layer 2 inside the perimeter: user VLANs with no DHCP snooping or ARP inspection let any compromised laptop sit in the middle of its neighbours' traffic.
Trusting the tunnel, not the user: a VPN authenticates once at the start and then gives layer 3 reach to whole networks. The Colonial Pipeline ransomware attack began through a legacy VPN profile that had never been disabled, accessed with a leaked password and no MFA: the encryption worked perfectly and protected the attacker's session.
Blind spots created by encryption: an IDS still deployed for cleartext signatures, now seeing mostly TLS 1.3, gives a false sense of coverage.
A WAF that never blocks: left in detection mode after the pilot, so it logs attacks it could have stopped.
Using the model as a filing system, not a test: mapping tools to layers in a diagram without checking that each one actually sees the traffic on the paths that matter.

Practitioner checklist

Map each critical system's traffic paths against all layers and record which controls see each path.
Disable unused switch ports and enable 802.1X where devices can be managed.
Turn on DHCP snooping, dynamic ARP inspection and port security on user access switches, and disable trunk auto-negotiation.
Apply BCP 38 anti-spoofing and deny-by-default filtering at every routed boundary.
Protect public services against layer 4 floods with SYN cookies, rate limits and upstream DDoS capacity.
Require TLS 1.2 or later for internal and external services and remove older protocol versions.
Put internet-facing web apps and APIs behind a WAF in blocking mode, after an audit-mode pilot.
Place NDR or IDS sensors on east-west chokepoints and confirm their logs reach the SIEM.
Require MFA on every VPN and remote access path, and review their user scope.

OSI and TCP/IP Models Guide: Network Layers and the Attacks at Each Layer