CYBER-01-003-P · Primer — Attack Surface

The idea in one sentence

Your attack surface is the sum of every way an attacker can reach your system — every feature, port, endpoint, and dependency you ship is one of those ways.

Why it exists

Security teams needed a single word for "how much of us is exposed." Imagine a suburban house: each front door, back door, basement window, and even the pet flap is a potential entry point. If the house has two doors and one small window, you can lock and monitor them easily. If it has fifty doors, skylights, and hidden crawl‑space hatches, the task of securing the property explodes. Software behaves the same way—only the doors are invisible code paths. Every public API, login form, or third‑party library you pull in quietly adds another opening. The term attack surface gives you a concrete thing to count, shrink, and reason about instead of guessing.

How it works

The surface is the set of all reachable entry points plus the paths behind them. You enumerate it in two beats.

1. The doors – list every open network port, HTTP endpoint, input field, file‑upload handler, message queue, and each third‑party dependency that executes code.
2. The reach – for each door, identify what an attacker can manipulate once they get past it (e.g., parameters they can inject, files they can write, services they can invoke).

Worked example: A simple web service runs on a VM with three open ports (22 SSH, 80 HTTP, 443 HTTPS). It exposes two HTTP endpoints (/login, /upload) and uses two libraries: a JSON parser and an image‑processing module.

• Doors: 3 ports + 2 endpoints + 2 libraries = 7 doors.
• Reach: SSH allows command execution, HTTP login allows credential brute‑force, upload allows arbitrary file write, the JSON parser can be fed malformed data, the image module can trigger a buffer overflow. That adds roughly 5 distinct attack vectors.
• Total surface map: 7 doors × (average 1‑2 reachable actions) ≈ 12 distinct ways an attacker could interact with the system.

Defenders use that map two ways — harden the doors that must stay open (e.g., restrict SSH with key‑based auth, validate upload files) and, more powerfully, close the doors that never needed to be open at all (remove the unused image‑processing library, shut down the SSH port if not required).

See it — Attack surface shows entry points and their reachable impact

flowchart LR
A["Attack Surface"]
B["Doors<br/>Ports & APIs"]
C["Inputs<br/>Uploads"]
D["Reduction"]
E["Defender"]
A --> B
A --> C
D --> A
E --> D

The one gotcha

The hidden danger is that every feature you ship automatically becomes a door, even if you never intend to use it. A debug endpoint left enabled, a stray open port, or a library imported for a one‑off script all create attack paths. Teams often focus on fortifying the doors they know they need and overlook the dozens of doors that sit idle. The cheapest, highest‑impact security win is not adding a stronger lock—it’s eliminating an unnecessary door: disable the feature, close the port, or drop the dependency. If the code never ships, the attacker never gets a foothold.

The one-line takeaway

Every feature is a door; close the ones you don't need.

Where you'll meet it

You will meet attack surface every time you review a Dockerfile bloated with unused packages, expose a new API route, or run a dependency audit like npm audit or Dependabot. NIST SP 800-160 treats attack surface reduction as a core design principle, and OWASP folds it into secure-defaults and hardening guidance — minimal images, disabled debug modes, and fewer open ports are all the same move.

Named concepts: attack surface, attack surface reduction