// networking basics — module 00

Module 0 — Orientation: The Shared Language of Security

Soren Brumbach · 2026-07-19 · 8 min read

Thesis: Before any tool or packet, security is a language. Beginners lose weeks to fuzzy definitions — mixing up "threat" and "vulnerability," or believing Base64 is encryption. Nail the vocabulary and the ethics down now, and every later module reads cleanly, because it's all built on these words.

Prerequisite: the Linux Foundations course. This is the beginning of the security course.

0.1 Why start with words

Security has a precise vocabulary, and precision here is not pedantry — it's the difference between a report someone can act on and a report they ignore. When you eventually write "the asset is the customer database; the vulnerability is an unpatched SQL injection; the risk is high because it's internet-facing," every word in that sentence is doing a specific job. Muddle the words and you muddle the thinking.

This module has almost no hands-on component. That's deliberate. It's the frame every later module hangs on. Read it slowly, say the definitions out loud, and come back to it whenever a later term feels slippery.

0.2 The CIA triad — the three goals all security serves

Every security control that has ever existed is protecting one or more of exactly three things. This is the root of the whole field.

Confidentiality — only authorized people can read the data. (Encryption, access controls, and permissions all serve this.)
Integrity — the data hasn't been tampered with, and you can tell if it was. (Hashing, digital signatures, and checksums serve this.)
Availability — the data or system is there when it's needed. (Backups, redundancy, and DDoS protection serve this.)

        Confidentiality
             /\
            /  \
           /    \
          /      \
         /  C I A \
        /__________\
  Integrity      Availability

The power of the triad is that it's exhaustive in a useful way. Every attack violates at least one leg; every defense protects at least one leg. When you meet DNS in Module 4, you'll immediately see all three: leaking queries is a confidentiality problem, poisoning answers is an integrity problem, and flooding a server offline is an availability problem. The triad turns a pile of disconnected facts into a system with three drawers to sort them into.

A fourth idea often rides alongside: non-repudiation — you can't credibly deny you did something, because there's cryptographic proof (a signature) that you did. Keep it in your back pocket; it becomes concrete in Module 7.

0.3 AAA — the machinery of access

Where CIA is about goals, AAA is about the gate every system puts in front of its resources:

Authentication — who are you? Proving identity (a password, a key, a fingerprint).
Authorization — what are you allowed to do? Deciding, once you're known, which actions and data you can reach.
Accounting / Auditing — what did you do? Recording actions so they can be reviewed later.

These are three distinct steps and they fail in distinct ways. A system can authenticate you correctly and still authorize you for too much (the root cause of countless breaches). It can authorize correctly but keep no audit trail, so an intrusion is invisible after the fact. You'll return to authentication vs. authorization in depth in Module 9 — for now, fix that they are not the same step.

0.4 The precise vocabulary — memorize these distinctions

This is the set of words beginners most often blur together. Learn the boundaries, because half of security writing is using them correctly.

Asset — something worth protecting. A database, a laptop, a reputation, a human life.
Threat — a potential cause of harm. A hurricane, a burglar, a piece of malware, a disgruntled employee. Threats exist whether or not you're vulnerable to them.
Vulnerability — a weakness that a threat could exploit. An unlocked window, an unpatched service, a reused password.
Exploit — the actual technique or code that takes advantage of a vulnerability. The crowbar in the window; the specific program that abuses the unpatched service.
Risk — the combination of how likely a threat is to hit a vulnerability and how bad it would be if it did. Risk is what you actually manage; you rarely eliminate it, you reduce it. Informally: Risk ≈ Likelihood × Impact.
Attack surface — every point where an attacker could try to get in. Every open port, every input field, every employee who can be phoned.
Attack vector — the specific path actually used in an attack. One route across the attack surface.

Worked example. Your house is the asset. A burglar is a threat. The unlocked back window is a vulnerability. Climbing through it is the exploit. The chance a burglar tries and the window is unlocked and you lose something valuable is the risk. Every door and window together is the attack surface; the back window they actually used is the attack vector.

Getting these wrong wastes real time on the job. "We found a threat" (you mean a vulnerability) sends people looking in the wrong direction. Say what you mean.

0.5 Core defensive principles

A handful of design principles recur in every well-built system. You'll see all of them again.

