Decompose a Web Request Into OSI and TCP/IP Layers

🎬 The Scenario

It's your third week as a junior SOC analyst at a mid-sized financial services firm. A Splunk alert fires: an internal workstation has made repeated HTTPS connections to an unfamiliar external IP at 3:17 AM. Your team lead drops the pcap file on your desk and says, "Tell me what layer the anomaly is at and what protocol is responsible." You open the file in Wireshark and immediately feel the problem — you're looking at a wall of packets labeled TCP, TLS, DNS, and HTTP/2, and you have no mental framework for which one to care about first, what data lives where, or what a SOC analyst is even supposed to look for at each level. This lesson gives you that framework before you touch another tool.

The Problem This Solves

Network traffic is layered by design. Every HTTPS request your browser sends is actually five or six separate protocols operating simultaneously, each responsible for a different job — addressing, routing, reliable delivery, encryption, and application logic. When something goes wrong (or someone is doing something malicious), the failure or the evidence lives at a specific layer. If you don't know the model, you can't localize the problem. You end up grep-ing through raw bytes hoping to stumble onto something suspicious, which is exactly as effective as it sounds.

Without a mental map of the OSI and TCP/IP models, you can't answer basic triage questions: Is this a network-layer routing problem or an application-layer C2 beacon? Is the anomalous traffic a malformed TCP segment or a DNS tunneling attempt in the payload? The OSI and TCP/IP layered models are not academic abstractions — they are the diagnostic vocabulary of every network engineer, every SOC analyst, and every interviewer at every security company. Every tool you will use in this course (Wireshark, Nmap, Snort, Splunk) is organized around this exact vocabulary.

Concept Foundation

The OSI model (Open Systems Interconnection) was published by the ISO in 1984 as a reference framework for how network communication should be structured. It defines seven layers, each with a specific responsibility and a specific name for the chunk of data it handles (called a Protocol Data Unit, or PDU). Think of it like a postal system: the message itself is just content, but by the time it leaves your house it has been placed in an envelope (transport), labeled with an address (network), loaded onto a truck route (data link), and physically carried as a truck on a road (physical). Each layer adds its own wrapper on the way down (encapsulation) and strips it off on the way up (de-encapsulation).

The TCP/IP model (also called the Internet model or DoD model) is the practical implementation of these ideas. It collapses the OSI's seven layers into four, because in the real world the top three OSI layers (Application, Presentation, Session) are almost always handled by the same application-layer protocol. TCP/IP is what actually runs the internet. OSI is the reference model you use to talk about what TCP/IP is doing. You need both: OSI gives you the diagnostic vocabulary; TCP/IP is the protocol stack your tools actually capture.

Here is the mapping you will use for the rest of this course:

Certification note: This content maps directly to CompTIA Security+ exam domain 3.0 (Implementation) and CompTIA Network+ exam domain 1.0 (Networking Concepts, objective 1.1). The CySA+ CS0-003 exam tests your ability to map network traffic to layers during incident triage — the exact skill this lesson builds.

Teaching Example

