Security Foundations & Threat Modeling
Network security is the discipline of protecting data in transit, network infrastructure, and connected endpoints from unauthorized access, modification, inspection, or disruption. Every security decision boils down to balancing risk, performance, and usability.
Imagine sending a postcard through the mail. Anyone handling it can read the text (lack of Confidentiality), alter the writing with a pen (lack of Integrity), or throw it away so it never arrives (loss of Availability). Network security transforms your exposed postcard into a tamper-evident, sealed titanium lockbox delivered via an escort convoy.
In computer networks, security primitives are formalized through mathematical proofs: Confidentiality via authenticated symmetric ciphers (AEAD), Integrity via cryptographic MACs/hashes, Authentication via public-key cryptography (PKI/X.509), and Non-Repudiation through asymmetric digital signatures.
The CIA Triad & Beyond
The foundational model of information security comprises three interlocking pillars, augmented by the AAA framework:
Confidentiality
Ensuring data is readable only by authorized entities. Achieved in transit via symmetric encryption algorithms (e.g. AES-GCM, ChaCha20).
Integrity
Guaranteeing data cannot be silently modified or tampered with in transit. Enforced with cryptographic hash functions (SHA-256) and HMACs.
Availability
Ensuring services and data remain accessible to legitimate users during failures or attacks via redundancy, DDoS filtering, and rate limiting.
- Authentication (Who are you?): Verifying identity via passwords, cryptographic certificates, or MFA tokens.
- Authorization (What are you allowed to do?): Enforcing access policies (RBAC, ABAC) to resources.
- Accounting (What did you do?): Logging audit trails of network events and access attempts for forensic analysis.
Threat Modeling with the STRIDE Framework
Developed by Microsoft engineers, STRIDE provides a systematic methodology for categorizing network and software threats against specific security properties:
Threat Category Violated Property Common Network Vector
─────────────────────────────────────────────────────────────────────────────
S - Spoofing Authentication IP/ARP/DNS Spoofing, Rogue AP
T - Tampering Integrity Man-in-the-Middle (MITM) Packet Injection
R - Repudiation Non-Repudiation Unsigned API requests, missing audit logs
I - Information Disclosure Confidentiality Plaintext packet sniffing (Wireshark)
D - Denial of Service Availability SYN Flood, UDP Amplification, BGP Hijack
E - Elevation of Privilege Authorization VLAN Hopping, Exploiting Default GatewayDeep Dive: The Defense-in-Depth Layer MatrixArchitecture Reference
Defense-in-Depth (DiD) dictates that no single security control should represent a single point of failure. Security mechanisms must be layered across the entire stack:
| Layer | Primary Threats | Defensive Controls & Technologies |
|---|---|---|
| Physical (L1) | Cable tapping, rogue hardware implants | Locked server racks, 802.1X port security, MAC filtering |
| Data Link (L2) | ARP poisoning, DHCP rogue server, CAM table overflow | Dynamic ARP Inspection (DAI), DHCP Snooping, Port Security |
| Network (L3) | IP spoofing, ICMP redirect attacks, route hijacking | uRPF (Unicast Reverse Path Forwarding), RPKI BGP validation, IPsec |
| Transport (L4) | SYN floods, port scanning, session hijacking | Stateful Firewalls (SPI), SYN Cookies, TLS 1.3 |
| Application (L7) | SQLi, XSS, SSRF, credential stuffing, API abuse | Web Application Firewalls (WAF), mTLS, OAuth2/OIDC, Rate Limiting |
| Human / Ops | Phishing, social engineering, credential reuse | FIDO2/WebAuthn hardware keys, Least Privilege, Zero Trust IAM |
Cryptography & TLS 1.3 Architecture
Transport Layer Security (TLS) is the cryptographic protocol that secures modern internet communication (HTTPS, SMTPS, DoT, QUIC). Published in 2018 under RFC 8446, TLS 1.3 modernized network cryptography by stripping away legacy algorithms and optimizing the handshake to a single round trip (1-RTT).
Asymmetric cryptography is like an open padlock you hand out to the world. Anyone can snap it shut around a message box (public key), but only you have the physical key to unlock it (private key). Once you unlock it, you exchange a shared combination (symmetric key) for fast everyday conversations.
In TLS 1.3, key agreement uses Elliptic-Curve Diffie-Hellman Ephemeral (ECDHE) over Curve25519 (X25519) or secp256r1. Ephemeral public keys ($g^a, g^b$) are exchanged in plaintext ClientHello / ServerHello; both endpoints multiply points to derive the shared secret $g^(ab)$ without an on-path eavesdropper being able to calculate the discrete logarithm.
Symmetric vs. Asymmetric Cryptography
Modern secure channels use a hybrid cryptosystem: asymmetric cryptography authenticates identity and negotiates a shared secret, while symmetric cryptography encrypts the high-volume payload.
Symmetric Encryption (Bulk Data)
The same secret key encrypts and decrypts messages. Extremely fast because it uses CPU hardware acceleration (Intel AES-NI, ARMv8 Cryptography extensions).
Standards: AES-256-GCM, ChaCha20-Poly1305 (Authenticated Encryption with Associated Data - AEAD).
Asymmetric Encryption (Key Exchange & Identity)
Uses a mathematically linked key pair: a public key shared openly and a private key kept strictly confidential.
Standards: ECDHE (Elliptic Curve Diffie-Hellman Ephemeral: X25519, secp256r1) for key exchange; RSA-4096 / Ed25519 for digital signatures.
The TLS 1.3 Handshake (1-RTT)
In TLS 1.3, the client generates an ephemeral Diffie-Hellman key share in the very first packet (ClientHello). The server computes the shared secret immediately upon receipt and returns its own key share in ServerHello. All subsequent handshake messages (including the server's certificate) are fully encrypted.
Client Server
────── ──────
│ │
│ 1. ClientHello │
│ + Supported Ciphers (e.g. TLS_AES_256_GCM_SHA384) │
│ + KeyShare (Client's Ephemeral Public Key $g^a$) │
│ ────────────────────────────────────────────────────▶ │ (Derives Shared Secret $g^{ab}$)
│ │
│ │ 2. ServerHello
│ │ + Selected Cipher Suite
│ │ + KeyShare (Server's Public Key $g^b$)
│ │ ── ── ── ── ── ── ── ── ── ── ── ──
│ │ 3. {EncryptedExtensions}
│ │ 4. {Certificate} (Server X.509 Identity)
│ │ 5. {CertificateVerify} (Signature)
│ │ 6. {Finished} (HMAC over handshake transcript)
│ ◀──────────────────────────────────────────────────── │
│ (Derives Shared Secret $g^{ab}$, verifies Cert) │
│ │
│ 7. {Finished} │
│ 8. {Encrypted HTTP Application Data} │
│ ────────────────────────────────────────────────────▶ │ 9. {Encrypted Application Data}
│ ◀──────────────────────────────────────────────────── │ ◀── Full Bi-directional Encrypted Traffic- Perfect Forward Secrecy (PFS) is Mandatory: Static RSA key exchanges are forbidden. If a server's long-term private key is stolen in the future, past recorded encrypted traffic CANNOT be decrypted.
- Elimination of Broken Primitives: Deprecated MD5, SHA-1, RC4, DES, 3DES, static DH, and CBC-mode ciphers.
- Handshake Encryption: The server's identity certificate is encrypted in transit, preventing passive eavesdroppers on the network from identifying the server hostname via certificate inspection.
Deep Dive: X.509 PKI Trust Chains & OCSP StaplingPKI Mechanics
How does your browser know `cso.org` actually belongs to the intended server and not a hostile interception proxy?
Root Certificate Authority (Pre-installed in OS/Browser Trust Store)
│ Signs intermediate certificate with private key
▼
Intermediate Certificate Authority (e.g. Let's Encrypt R3)
│ Signs end-entity leaf certificate with private key
▼
Leaf / Server Certificate (CN=cso.org, SAN=*.cso.org, Contains Server Public Key)Certificate Revocation (OCSP vs OCSP Stapling): When a private key is compromised, the CA revokes the certificate. In traditional OCSP, the client queries the CA directly on every connection (introducing latency and privacy leaks). With OCSP Stapling (RFC 6066), the web server periodically fetches a cryptographically time-stamped revocation status from the CA and "staples" it directly inside the TLS handshake.
Perimeter Defenses, NAT & Segmentation
A network perimeter establishes a boundary between a trusted internal network and an untrusted external network (such as the public internet). Defensive perimeter design relies on firewalls, network address translation, and strict subnet segmentation.
Firewall Evolution: 3 Generations
Stateless Packet Filters
Inspects individual packets in isolation (Source IP, Dest IP, Port, Protocol). Blind to connection context and TCP state flags.
Stateful Inspection (SPI)
Maintains a dynamic State Connection Table (tracking SYN, ESTABLISHED, FIN/RST states). Automatically permits returning traffic for outbound connections.
Next-Gen / L7 WAF
Performs Deep Packet Inspection (DPI) up to Layer 7. Identifies specific application protocols, inspects HTTP payloads, and detects malware or SQLi payloads.
Network Address Translation (NAT) & Security Boundaries
Defined in RFC 1918, private IP address ranges (10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16) are non-routable on the public internet. Port Address Translation (PAT) maps thousands of internal private host sockets to a single public IP address using ephemeral source ports.
While NAT blocks unsolicited inbound connections by default (because no mapping entry exists in the NAT state table), it provides zero protocol validation, no packet filtering, and no inspection of outbound connections or payload content. A dedicated stateful firewall is always required.
DMZ (Demilitarized Zone) Architecture
A DMZ is a physical or logical subnet that isolates public-facing services (e.g. Web Servers, Mail Relays, Reverse Proxies) from the crown-jewel internal network (Database clusters, LDAP servers, HR records).
┌────────────────────────┐
│ Untrusted WAN │
│ (Public Internet) │
└───────────┬────────────┘
│
▼
┌────────────────────────┐
│ External Firewall │ (Permits only Port 80, 443 inbound)
└───────────┬────────────┘
│
┌───────────────┴───────────────┐
│ │
▼ ▼
┌─────────────────────┐ ┌─────────────────────┐
│ Public Web App │ │ API Reverse Proxy │ DMZ Network (Subnet 172.16.1.0/24)
└──────────┬──────────┘ └──────────┬──────────┘
│ │
└───────────────┬───────────────┘
│
▼
┌────────────────────────┐
│ Internal Firewall │ (Permits only Port 5432/Postgres from DMZ)
└───────────┬────────────┘
│
▼
┌────────────────────────┐
│ Internal Database │
│ & LDAP Infrastructure│ Secure Internal LAN (Subnet 10.0.10.0/24)
└────────────────────────┘Deep Dive: Linux Netfilter & nftables Kernel HooksKernel Architecture
In Linux operating systems, packet filtering and NAT are implemented inside the kernel via the Netfilter subsystem (managed by `iptables` and modern `nftables`):
Incoming Network Packet
│
│
▼
[ PREROUTING ] ── (DNAT occurs here)
│
[ Routing Decision: Is packet addressed to local machine? ]
/ \
Yes / \ No (Packet needs routing to another interface)
/ \
▼ ▼
[ INPUT ] [ FORWARD ]
│ │
Local Process │
│ │
▼ │
[ OUTPUT ] │
│ │
└────┬────┘
│
▼
[ POSTROUTING ] ── (SNAT / Masquerade occurs here)
│
▼
Outgoing Network PacketKey Connection States (`conntrack`): `NEW` (packet initiating a connection), `ESTABLISHED` (part of an active bi-directional stream), `RELATED` (associated helper connection, e.g. FTP data or ICMP errors), and `INVALID` (malformed or out-of-window packet).
Wireless & Remote Access Security (WPA3 & VPNs)
Radio frequency signals broadcast beyond physical building walls, making wireless communication inherently vulnerable to passive eavesdropping and rogue access point injection. Simultaneously, remote work demands encrypted tunnels across untrusted transit networks.
Wi-Fi Security: The Evolution to WPA3
| Standard | Encryption Cipher | Key Handshake & Vulnerabilities |
|---|---|---|
| WEP (1997) | RC4 (Stream cipher) | 24-bit initialization vectors (IV). Flawed key schedule allows cracking within 60 seconds of packet capture. Completely obsolete. |
| WPA2 (2004) | AES-CCMP | 4-Way Handshake (PSK). Vulnerable to offline dictionary/rainbow table attacks when pre-shared key is weak; susceptible to KRACK (Key Reinstallation Attacks). |
| WPA3 (2018) | AES-GCM-256 (Enterprise) / AES-CCMP-128 | Simultaneous Authentication of Equals (SAE) using the Dragonfly handshake. Immune to offline dictionary attacks; provides forward secrecy for all sessions. |
Virtual Private Networks (VPNs): WireGuard vs. IPsec vs. OpenVPN
A VPN encapsulates and encrypts network packets within an outer IP tunnel, granting remote endpoints a virtual presence inside an organization's internal private subnet.
WireGuard (Modern Standard)
Operates entirely in kernel space with ~4,000 lines of code. Cryptographic opinionated design using Curve25519, ChaCha20-Poly1305, and BLAKE2s. Fast roaming and instant handshake resumption.
IPsec (IKEv2 / ESP)
Layer 3 protocol suite built into enterprise routers and OS network stacks. Highly configurable with Tunnel Mode and Transport Mode, but complex state machines and heavy configuration overhead.
OpenVPN (Userland SSL/TLS)
Custom protocol running over TLS in user space (requires `tun`/`tap` device context switching). Highly flexible and bypasses firewalls via TCP 443, but incurs higher CPU context-switching latency.
Deep Dive: Enterprise 802.1X, RADIUS & EAP-TLS WorkflowEnterprise Auth
In enterprise corporate networks, shared pre-shared keys (PSK) are unacceptable. Instead, IEEE 802.1X port-based network access control authenticates individual devices and users:
[ Supplicant ] [ Authenticator ] [ Authentication Server ]
(Laptop / Phone) (Switch or Wireless AP) (RADIUS / FreeRADIUS)
│ │ │
│ 1. EAPOL-Start │ │
│ ────────────────────────────▶ │ │
│ 2. EAP-Request/Identity │ │
│ ◀──────────────────────────── │ 3. RADIUS-Access-Request │
│ 4. EAP-Response/Identity │ ─────────────────────────────────▶ │
│ ────────────────────────────▶ │ │
│ │ 5. EAP-TLS Handshake (Cert Exchange)│
│ ◀─────────────────────────── [ EAP Tunnel Encapsulated ] ────────▶ │
│ │ │
│ │ 6. RADIUS-Access-Accept │
│ │ + Pairwise Master Key (PMK) │
│ │ ◀───────────────────────────────── │
│ 7. 4-Way Handshake │ │
│ ◀───────────────────────────▶ │ (Port transitioned to UNBLOCKED) │Network Attacks & Packet-Level Mitigations
Network attacks exploit architectural trust assumptions across different layers of the OSI model. Securing a network requires recognizing how packet headers are manipulated and deploying deterministic protocol defenses.
1. Layer 2: ARP Poisoning & MITM
The Address Resolution Protocol (ARP) translates 32-bit IPv4 addresses to 48-bit MAC hardware addresses. By default, ARP is completely stateless and unauthenticated: hosts accept unsolicited ARP replies and overwrite their ARP cache tables.
[ Victim Client ] [ Attacker ] [ Default Gateway ]
IP: 192.168.1.50 IP: 192.168.1.99 IP: 192.168.1.1
MAC: AA:AA:AA:AA:AA:AA MAC: CC:CC:CC:CC:CC:CC MAC: BB:BB:BB:BB:BB:BB
│ │ │
│ │ 1. Fake ARP Reply: │
│ ◀───────────────────────────── │ "192.168.1.1 is at CC:CC..." │
│ (Victim ARP Table Poisoned) │ │
│ │ 2. Fake ARP Reply: │
│ │ "192.168.1.50 is at CC:CC..." │
│ │ ─────────────────────────────────▶ │
│ │ (Gateway ARP Table Poisoned)
│ │ │
│ 3. Outbound Internet Packet │ │
│ ─────────────────────────────▶ │ 4. Eavesdrops / Mutates Packet │
│ │ ─────────────────────────────────▶ │ (To WAN)- Dynamic ARP Inspection (DAI): Managed switches inspect all ARP packets against the authoritative DHCP Snooping binding database. Unmatched fake ARP announcements are dropped at the switch port.
- Static ARP Bindings: Hardcoding critical default gateway MAC addresses in sensitive server subnets.
2. Layer 4: TCP SYN Flood & Exhaustion
During a standard TCP 3-way handshake, the server allocates a Transmission Control Block (TCB) in kernel memory upon receiving a `SYN` packet and waits for the client's `ACK`. In a SYN flood, an attacker sends millions of spoofed SYN packets and never completes the handshake, filling the server's SYN backlog queue and denying service to legitimate clients.
Deep Dive: The Mathematics of SYN Cookies (RFC 4987)Kernel Algorithm
SYN Cookies allow a server to completely bypass allocating kernel memory state during the initial SYN packet. The server encodes the connection state inside its 32-bit Initial Sequence Number (ISN):
32-bit SYN Cookie Initial Sequence Number (ISN) Layout:
┌──────────────────┬────────────────────────┬────────────────────────────────────────┐
│ Top 5 bits: │ Middle 3 bits: │ Bottom 24 bits: │
│ Slow-moving │ MSS (Maximum Segment │ Cryptographic MAC Hash: │
│ Timestamp counter│ Size) index table │ SHA-1(SrcIP, DstIP, SrcPort, DstPort, │
│ (mod 32 minutes) │ │ SecretKey, Timestamp) │
└──────────────────┴────────────────────────┴────────────────────────────────────────┘When the legitimate client returns `ACK` (acknowledging $ISN + 1$), the server subtracts 1 from the sequence number, recomputes the MAC hash, verifies the timestamp, and only then allocates socket memory!
3. Layer 7: DNS Cache Poisoning & DNSSEC
Because traditional DNS runs over unauthenticated UDP on port 53, an attacker who guesses a query's 16-bit Transaction ID (`TXID`) can inject forged DNS response records into a resolver's cache (the Kaminsky attack), redirecting users to phishing mirrors.
DNSSEC (Cryptographic Validation)
Adds cryptographic signatures to DNS records (`RRSIG`, `DNSKEY`, `DS`). Validating recursive resolvers verify signatures up to the root zone trust anchor (`.`).
DoH (DNS over HTTPS) / DoT (DNS over TLS)
Encrypts the transport channel between the client stub resolver and the upstream resolver, preventing ISP eavesdropping and local LAN spoofing.
Zero Trust & Application-Layer Security
The traditional network security paradigm followed the Castle-and-Moat model: everything outside the firewall was untrusted, but once inside the internal corporate LAN, everything was implicitly trusted. Modern threats, insider risk, cloud hosting, and mobile workforces have rendered this perimeter-only model obsolete.
The Zero Trust Core Tenet: "Never Trust, Always Verify"
Formalized in NIST SP 800-207, Zero Trust assumes the network is already hostile and that attackers are already present inside the network boundaries.
Verify Explicitly
Always authenticate and authorize based on all available data points (user identity, device posture, location, anomaly heuristics).
Use Least Privilege Access
Limit user and service access with Just-In-Time (JIT) and Just-Enough-Access (JEA) policies, role-based controls, and adaptive risk scoring.
Assume Breach
Minimize blast radius by micro-segmenting networks, encrypting all end-to-end traffic (mTLS), and instrumenting continuous threat visibility.
Mutual TLS (mTLS) for Microservices
In standard TLS, only the server provides a certificate to prove identity. In mTLS, both client and server present X.509 certificates to each other. This guarantees cryptographic authentication and authorization for every inter-service API call within a cloud or Kubernetes cluster.
Essential HTTP Security Headers
| Security Header | Recommended Production Value | Attack Mitigated |
|---|---|---|
Strict-Transport-Security | max-age=63072000; includeSubDomains; preload | SSL Stripping, man-in-the-middle HTTPS downgrade attacks. |
Content-Security-Policy | default-src 'self'; script-src 'self'; object-src 'none'; | Cross-Site Scripting (XSS) and malicious script injection. |
X-Content-Type-Options | nosniff | MIME-confusion and drive-by download exploits. |
X-Frame-Options | DENY or SAMEORIGIN | Clickjacking and UI redress attacks in nested iframes. |
Referrer-Policy | strict-origin-when-cross-origin | Leaking sensitive URL parameters or internal tokens to 3rd-party sites. |
Interactive Simulators & Protocol Lab
Experiment with protocol mechanics directly in your browser. Run step-by-step cryptographic handshakes and evaluate firewall packet filtering rules in real time.
Knowledge Check & Defense Checklist
Test yourself on core network security principles with this quick 4-question interactive diagnostic:
1. Why does TLS 1.3 guarantee Forward Secrecy even if the server's long-term private key is compromised 5 years later?
2. How does Dynamic ARP Inspection (DAI) prevent Layer 2 ARP Poisoning / Man-in-the-Middle attacks?
3. How do SYN Cookies protect a server against massive TCP SYN Flood attacks without allocating kernel memory?
4. What is the defining principle of Zero Trust Architecture compared to traditional perimeter defenses?
Layered Network Hardening Checklist
Interactive defense baseline for production infrastructure: