⌘K
ENES
GitHub
index

Índice de ciberseguridad

Propósito

Este es el índice raíz del atlas de ciberseguridad.

El objetivo de este sistema es pasar de:

  • aprender conceptos de seguridad aislados

a:

  • construir un grafo conectado de conocimiento de seguridad
  • entender exposición, explotación y defensa como un solo sistema
  • vincular conceptos con workflows prácticos, playbooks y decisiones de ingeniería

Este atlas está estructurado para soportar:

  • aprendizaje de seguridad
  • testing práctico
  • razonamiento de arquitectura
  • recuperación a largo plazo y workflows asistidos por LLM

Cómo está organizado este atlas

El atlas está dividido en ramas canónicas.

Orientación (empezá acá)

El framework que todo lo demás asume; leelo primero.

Sustrato (cómo funcionan realmente las cosas)

Leé en orden. Networking es el sustrato de todo lo demás, Web Security es la superficie diaria, Cryptography es la capa de correctness.

Offense / Defense (en pares)

Leé nota por nota como pares. Estudiar una sola mitad te estanca.

Superficie de operador

Qué está realmente expuesto, de dónde viene la evidencia y cómo los conceptos se vuelven procedimientos repetibles.

Specialty tracks (elección por contexto laboral)

Elegí lo que tu trabajo demande. No son prerequisitos entre sí.

Always-on (disciplina personal paralela)

No es una fase. Leela junto con todo lo demás.

Orden de estudio recomendado

Roadmap v2 — aterrizado el 2026-05-10. Reorganizado para la persona de IT entrando a cyber. Fase 0 nombra los modelos mentales; Fase 1 enseña el sustrato (Networking primero porque es el sustrato de todo lo demás, luego Web Security como superficie diaria, luego Cryptography cuando TLS/JWTs ya son lo suficientemente concretos para motivarla); Fase 2 empareja Offensive Security con Detection Engineering nota por nota; Fase 3 convierte concepto en capacidad de operador; Fase 4 es especialización elegida por contexto laboral, no como prerequisito. Privacy, Anonymity & OPSEC se reencuadra como disciplina personal always-on, no como fase. Ver Empezá acá para la página de triage por persona.

Fase 0 — Orientación (empezá acá)

  1. Fundamentos — los modelos mentales que todas las otras ramas asumen que ya tenés.

Fase 1 — Sustrato (cómo funcionan realmente las cosas)

Página de entrada: Fase 1 — Sustrato — primera pasada curada + camino extendido por Networking + Web Security + Cryptography.

  1. Networking — el sustrato de todo lo demás.
  2. Web Security — la superficie diaria que la mayoría de gente de IT toca.
  3. Cryptography — la capa de correctness; cobra sentido después de que TLS y sesiones son concretos.

Fase 2 — Offense / defense en pares

Página de entrada: Fase 2 — Offense / Defense (en pares) — pares de primera pasada + pares extendidos, cada uno con el ritual de lectura en pares.

  1. Offensive Security / Recon — cómo los atacantes descubren y validan.
  2. Detection Engineering — leer nota por nota emparejada con #4.

Fase 3 — Superficie de operador

Página de entrada: Fase 3 — Superficie de operador — loop de workflow entre surface mapping, OSINT, privesc y playbooks, con un camino curado de primera pasada.

  1. Attack Surface Mapping — qué está realmente expuesto.
  2. OSINT — manejo de evidencia de fuentes públicas.
  3. Linux Privilege Escalation — fallas de límites locales después de un foothold.
  4. Security Playbooks — conceptos como procedimientos repetibles.

Fase 4 — Specialty tracks (elegí lo que tu trabajo demande)

Página de entrada: Fase 4 — Specialty Tracks — shaped por persona, con tracks por contexto (API / Cloud / DevSecOps / Wireless / Identity & AD / Binary Exploitation), cada uno con sus condiciones de entrada y camino curado. Elegí uno; la lectura generalista en paralelo es el movimiento equivocado acá.

  1. API Security
  2. Cloud Security
  3. DevSecOps
  4. Wireless Security
  5. Identity and Active Directory
  6. Binary Exploitation

Always-on — Disciplina personal (paralela, de por vida)

Roles de las ramas

Foundations (Fase 0)

Explica:

  • qué es realmente ciberseguridad (y por qué no es una lista de herramientas)
  • la tríada CIA como herramienta de decisión, no como definición
  • el reflejo de threat modeling de 4 preguntas / STRIDE
  • la dualidad atacante-defensor como el metamarco que todas las otras ramas asumen

Fase 0 es la única rama que todo learner lee sin importar su rol.

Networking

Explica:

  • transporte
  • reachability
  • comportamiento HTTP
  • proxies
  • caminos internos vs externos

Es el sustrato para web, API, SSRF, request smuggling y razonamiento de superficie de ataque.