# -- TEACHING EXAMPLE: simplified for clarity --
# Tracing a single HTTPS GET request to https://bank.example.com/dashboard
# We walk DOWN the sender's stack (encapsulation) then UP the receiver's stack.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 7 — APPLICATION  |  TCP/IP: APPLICATION
# Protocol: HTTP/2 (inside TLS tunnel)
# PDU: Data
# ─────────────────────────────────────────────────────────────
# Your browser constructs an HTTP/2 GET request:
# GET /dashboard HTTP/2
# Host: bank.example.com
# WHY this layer matters to a SOC analyst:
#   C2 beacons, malicious User-Agent strings, HTTP verb anomalies,
#   and data exfiltration payloads all live here.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 6 — PRESENTATION  |  TCP/IP: APPLICATION
# Protocol: TLS 1.3
# PDU: Data (still — TLS wraps the HTTP data before TCP sees it)
# ─────────────────────────────────────────────────────────────
# TLS encrypts the HTTP payload so it cannot be read in transit.
# WHY this layer matters to a SOC analyst:
#   Expired or self-signed certs, outdated TLS 1.0/1.1 negotiation,
#   JA3/JA3S fingerprints that identify malware families even through encryption.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 5 — SESSION  |  TCP/IP: APPLICATION
# Protocol: TLS handshake (session establishment)
# PDU: Data
# ─────────────────────────────────────────────────────────────
# The TLS handshake negotiates cipher suites and exchanges keys.
# A full TLS 1.3 handshake = ClientHello → ServerHello → Finished (1-RTT).
# WHY this layer matters to a SOC analyst:
#   Anomalous handshake patterns, unusual cipher suites, and
#   certificate CN/SAN mismatches are detected here.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 4 — TRANSPORT  |  TCP/IP: TRANSPORT
# Protocol: TCP
# PDU: Segment
# ─────────────────────────────────────────────────────────────
# TCP adds: source port (random ephemeral, e.g. 54231), destination port 443,
# sequence numbers, and ACK numbers.
# The browser first completes a 3-way handshake: SYN → SYN-ACK → ACK
# WHY this layer matters to a SOC analyst:
#   Port scans, SYN floods, RST injection, unusual ephemeral port ranges,
#   and retransmission storms are all transport-layer anomalies.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 3 — NETWORK  |  TCP/IP: INTERNET
# Protocol: IPv4 (or IPv6)
# PDU: Packet
# ─────────────────────────────────────────────────────────────
# IP adds: source IP (192.168.1.105), destination IP (203.0.113.50),
# TTL (Time To Live, e.g. 64), protocol field (6 = TCP).
# WHY this layer matters to a SOC analyst:
#   IP spoofing, TTL anomalies for OS fingerprinting, GeoIP of destination,
#   ICMP tunneling, and routing anomalies live at this layer.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 2 — DATA LINK  |  TCP/IP: NETWORK ACCESS
# Protocol: Ethernet II
# PDU: Frame
# ─────────────────────────────────────────────────────────────
# Ethernet adds: source MAC (aa:bb:cc:dd:ee:ff), destination MAC (default gateway),
# and an EtherType field (0x0800 = IPv4).
# WHY this layer matters to a SOC analyst:
#   ARP spoofing/poisoning, MAC flooding, rogue DHCP servers, and
#   802.1Q VLAN hopping attacks all operate here.

# ─────────────────────────────────────────────────────────────
# OSI LAYER 1 — PHYSICAL  |  TCP/IP: NETWORK ACCESS
# Protocol: Electrical signal / Radio frequency
# PDU: Bits
# ─────────────────────────────────────────────────────────────
# The frame is converted to voltage changes on copper, light pulses on fiber,
# or RF waves on Wi-Fi. SOC analysts rarely work here directly.
# WHY this layer matters to a SOC analyst:
#   Physical layer taps, rogue Wi-Fi APs, and cable interference. You care
#   when the physical medium IS the attack vector (e.g., evil twin AP).

The example above walks the sender's stack from Layer 7 down to Layer 1. Each layer adds its own header (encapsulation). The receiver's stack does the exact reverse: the NIC receives bits, Ethernet strips the frame header, IP strips the packet header, TCP strips the segment header, and the application finally sees the original HTTP/2 GET request.

Notice that TLS spans OSI Layers 5 and 6. This is intentional and reflects reality — TLS handles both session management (the handshake, Layer 5) and data formatting/encryption (Layer 6). In practice, when you see TLS in Wireshark, it's operating across both layers simultaneously.

The PDU names are what you'll use when talking to engineers and reading tool documentation. In Wireshark, frames are what you capture at Layer 2; packets are what you inspect at Layer 3; segments are what TCP reassembles at Layer 4. Using the wrong term in an incident report signals inexperience — use the right one.

Production Version

# -- PRODUCTION VERSION: how this looks in a real codebase --
# This is your SOC analyst layer-inspection reference table.
# Use this when triaging an alert in Wireshark, Zeek, or Splunk.
# Each layer now includes: threat examples, detection method, and log source.
# The teaching example focused on "what lives here."
# The production version adds "what an analyst DOES here and where evidence lives."

