index

Cybersecurity Index

Purpose

This is the root index for the cybersecurity branch of the vault.

The goal of this system is to move from: - learning isolated security concepts

to: - building a connected security knowledge graph - understanding exposure, exploitation, and defense as one system - linking concepts to practical workflows, playbooks, and engineering decisions

This vault is structured to support: - security learning - practical testing - architecture reasoning - long-term retrieval by both me and LLM-assisted workflows


How this vault is organized

The vault is split into canonical branches.

Orientation (start here)

The framework everything else assumes — read first.

Substrate (how things actually work)

Read in order. Networking is the substrate of everything else, Web Security is the daily surface, Cryptography is the correctness layer.

Offense / Defense (paired)

Read note-by-note as pairs. Studying one half plateaus you.

Operator surface

What is actually exposed, where evidence comes from, and how concepts become repeatable procedures.

Specialty tracks (job-context choice)

Pick what your job demands. These are not prerequisites for each other.

Always-on (parallel personal discipline)

Not a phase. Read alongside everything else.


Roadmap v2 — landed 2026-05-10. Reorganized for the IT-person-entering-cyber learner. Phase 0 names the mental models; Phase 1 teaches the substrate (Networking first because it is the substrate of everything else, then Web Security as the daily surface, then Cryptography once TLS/JWTs are concrete enough to motivate it); Phase 2 pairs Offensive Security with Detection Engineering note-by-note; Phase 3 turns concept into operator capability; Phase 4 is specialization chosen by job context, not as a prerequisite. Privacy, Anonymity & OPSEC is reframed as an always-on personal discipline, not a phase. See Start Here for the persona-driven triage page.

Phase 0 — Orientation (start here)

  1. Foundations — the mental models every other branch assumes you already hold.

Phase 1 — Substrate (how things actually work)

Entry page: Phase 1 — Substrate — curated 12-note first-pass + 13-note extended path through Networking + Web Security + Cryptography. 1. Networking — the substrate of everything else. 2. Web Security — the daily surface most IT people touch. 3. Cryptography — the correctness layer; meaningful after TLS and sessions are concrete.

Phase 2 — Offense / defense paired

Entry page: Phase 2 — Offense / Defense (Paired) — 6 first-pass pairs + 3 extended pairs, each with the 4-step paired-reading ritual. 4. Offensive Security / Recon — how attackers discover and validate. 5. Detection Engineering — read note-by-note paired with #4.

Phase 3 — Operator surface

Entry page: Phase 3 — Operator Surface — the 4-branch workflow loop (surface mapping → OSINT → privesc → playbooks) with a curated 12-note first-pass path. 6. Attack Surface Mapping — what is actually exposed. 7. OSINT — public-source evidence handling. 8. Linux Privilege Escalation — local boundary failures after a foothold. 9. Security Playbooks — concepts as repeatable procedures.

Phase 4 — Specialty tracks (pick what your job demands)

Entry page: Phase 4 — Specialty Tracks — persona-shaped: 6 tracks (API / Cloud / DevSecOps / Wireless / Identity & AD / Binary Exploitation), each with its own entry conditions and curated path. Pick one — generalist parallel reading is the wrong move here. 10. API Security 11. Cloud Security 12. DevSecOps 13. Wireless Security 14. Identity and Active Directory 15. Binary Exploitation

Always-on — Personal discipline (parallel, lifelong)

Branch roles

Foundations (Phase 0)

Explains: - what cybersecurity actually is (and why it is not a tool list) - the CIA triad as a decision tool, not a definition - the 4-question / STRIDE threat-modeling reflex - the attacker-defender duality as the meta-frame every other branch assumes

Phase 0 is the only branch every learner reads regardless of role.

Networking

Explains: - transport - reachability - HTTP behavior - proxies - internal vs external paths

This is the substrate for web, API, SSRF, request smuggling, and attack surface reasoning.

Web Security

Explains: - classic web vulnerability classes - browser behavior - sessions - access control - server-side exploit patterns

Cryptography

Explains: - hashes, encryption, MACs, signatures, key exchange, and CSPRNGs - TLS/PKI, JWT signing, password hashing, and KDF correctness - how nonce reuse, weak modes, algorithm confusion, and roll-your-own designs fail

This is the correctness layer under TLS, sessions, JWTs, MFA/passkeys, secrets management, and privacy tooling. Sits after Networking in the new study order because crypto is most meaningful once TLS and sessions are concrete.

Wireless Security

Explains: - Wi-Fi as radio, frame, association, and authentication behavior - monitor-mode observation and packet capture - WEP, WPA/WPA2 handshakes, and passphrase risk - deauthentication, rogue access points, and local-network MITM

Specialty track in the new ordering — read when your job demands Wi-Fi-specific work.

API Security

Explains: - object-, function-, and property-level authorization - token trust - inventory drift - machine-readable abuse patterns

Cloud Security

Explains: - cloud shared responsibility, identity, and safe lab boundaries - IAM, metadata, storage, network, DNS/TLS, secrets, and logging controls - how cloud misconfiguration becomes attack surface

Attack Surface Mapping

Explains: - what is actually exposed - what is reachable - what is discoverable - what has drifted from intended design

Offensive Security / Recon

Explains: - how attackers discover - how findings are validated - how recon turns into testing

Linux Privilege Escalation

Explains: - how local Linux privilege boundaries fail after an authorized foothold - how enumeration turns host clues into ranked escalation hypotheses - how sudo, SUID/SGID, capabilities, scheduled jobs, PATH, kernel, and LinPEAS findings should be verified safely

Privacy, Anonymity & OPSEC

Explains: - how privacy tools change observer visibility and trust - why VPNs are privacy-routing tools, not anonymity guarantees - how metadata, accounts, browser state, files, and behavior leak identity - how Tor, compartmentalized systems, encrypted communication, and secure deletion fit into a threat model

OSINT

Explains: - how public-source information is collected and evaluated - how public clues become evidence instead of guesses - how people, company, media, breach, and search data should be handled ethically

DevSecOps

Explains: - secure development workflow - software supply chain - CI/CD hardening - release trust - secrets, containers, and artifacts

Detection Engineering

Explains: - telemetry sources and visibility limits - network observability, IDS/IPS pipelines, and behavioral correlation - Zeek, Suricata, NetFlow/IPFIX, EDR, cloud, and endpoint-network joins - why modern defense is behavioral and correlational rather than signature-only

Security Playbooks

Explains: - how to operationalize concepts - how to test specific classes of weakness - how to move from theory to repeatable procedure

Reference registries

These are the source-of-truth notes for references in each branch.


Working rules for the vault

Canonical notes

Each branch should use: - one canonical index.md - atomic notes with clear scope - strong related-note links - references aligned to the branch registry

Playbooks

Playbooks should: - operationalize concepts - connect to the relevant canonical notes - stay procedural, not conceptual

Cross-branch links should: - be meaningful - explain mechanisms, trust boundaries, exploit flow, or control design - stay selective rather than exhaustive

Cleanup rule

When overlapping notes exist: - preserve the canonical note - archive weaker or older duplicates - merge unique insights instead of losing them


Current focus

The current mature branches, listed in the new study order:

This root index should remain a navigation and system note, not a giant summary note.


Suggested future additions

Potential future branches: - mobile-security - reverse-engineering - social-engineering - ai-security / agent-security

These should only be added once their branch structure and reference registry are mature enough.