Defense in depth — never rely on a single control. Layer them, so that when one fails (and one always eventually fails), another is still standing. A firewall and host hardening and monitoring and least privilege.
Least privilege — every user, process, and service gets only the access it needs to do its job, and no more. Over-privileged accounts are the root of a huge share of breaches (Module 9).
Zero trust — "verify everything, trust nothing by default." Don't assume traffic is safe because it's coming from inside the network; authenticate and authorize every request regardless of origin.
Fail-safe / secure defaults — when something breaks, it should break closed (deny access), not open. And the out-of-the-box configuration should be the safe one, because most systems are never reconfigured.

0.6 The split you're preparing for

This whole course exists to get you to a fork in the road. The two directions:

Red team — offense. Simulate real attackers to find and prove weaknesses before a genuine adversary does. Reconnaissance, exploitation, post-exploitation, reporting.
Blue team — defense. Detect, respond to, and harden against attacks. Monitoring, detection engineering, incident response, threat hunting.
Purple team — the two working together deliberately: red demonstrates an attack, blue builds the detection for it, and they iterate.

Here is the insight that justifies this entire foundation course: both tracks read the same packets, use the same operating-system knowledge, and write the same scripts. They just point them in opposite directions. A packet capture is evidence to a defender and reconnaissance to an attacker — same capture, same skill. That's why we teach the shared base first and let you specialize after you can do the groundwork either one requires.

Throughout the course, the → Red/Blue notes make this explicit for each topic.

0.7 Ethics and law — the non-negotiable part

Read this section as if your future depends on it, because it does.

The skills in this course are neutral. Scanning a network, cracking a hash, and exploiting a vulnerability are the same keystrokes whether you're a paid penetration tester or a criminal. The one thing that separates the two is authorization.

The rule, stated plainly:

You may only test systems you own, or systems you have explicit, written authorization to test — and only within the agreed scope.

Three words carry the weight:

Explicit — implied permission is not permission. "They probably won't mind" is how people get prosecuted.
Written — verbal permission evaporates the moment something goes wrong. Get it on paper (or in a signed contract / engagement letter).
Scope — authorization covers specific systems, specific techniques, and a specific time window. Testing something outside the agreed scope is unauthorized even if you were hired to test something.

In professional work these live in a document called the rules of engagement (ROE): what you're allowed to touch, what's off-limits, when you can test, and who to call if something breaks. Unauthorized access to computer systems is a crime in essentially every jurisdiction (in the US, the Computer Fraud and Abuse Act; elsewhere, direct equivalents), regardless of whether you caused harm or "just looked."

Where you are free to practice, and where every lab in this course lives:

Systems you own — your own lab (Module 1 builds it).
Deliberately vulnerable targets — VMs and web apps built to be attacked for training.
Sanctioned platforms — online ranges and capture-the-flag events that grant explicit permission by design.

This is not a section to skim. Internalize it now, because every powerful technique after this point assumes you already have.

Lab 0

No VMs yet — this module's work is conceptual, and it matters.

Sort three systems into the triad. Pick three everyday systems you use — your email, your bank account, a game save. For each, name one concrete threat to confidentiality, one to integrity, and one to availability. (Example for a bank: someone reading your balance = C; someone altering a transaction = I; the app being down on payday = A.)
Write the definitions cold. On paper or in this vault, write one-sentence definitions of threat, vulnerability, exploit, and risk without looking at §0.4. Then check yourself. Rewrite any that were fuzzy.
Read a real advisory. Find a published vulnerability advisory (a CVE — you'll meet these formally in Module 12; for now just read one, e.g. on the NVD website or a vendor's security page). Identify, in the advisory's own details: the asset at risk, the vulnerability, and the potential impact. Notice how the advisory itself uses this vocabulary.
State the rule from memory. Close this file and write the one-sentence authorization rule from §0.7 in your own words. Then list the three kinds of place you're allowed to practice.

✅ Mastery Check — do not proceed until true

Answer out loud, without notes:

Name the three legs of the CIA triad and give one real control that protects each.
What is the difference between authentication and authorization? Give an example where one succeeds and the other still fails badly.
Define, in one sentence each: asset, threat, vulnerability, exploit, risk. Then use all five correctly in a single sentence about a house being burgled.
What is the difference between attack surface and attack vector?
Explain "defense in depth" and "least privilege" and why each exists.
What single thing separates a penetration tester from a criminal? Name the three properties good authorization must have.
Red, blue, purple — what does each do, and what is the one insight that makes it worth learning their shared foundation first?

When all of that is effortless: Module 1 — Build Your Lab (Virtualization & Safe Practice)