Network Security
OSI and TCP/IP as Security Frameworks
Map every layer of the network stack to the attacks that live there and the controls that stop them — so you always know where to look when something goes wrong.
The Argument That Saved a Network
A mid-size financial services firm was losing thousands of dollars an hour to an attack that nobody on the incident response call could agree on. The network team said the firewall was clean. The application team said the app logs showed nothing unusual. The infrastructure team pointed at the database. The argument went in circles for forty minutes — until one engineer asked: "Which layer are we actually looking at?" That question cut through everything.
The attack turned out to be a DNS amplification flood happening at the network layer — the application and database teams had been staring at entirely the wrong part of the stack. The network model was not a theoretical exercise. It was the shared vocabulary that made the right conversation possible.
This is why security professionals learn the OSI and TCP/IP models — not to pass a certification exam, but to have a precise language for where problems live and which controls address them. Without that precision, incident response becomes an expensive argument.
The OSI Model: Seven Layers, One Framework
The OSI model — Open Systems Interconnection — was developed by the International Organization for Standardization in the late 1970s as a way to describe how different networking components communicate without being tied to any single vendor's implementation. It divides network communication into seven distinct layers, each with a defined job and a defined interface to the layers above and below it.
Think of it as a very well-organized post office. The person writing a letter (Layer 7) does not care about the van route the delivery driver takes (Layer 3). The driver does not care whether the letter is in English or French (Layer 6). Each layer handles its own concerns and trusts the adjacent layers to handle theirs. When something breaks, you start at the physical cable and work up — or start at the application and work down — until you find the layer where the contract is being violated.
The Seven OSI Layers — Top to Bottom
Application — where user-facing software operates. HTTP, DNS, SMTP, FTP live here. Attacks: SQL injection, cross-site scripting, API abuse. Controls: WAFs, input validation, application firewalls.
Presentation — data translation, encryption, and compression. TLS encryption happens here. Attacks: SSL stripping, certificate spoofing. Controls: enforced TLS versions, certificate pinning, HSTS.
Session — manages the lifecycle of conversations between systems: establishing, maintaining, and terminating connections. Attacks: session hijacking, replay attacks. Controls: session token rotation, secure cookie flags.
Transport — TCP and UDP. Handles end-to-end delivery, ordering, and error correction. Port numbers live here. Attacks: SYN floods, port scanning, UDP amplification. Controls: stateful firewalls, rate limiting, TCP normalization.
Network — IP addresses and routing. Decides the path packets take across interconnected networks. Attacks: IP spoofing, ICMP floods, BGP hijacking. Controls: ingress/egress filtering, route authentication, firewalls.
Data Link — MAC addresses, Ethernet frames, switches. Governs communication between directly connected devices. Attacks: ARP spoofing, MAC flooding, VLAN hopping. Controls: dynamic ARP inspection, port security, 802.1X.
Physical — cables, fiber, radio waves, network interface cards. Attacks: wiretapping, jamming, hardware tampering. Controls: physical access controls, tamper-evident seals, shielded cabling in sensitive areas.
When a security control is described as "Layer 3" or "Layer 7," that tells you something precise: a Layer 3 firewall looks at IP addresses and makes decisions about routing — it has no idea what is inside the packet. A Layer 7 firewall can read the actual HTTP request and make decisions based on the URL, the method, the headers, and the payload. Same category of device, completely different visibility and capability.
TCP/IP: The Model the Internet Actually Runs On
The OSI model is elegant and precise — and the internet largely ignores it. What the internet runs on is the TCP/IP model, a four-layer framework developed by DARPA in the 1970s that predates OSI and remains the practical foundation of every networked device you have ever used.
TCP/IP collapses OSI's seven layers into four: Application (covering OSI's 5, 6, and 7), Transport (matching OSI's Layer 4), Internet (matching OSI's Layer 3), and Network Access (covering OSI's 1 and 2). Security professionals use both models. OSI for precision in describing where exactly something happens. TCP/IP for describing how actual traffic flows and where actual protocols operate.
Why Both Models Matter in Security
In a security context, OSI gives you a scalpel and TCP/IP gives you a map. When reading vendor documentation, firewall rule specifications, or IDS signatures, you will see both used interchangeably — sometimes in the same paragraph. A Palo Alto Networks next-generation firewall operating at "Layer 7" is using OSI language. A Wireshark filter for "TCP port 443" is using TCP/IP language. Knowing both fluently means you are never lost in translation when documentation switches between them.
How Packets Actually Move — and Where Attackers Intercept Them
When a TechPulse support agent opens a browser and logs into the customer management portal, their machine does not send a single indivisible message. It assembles data at the application layer, hands it down through each layer — each one adding its own header information — until a raw electrical or optical signal leaves the network interface card. At every point in that journey, a different attacker technique becomes relevant.
This process is called encapsulation. Each layer wraps the data it receives from the layer above in its own envelope — adding addressing, sequencing, error-checking, or routing information. At the receiving end, each layer strips its envelope and passes the contents up. The entire system depends on each layer trusting the headers added by its peer on the other side — and that trust is exactly what attackers exploit.
Physical & Data Link Attacks
Require physical proximity or local network access. ARP spoofing poisons the mapping between IP and MAC addresses, redirecting traffic to an attacker's machine. VLAN hopping lets an attacker send traffic into network segments they should not be able to reach. These are insider or adjacent-attacker threats — hard to execute remotely, devastating when achieved.
Network & Transport Attacks
IP spoofing forges the source address in a packet header so the response goes somewhere else — useful for reflection and amplification attacks. SYN floods overwhelm a server by filling its connection table with half-open TCP handshakes, leaving no capacity for legitimate connections. These are the attacks that volumetric DDoS protection is designed to absorb.
Session & Presentation Attacks
Session hijacking steals or forges the token that proves a user is authenticated, allowing an attacker to impersonate them without ever learning their password. SSL stripping downgrades an HTTPS connection to plain HTTP by intercepting the initial request before encryption is established — classic man-in-the-middle territory on unprotected networks.
Application Layer Attacks
The most common category by volume. SQL injection inserts database commands into input fields expecting plain data. Cross-site scripting embeds malicious scripts in web content that execute in other users' browsers. DNS attacks manipulate the naming system that translates domain names into IP addresses. These require no network position — just an internet connection and a vulnerable endpoint.
TechPulse: Meera Runs a Layer-by-Layer Security Review
After mapping TechPulse's assets, Meera built a threat matrix organized by OSI layer. At Layer 1 and 2, the HQ office had no 802.1X port authentication — any device plugged into a wall jack joined the corporate network without any verification. At Layer 3, ingress filtering was missing on the edge router, meaning spoofed source IPs could enter the network undetected. At Layer 4, the SIP phone system was reachable from the internet on UDP with no rate limiting. At Layer 7, the customer portal had no Web Application Firewall in front of it despite handling PII. The layered view turned a vague "we should improve security" mandate into a specific, ordered remediation list that the Engineering team could actually execute against.
Protocols That Security Teams Must Know Cold
Every protocol is a set of rules two systems agree to follow when communicating. Security vulnerabilities often live in the gaps between what a protocol was designed to do and how it gets implemented or used in production. Understanding the most important protocols means understanding exactly where those gaps are.
TCP — The Reliable Protocol
Transmission Control Protocol establishes a connection through a three-way handshake (SYN → SYN-ACK → ACK), guarantees delivery and ordering, and tracks every packet. This statefulness is both its strength and its attack surface — a SYN flood sends thousands of SYN packets without completing handshakes, filling the server's connection table and blocking legitimate traffic.
Used by: HTTP/S, SSH, SMTP, databases. Security relevance: stateful firewalls track TCP connections; anomalous handshake patterns are detectable.
UDP — The Fast Protocol
User Datagram Protocol fires packets without establishing a connection first. No handshake, no delivery guarantee, no ordering — just speed. That statelessness makes UDP ideal for DNS lookups, streaming, and VoIP. It also makes it the preferred vehicle for amplification attacks: send a small forged request to a UDP service, and a much larger response floods the spoofed victim.
Used by: DNS, DHCP, NTP, video streaming. Security relevance: harder to filter statefully; amplification factors of 50x or more are achievable with vulnerable UDP services.
DNS — the Domain Name System — deserves special mention because almost all network activity depends on it and almost all security products interact with it. DNS translates human-readable names like "techpulse-internal.com" into IP addresses. It was designed in the 1980s with zero authentication — any server could tell you that any domain resolves to any IP address, and the client had no way to verify the answer. DNSSEC was created to add cryptographic signatures to DNS responses, but deployment remains inconsistent. DNS is used for command-and-control communication by malware, for data exfiltration via DNS tunneling, and as a target for cache poisoning attacks that redirect users to malicious sites without touching their device.
The Plaintext Protocol Problem
Several foundational internet protocols — HTTP, Telnet, FTP, SMTP without TLS, early versions of SNMP — transmit data in plaintext. That means anyone on the network path between sender and receiver can read the contents in full. Inside a corporate LAN where an attacker has achieved a foothold, plaintext protocols are an intelligence windfall. Every password, every session token, every internal API call sent over Telnet or unencrypted HTTP is readable with a packet capture tool. The default posture in 2024 should be: if a protocol has an encrypted alternative, use it. If it does not, build compensating controls around it.
Applying the Stack to Real Security Decisions
The practical value of the layered model shows up in three common security situations: designing controls, troubleshooting incidents, and explaining coverage gaps to non-technical stakeholders.
When designing controls, the layer model tells you where each control can see. A network firewall at Layer 3 and 4 can block traffic based on IP address and port — but it is completely blind to the content of an encrypted HTTPS session. A Web Application Firewall at Layer 7 can inspect that content, but it sits further up the stack and never sees IP-level attacks. Neither control is wrong; they cover different ground. Defense in depth means having controls at multiple layers so an attacker who bypasses one immediately faces another.
When troubleshooting incidents, the layer model gives you a systematic methodology. A user reports they cannot reach an internal server. You start at Layer 1: is the cable plugged in, is the interface up? Move to Layer 2: is the switch port active, is the VLAN correct? Layer 3: is the route present, is the IP reachable with ping? Layer 4: is the port open, is the service listening? Layer 7: is the application responding correctly to valid requests? This bottom-up process finds problems in minutes that an ad hoc "check everything" approach might miss for hours.
Wireshark Speaks OSI
When you open a packet in Wireshark, the display pane shows the protocol stack exactly as the OSI model describes it — Frame (Layer 2), Internet Protocol (Layer 3), Transmission Control Protocol (Layer 4), Hypertext Transfer Protocol (Layer 7). Each section is collapsible and shows the raw header fields that protocol uses. Learning to read a Wireshark packet trace is directly equivalent to learning to read the OSI model in action. The model stops being abstract the first time you expand a TCP header and see the SYN flag set in a three-way handshake.
When explaining coverage gaps to leadership, the layer model provides an accessible analogy. A perimeter firewall is like a security guard at the building entrance — it checks who comes in through the front door. But it cannot see what happens once someone is inside (no visibility into lateral movement at Layer 2), and it cannot read the contents of sealed envelopes (encrypted application traffic at Layer 7). Describing what your controls see and what they are blind to, in layered terms, makes the investment case for additional visibility much clearer than vague references to "improving security posture."
TechPulse's Engineering team used exactly this argument to justify adding a network detection and response (NDR) tool that monitors east-west traffic — traffic moving between servers inside the network rather than between the internet and the perimeter. Their existing firewall only saw north-south traffic crossing the perimeter. An attacker who got inside faced no monitoring at all on internal movement. The layer-by-layer gap analysis made that invisible blind spot visible to every stakeholder in the room.
Quiz
1. Meera's monitoring tool alerts on suspicious ARP traffic within TechPulse's HQ office network — multiple IP addresses are being associated with a single MAC address, suggesting a spoofing attempt. At which OSI layer is this attack occurring?
2. TechPulse's customer portal is being targeted with SQL injection attempts embedded in HTTPS POST requests. The existing network firewall at the perimeter allows port 443 traffic through normally. Which additional control would be able to detect and block these attacks?
3. TechPulse's cloud environment is receiving a flood of large DNS response packets from dozens of open resolvers worldwide, overwhelming their ingress bandwidth — despite no staff making the corresponding DNS queries. Which attack technique is being used?