# ═══════════════════════════════════════════════════════════════════════
# LAYER 7 — APPLICATION  (TCP/IP: Application)
# PDU: Data   |   Protocols: HTTP/2, DNS, FTP, SMTP, SSH
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Inspect payload content, headers, and URI patterns.
# THREAT EXAMPLES:
#   - C2 beaconing over HTTP/S (MITRE ATT&CK T1071.001)
#   - DNS tunneling for data exfiltration (MITRE ATT&CK T1071.004)
#   - Malicious file downloads via HTTP (T1105)
# DETECTION METHOD: Proxy logs, DNS query logs, HTTP header inspection
# LOG SOURCE (Splunk): index=proxy OR index=dns
# WIRESHARK FILTER: http.request.method == "POST" && http.content_length > 100000
#   WHY: Large POST bodies at unusual hours = potential exfil. Small GETs at
#        regular intervals = potential beacon.
# CERT REFERENCE: CompTIA CySA+ CS0-003, Domain 2: Vulnerability Management

# ═══════════════════════════════════════════════════════════════════════
# LAYER 6 — PRESENTATION  (TCP/IP: Application)
# PDU: Data   |   Protocols: TLS 1.3, SSL (deprecated), encoding schemes
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Validate TLS certificate details, cipher suites, JA3 hashes.
# THREAT EXAMPLES:
#   - TLS downgrade attacks forcing TLS 1.0 (T1040)
#   - Malware identified by JA3 fingerprint despite encrypted payload
#   - Self-signed certs masquerading as legitimate services
# DETECTION METHOD: TLS inspection via network sensor (Zeek/Suricata ssl.log)
# LOG SOURCE: Zeek ssl.log fields: certificate_subject, cipher, version
# WIRESHARK FILTER: tls.handshake.type == 1
#   WHY: Filter for ClientHello packets to inspect what cipher suites the
#        CLIENT is willing to use — malware often supports unusual suites.

# ═══════════════════════════════════════════════════════════════════════
# LAYER 5 — SESSION  (TCP/IP: Application)
# PDU: Data   |   Protocols: TLS handshake, RPC, NetBIOS, SMB session setup
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Inspect session establishment patterns and frequency.
# THREAT EXAMPLES:
#   - SMB session hijacking (T1557)
#   - Repeated failed TLS handshakes = potential scanner/brute-force
#   - Unusual session counts per host per hour (beacon jitter analysis)
# LOG SOURCE: Windows Event 4624/4625 for SMB sessions; Zeek conn.log for TCP
# WHY conn.log: Duration and bytes transferred per session reveal beaconing
#               patterns invisible in individual packet analysis.

# ═══════════════════════════════════════════════════════════════════════
# LAYER 4 — TRANSPORT  (TCP/IP: Transport)
# PDU: Segment   |   Protocols: TCP, UDP
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Check port usage, flag combinations, and connection volume.
# THREAT EXAMPLES:
#   - SYN flood DDoS (T1498)
#   - Port scanning via SYN packets to many destinations (T1046)
#   - Data exfil over unusual high port UDP (T1048.001)
# DETECTION METHOD: NetFlow/IPFIX data; Suricata threshold rules
# WIRESHARK FILTER: tcp.flags.syn == 1 && tcp.flags.ack == 0
#   WHY: SYN-only packets without ACK = incomplete handshake = scan or SYN flood.
#        In normal traffic, nearly every SYN is followed by SYN-ACK within ms.

# ═══════════════════════════════════════════════════════════════════════
# LAYER 3 — NETWORK  (TCP/IP: Internet)
# PDU: Packet   |   Protocols: IPv4, IPv6, ICMP, IPsec
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Inspect source/destination IPs, TTL values, and ICMP types.
# THREAT EXAMPLES:
#   - IP spoofing in DDoS reflection attacks (T1498.002)
#   - ICMP tunneling (T1095) — oversized ICMP payloads carry covert data
#   - TTL manipulation for traceroute-based network mapping
# DETECTION METHOD: Firewall logs, router NetFlow
# WIRESHARK FILTER: icmp && data.len > 64
#   WHY: Standard ICMP echo requests carry 32-56 bytes. Payloads >64 bytes
#        are abnormal and may indicate ICMP tunneling.