Web Security

Explica:

  • clases clásicas de vulnerabilidades web
  • comportamiento del navegador
  • sesiones
  • access control
  • patrones de exploit server-side

Cryptography

Explica:

  • hashes, cifrado, MACs, firmas, key exchange y CSPRNGs
  • TLS/PKI, firma JWT, password hashing y correctness de KDF
  • cómo fallan nonce reuse, modos débiles, algorithm confusion y diseños roll-your-own

Es la capa de correctness debajo de TLS, sesiones, JWTs, MFA/passkeys, secrets management y tooling de privacidad. Queda después de Networking en el nuevo orden de estudio porque crypto cobra más sentido cuando TLS y sesiones ya son concretos.

Wireless Security

Explica:

  • Wi-Fi como comportamiento de radio, frames, asociación y autenticación
  • observación en monitor-mode y packet capture
  • WEP, handshakes WPA/WPA2 y riesgo de passphrase
  • deauthentication, rogue access points y MITM en red local

Specialty track en el nuevo orden: leela cuando tu trabajo demande Wi-Fi específico.

API Security

Explica:

  • autorización a nivel objeto, función y propiedad
  • confianza en tokens
  • inventory drift
  • patrones de abuso machine-readable

Cloud Security

Explica:

  • responsabilidad compartida cloud, identidad y límites seguros de lab
  • IAM, metadata, storage, red, DNS/TLS, secrets y controles de logging
  • cómo la mala configuración cloud se vuelve superficie de ataque

Attack Surface Mapping

Explica:

  • qué está realmente expuesto
  • qué es reachable
  • qué es discoverable
  • qué se desvió del diseño previsto

Offensive Security / Recon

Explica:

  • cómo descubren los atacantes
  • cómo se validan hallazgos
  • cómo recon se convierte en testing

Linux Privilege Escalation

Explica:

  • cómo fallan los límites locales de privilegio en Linux después de un foothold autorizado
  • cómo la enumeración convierte pistas del host en hipótesis rankeadas de escalada
  • cómo verificar de forma segura hallazgos de sudo, SUID/SGID, capabilities, scheduled jobs, PATH, kernel y LinPEAS

Privacy, Anonymity & OPSEC

Explica:

  • cómo las herramientas de privacidad cambian visibilidad de observadores y confianza
  • por qué las VPNs son herramientas de ruteo de privacidad, no garantías de anonimato
  • cómo metadata, cuentas, estado del navegador, archivos y comportamiento filtran identidad
  • cómo Tor, sistemas compartimentalizados, comunicación cifrada y borrado seguro encajan en un threat model

OSINT

Explica:

  • cómo se recolecta y evalúa información de fuentes públicas
  • cómo pistas públicas se vuelven evidencia en vez de guesses
  • cómo manejar ética y correctamente datos de personas, compañías, media, breaches y search

DevSecOps

Explica:

  • workflow de desarrollo seguro
  • software supply chain
  • hardening de CI/CD
  • confianza en releases
  • secrets, containers y artifacts

Detection Engineering

Explica:

  • fuentes de telemetría y límites de visibilidad
  • observabilidad de red, pipelines IDS/IPS y correlación behavioral
  • Zeek, Suricata, NetFlow/IPFIX, EDR, cloud y joins endpoint-network
  • por qué la defensa moderna es behavioral y correlacional más que signature-only

Security Playbooks

Explica:

  • cómo operacionalizar conceptos
  • cómo testear clases específicas de debilidad
  • cómo pasar de teoría a procedimiento repetible

Registros de referencias

Estas son las notas source-of-truth para referencias en cada rama.

Reglas de trabajo del atlas

Notas canónicas

Cada rama debería usar:

  • un index.md canónico
  • notas atómicas con alcance claro
  • links fuertes a notas relacionadas
  • referencias alineadas al registry de la rama

Playbooks

Los playbooks deberían:

  • operacionalizar conceptos
  • conectarse con las notas canónicas relevantes
  • mantenerse procedurales, no conceptuales

Los links entre ramas deberían:

  • ser significativos
  • explicar mecanismos, trust boundaries, exploit flow o diseño de controles
  • mantenerse selectivos en vez de exhaustivos

Regla de cleanup

Cuando existan notas superpuestas:

  • preservá la nota canónica
  • archivá duplicados más débiles o viejos
  • mergeá insights únicos en vez de perderlos

Foco actual

Las ramas maduras actuales, listadas en el nuevo orden de estudio:

Este índice raíz debería seguir siendo una nota de navegación y sistema, no una nota resumen gigante.

Futuras adiciones sugeridas

Ramas futuras potenciales:

  • mobile-security
  • reverse-engineering
  • social-engineering
  • ai-security / agent-security

Solo deberían agregarse cuando su estructura de rama y registro de referencias sean lo suficientemente maduros.