Where the Series Begins#

This is the opening volume of a five-part journey through Security Architecture. Over the series we will walk the entire stack, from copper to container, and the map looks like this:

• Volume I (this one) - the foundations: the network as an attack surface, defensible design, defense in depth, threat modeling, and the attacker’s method.
• Volume II - Identity, Access & the Zero Trust Frontier: when the perimeter dissolves, identity becomes the new boundary.
• Volume III - Cryptography Engineering: the primitives that make any of it trustworthy.
• Volume IV - Detection, Response & Threat Intelligence: what you do when prevention fails.
• Volume V - Cloud-Native & Supply Chain Security: securing the ephemeral, and proving what you ship.

What makes this guide different is its method. Every topic is examined through four pairs of eyes, because a real system is argued over by four kinds of engineer at once:

• The Network Engineer who builds the foundation.
• The Defender who has to protect it.
• The Hacker who tries to break it.
• The Software Engineer who writes the code that runs on it.

The thesis of the whole series

No single control is trustworthy. Firewalls fail, credentials leak, code has bugs, and dependencies get poisoned. Security is therefore not a product you buy but a property you engineer: layers that each assume the one before it has already failed. This volume builds the outermost layers and the mindset. The rest of the series builds inward.

Part I: The Network Is the Territory#

Data communication begins at the network, and so does attack. A superficial reading of the OSI or TCP/IP model is not enough ¹; a security professional reads each layer twice, once for what it does and once for how it can be turned.

graph TD
    A7["L7 Application - HTTP, DNS, TLS<br/>SQLi, XSS, SSRF, auth flaws"]
    A4["L4 Transport - TCP, UDP<br/>SYN flood, port scanning"]
    A3["L3 Network - IP, ICMP, BGP<br/>IP spoofing, BGP hijack, DoS"]
    A2["L2 Data Link - Ethernet, ARP<br/>ARP spoofing, MAC flooding, VLAN hopping"]
    A1["L1 Physical - Cables, RF<br/>Tapping, rogue implants, port access"]
    A7 --> A4 --> A3 --> A2 --> A1

sequenceDiagram
    participant V as Victim
    participant A as Attacker
    participant G as Gateway
    Note over V,G: Before - Victim reaches the Gateway directly
    A->>V: forged ARP - the Gateway is at my MAC
    A->>G: forged ARP - the Victim is at my MAC
    Note over A: Attacker is now in the middle
    V->>A: traffic intended for the Gateway
    A->>G: relayed, after reading or altering it
    G-->>A: response
    A-->>V: relayed back

flowchart LR
    NET(["Internet"]) --> EFW["Edge Firewall / NGFW"]
    EFW --> DMZ["DMZ<br/>web + reverse proxy"]
    DMZ -->|"443 only, inward"| APP["App Tier<br/>business logic"]
    APP -->|"DB port only"| DATA[("Data Tier<br/>databases")]
    EFW -. "deny direct path" .-> DATA

Part II: Defense in Depth - and Why It Is This Series#

Defense in depth is the recognition that any one control will fail, so you build layers that each buy time, visibility, and another chance to stop the attacker ²⁰. The medieval castle is the tired-but-perfect analogy: moat, wall, archers, keep, crown jewels, and the guards who tie it together.

Here is the move that organizes this whole series: each layer of the castle is a volume.

mindmap
  root((Security in Depth))
    Vol I - Foundations
      Network segmentation
      Perimeter and controls
      Defense in depth
      Threat modeling
    Vol II - Identity
      Identity is the perimeter
      Zero Trust
      Least privilege
    Vol III - Cryptography
      Confidentiality and integrity
      TLS and key management
      Post-quantum
    Vol IV - Detection
      Assume breach
      Detect on behavior
      Respond and learn
    Vol V - Cloud-Native
      Shared responsibility
      Shift-left
      Supply chain trust

• The moat and outer wall are network perimeter and segmentation - this volume.
• The guard at every door is identity and access - Volume II.
• The sealed messages the guards trust are cryptography - Volume III.
• The archers watching for the breach are detection and response - Volume IV.
• The provenance of the stones themselves is supply chain and cloud-native security - Volume V.

The Hacker’s View: an attacker sees the layers as obstacles and hunts for the weakest seam in each. A perfect firewall is worthless if an employee clicks a phishing link; flawless code is worthless on an unpatched host. Depth matters precisely because the attacker only needs one path, and depth is how you make sure no single failure is that path.

Part III: Threat Modeling - Thinking Like an Attacker on Purpose#

Threat modeling is a structured way to find the weak seams before you build them ²¹. It is proactive, cheap, and one of the highest-leverage security activities a team can do. The canonical mnemonic is Microsoft’s STRIDE ²².

Consider a mundane endpoint: PUT /api/users/{id}. Draw its data-flow diagram first, marking the trust boundary where data crosses from the hostile outside into your infrastructure.

flowchart LR
    U(["User / Browser"]) -->|HTTPS| GW["API Gateway"]
    subgraph TB["Trust boundary - your infrastructure"]
      GW --> SVC["User Service"]
      SVC --> DB[("User DB")]
    end

Now walk STRIDE across every element and flow:

Most real-world breaches begin with the two ends of that table: Spoofing (broken authentication) and Elevation of privilege. The single most common web flaw, an Insecure Direct Object Reference (IDOR), is just Spoofing wearing a URL - the app trusts a user-supplied {id} without checking that this user may touch that object ²³.

Enumerating threats is only half the job; you cannot fix everything, so you rank by likelihood × impact and spend your budget where the product of the two is highest.