# ═══════════════════════════════════════════════════════════════════════
# LAYER 2 — DATA LINK  (TCP/IP: Network Access)
# PDU: Frame   |   Protocols: Ethernet II, IEEE 802.11 Wi-Fi, ARP, 802.1Q VLAN
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Inspect MAC addresses for spoofing; check ARP table integrity.
# THREAT EXAMPLES:
#   - ARP poisoning / MitM (T1557.002) — adversary associates their MAC
#     with the gateway IP to intercept all traffic
#   - MAC flooding to overwhelm switch CAM table, forcing hub-mode
#   - Rogue 802.1Q double-tagging for VLAN hopping
# DETECTION METHOD: Dynamic ARP inspection on managed switches; endpoint ARP logs
# WIRESHARK FILTER: arp.opcode == 2 && arp.duplicate-address-detected
#   WHY: Unsolicited ARP replies (gratuitous ARP) are the signature of ARP
#        poisoning. Wireshark flags duplicate IPs automatically.

# ═══════════════════════════════════════════════════════════════════════
# LAYER 1 — PHYSICAL  (TCP/IP: Network Access)
# PDU: Bits   |   Media: CAT6, Fiber, 802.11 RF
# ═══════════════════════════════════════════════════════════════════════
# ANALYST ACTION: Verify physical access controls; investigate rogue devices.
# THREAT EXAMPLES:
#   - Evil twin Wi-Fi AP (T1465) — adversary broadcasts SSID matching corp network
#   - Hardware keyloggers / LAN taps on physical ports
#   - RF jamming of wireless networks
# DETECTION METHOD: Wireless IDS (WIDS), port security on switches (802.1X),
#                   physical security audits
# WHY 802.1X matters: It enforces authentication BEFORE layer-2 access is granted,
#                     blocking rogue devices at the physical port level.

Common Mistakes & How to Fix Them

Mistake 1: Calling everything a "packet"

• Symptom: You write "the packet arrived at the MAC address" in an incident report. Your senior analyst corrects you.
• Why it happens: "Packet" is colloquially used for all network data, but technically it only refers to Layer 3 PDUs.
• Fix: Use the correct PDU name for the layer you're describing. Layer 2 = frame. Layer 3 = packet. Layer 4 = segment. Application = data. Build the habit now; it signals competence in interviews and reports.

Mistake 2: Placing TLS entirely at Layer 6 (or Layer 4)

• Symptom: On a CompTIA exam or interview, you say "TLS is a Layer 6 protocol" and lose marks.
• Why it happens: TLS does encryption (Layer 6 function) but also manages session state via its handshake (Layer 5 function). It's a common point of confusion because TLS predates the OSI model.
• Fix: Explain TLS as spanning Layers 5 and 6 in OSI terms, while living in the Application layer of the TCP/IP model. Wireshark also classifies TLS records by their Content-Type (Handshake = session/Layer 5, Application Data = presentation/Layer 6).

Mistake 3: Confusing ARP's layer placement

• Symptom: You place ARP at Layer 3 on a diagram, and your network engineer shakes their head.
• Why it happens: ARP resolves IP addresses (a Layer 3 concept) but operates using MAC addresses and Ethernet frames (Layer 2). Its position is genuinely debated.
• Fix: In practice, classify ARP as Layer 2/Layer 3 boundary or simply Layer 2. Wireshark captures ARP as a Layer 2 frame with no IP header. The RFC for ARP (RFC 826) does not use the OSI model at all — it predates it.

Mistake 4: Assuming Wireshark shows you Layer 7 data in encrypted HTTPS traffic

• Symptom: You apply the Wireshark filter http to HTTPS traffic and see nothing. You assume the capture is broken.
• Why it happens: HTTPS encrypts the HTTP payload at Layer 6 (TLS). Wireshark sees only the encrypted TLS Application Data record, not the HTTP/2 frames inside it.
• Fix: Use tls or tcp.port == 443 instead. To decrypt HTTPS in Wireshark, you need the session's pre-master secret exported from the browser (set env var SSLKEYLOGFILE=/path/to/keylog.txt in Chrome/Firefox). Only do this in a lab — never export TLS keys from a production session.

Mistake 5: Treating the TCP/IP model as a replacement for OSI

• Symptom: You describe a threat using only TCP/IP layer names (e.g., "Internet layer attack") in a vendor report, and the client's team is confused.
• Why it happens: The two models have different layer counts and names. TCP/IP is what runs; OSI is the universal diagnostic language.
• Fix: Always map to both in professional communication: "This is a Layer 3 (Network/Internet layer) ICMP tunneling technique." Most security frameworks (MITRE ATT&CK, NIST) use OSI layer numbering.

Interview Questions

Question 1 — Conceptual: "Explain the difference between the OSI model and the TCP/IP model. Which one do real protocols use?"

Model Answer: The OSI model is a 7-layer reference framework developed by ISO to describe how network communications should be structured — it's a teaching and diagnostic tool. The TCP/IP model is a practical 4-layer implementation that maps directly to the protocols that actually power the internet (TCP, IP, HTTP, etc.). Real protocols use TCP/IP. When a SOC analyst says "this is a Layer 3 attack," they're using OSI vocabulary to describe a TCP/IP Internet-layer event — the two models are complementary, not competing. The OSI model's granularity (especially distinguishing Layer 5 Session from Layer 6 Presentation) is what makes it useful for precise incident analysis.

Maps to: CompTIA Network+ N10-008 Objective 1.1 | CompTIA Security+ SY0-701 Domain 3.1

Question 2 — Scenario-Based: "During an investigation, you notice a host is sending ICMP echo requests with 512-byte payloads to an external IP every 60 seconds. Which OSI layer is the primary concern, and what MITRE ATT&CK technique does this suggest?"

Model Answer: The primary concern is Layer 3 (Network layer) because ICMP is a Layer 3 protocol — the anomaly is in the IP/ICMP packet itself. Standard ICMP echo requests carry 32–56 bytes of payload; 512-byte payloads are a strong indicator of ICMP tunneling, mapped to MITRE ATT&CK T1095 (Non-Application Layer Protocol). The 60-second interval also suggests beaconing, which maps to T1071 (Application Layer Protocol) if the data being tunneled is C2 traffic. Detection involves a Layer 3/4 firewall rule limiting ICMP payload size, combined with a Snort/Suricata rule alerting on icmp with dsize > 64.

Maps to: CompTIA CySA+ CS0-003 Domain 2 | MITRE ATT&CK T1095

What You Can Now Do

You can now walk any network communication — including the HTTPS alert that opened this lesson — down through all seven OSI layers and the four TCP/IP layers, name the correct PDU at each layer, identify which protocols operate where, and articulate what a SOC analyst specifically looks for at each level. You have a reference table you can use immediately in Wireshark, Splunk, and incident reports. In the next lesson, you will extend this framework to the hands-on mechanics of the TCP 3-way handshake and 4-way teardown, capturing the exact SYN/SYN-ACK/ACK/FIN packets in Wireshark and mapping each flag to the connection state it represents.

Key Terms

• OSI Model: A 7-layer reference framework (ISO/IEC 7498-1) that standardizes the functions of a telecommunication system, used as the universal diagnostic vocabulary in networking and security.
• TCP/IP Model: A 4-layer practical implementation of layered networking that maps to the protocols actually used on the internet (also called the Internet model or DoD model).
• Protocol Data Unit (PDU): The name for the data package at each layer — Bits (L1), Frame (L2), Packet (L3), Segment (L4), and Data (L5–L7).
• Encapsulation: The process of wrapping data with a layer's header (and sometimes trailer) as it travels down the sender's stack from Layer 7 to Layer 1.
• De-encapsulation: The reverse process on the receiver's side — each layer strips its header and passes the payload up to the next layer.
• TLS (Transport Layer Security): A cryptographic protocol spanning OSI Layers 5–6 that provides encryption, authentication, and integrity for application data in transit.
• JA3 Fingerprint: A hash of TLS ClientHello parameters (cipher suites, extensions, elliptic curves) used to identify specific TLS client software, including malware, even through encrypted traffic.
• ARP (Address Resolution Protocol): A Layer 2/3 boundary protocol that resolves IPv4 addresses to MAC addresses within a local network segment; a common vector for man-in-the-middle attacks via ARP poisoning.