quadrantChart
    title Threat Prioritization - Likelihood vs. Impact
    x-axis Low Likelihood --> High Likelihood
    y-axis Low Impact --> High Impact
    quadrant-1 "Critical - fix now"
    quadrant-2 Plan remediation
    quadrant-3 Accept or monitor
    quadrant-4 Contain the blast radius
    "Phishing into a flat network": [0.85, 0.9]
    "Unpatched public VPN": [0.72, 0.95]
    "Malicious insider": [0.35, 0.7]
    "Lost laptop (encrypted)": [0.4, 0.18]
    "DoS on the marketing site": [0.62, 0.25]

Here is the same discipline as a repeatable loop you can run in a one-hour design meeting:

:::

Part IV: The Attacker’s Method#

To break the chain you must first see it. Lockheed Martin’s Cyber Kill Chain models a typical intrusion as seven stages; the defender’s goal is to break it as early as possible, because cost-to-remediate climbs at every step ²⁴.

flowchart LR
    R["1. Recon"] --> W["2. Weaponize"] --> D["3. Deliver"] --> X["4. Exploit"] --> N["5. Install"] --> C["6. C2"] --> O["7. Actions on Objectives"]

Reconnaissance blends passive OSINT with active probing (port scans, DNS enumeration, Shodan sweeps). Weaponization and delivery build and ship the payload - overwhelmingly by phishing, still the number-one way in:

pie showData
    title How attackers get their first foothold
    "Phishing and social engineering" : 36
    "Stolen or weak credentials" : 27
    "Unpatched public-facing vuln" : 21
    "Misconfiguration" : 10
    "Supply chain / third party" : 6

After exploitation and installation, the attacker “calls home” over a C2 channel and begins actions on objectives. Post-foothold, the tradecraft shifts to staying quiet:

• Lateral movement - hop from the first host toward the crown jewels. In a Windows domain this means dumping credentials from memory and reusing them, often via Pass-the-Hash, no plaintext password required.
• Persistence - survive reboots and patches with a foothold that regrows.
• Living off the Land (LotL) - avoid custom malware entirely; use PowerShell, PsExec, and other tools already trusted on the box, so nothing looks out of place.

Why the perimeter alone can never win

LotL is the reason Volume I’s walls are necessary but not sufficient. An attacker using only legitimate, signed system tools throws no signatures for a firewall or antivirus to match. Catching them requires watching behavior - a Word document that spawns PowerShell that opens a network socket - which is the province of Volume IV and its map of attacker behavior, MITRE ATT&CK. Prevention assumes you can keep them out. Detection assumes you could not.

Part V: Secure by Design#

The cheapest vulnerability is the one never written. Shifting left means moving security earlier in the lifecycle, where a fix costs a code review instead of an incident ²⁵.

flowchart LR
    RQ["Requirements<br/>security stories"] --> DS["Design<br/>threat modeling"]
    DS --> IM["Implement<br/>secure coding, SAST"]
    IM --> TS["Test<br/>DAST, pen test"]
    TS --> DP["Deploy<br/>IaC scan, secrets mgmt"]
    DP --> OP["Operate<br/>monitor, respond"]
    OP -->|"lessons feed back"| RQ

Under the pipeline sit a handful of principles that predate the cloud and will outlive it - the timeless design rules articulated by Saltzer and Schroeder ²⁶:

• Least privilege - every principal gets the minimum access it needs, and nothing more.
• Fail-safe defaults - deny by default; grant by exception.
• Complete mediation - check every access, every time, not just the first.
• Economy of mechanism - keep the security-critical parts small enough to audit.
• Defense in depth - the through-line of this entire series.

These are the constants. The specifics of how you satisfy them are where the rest of the series lives, and Volume I deliberately hands each one off rather than duplicating it:

• Authentication, authorization, session management, and secrets - Volume II.
• “Never roll your own crypto,” how TLS actually works, and how to manage keys - Volume III.
• The SOC, SIEM/SOAR, threat hunting, and the incident-response lifecycle you run when a control fails - Volume IV.
• Container and Kubernetes hardening, IaC scanning, SBOMs, and defending the dependency supply chain (remember Log4Shell ²⁷) - Volume V.

The mental model to carry forward

Read every later volume as a deeper answer to a question raised here. Volume I asks “how do we keep the attacker out and slow them down?” - and each answer eventually admits its own limit, which is the question the next volume opens with. That chain of honest limits is the series.

Conclusion & The Road Ahead#

We started at the physical layer - a cable, a switch, a forged ARP reply - and climbed to a design meeting where four engineers argue over a data-flow diagram. Along the way we built the outer defenses: a segmented, defensible network; layered controls that assume each other’s failure; a repeatable way to find weak seams before an attacker does; and a clear-eyed model of how that attacker actually operates.

graph LR
    I["Vol I<br/>Foundations and Networks"] --> II["Vol II<br/>Identity and Zero Trust"] --> III["Vol III<br/>Cryptography"] --> IV["Vol IV<br/>Detection and Response"] --> V["Vol V<br/>Cloud-Native and Supply Chain"]

The modern systems engineer must be a polymath - reasoning about the packet and the application logic, the firewall rule and the container manifest, thinking like a builder, a defender, and a breaker at once. Security is not a feature you add. It is a property of a system engineered, at every layer, to survive the failure of the layer beside it.

We built walls in this volume. But the moment laptops go home, servers move to someone else’s data center, and APIs call APIs across the open internet, the wall stops describing reality. The “inside” you were protecting dissolves into a swarm of principals - people, services, devices, workloads - each asking to do something, each needing to prove who it is and what it may touch.

That is where Volume II - Identity, Access & the Zero Trust Frontier begins. Identity is the new perimeter, and every request is a border crossing. See you there.

References#