⌘K
ENES
GitHub
concept~10 min de lecturaActualizado May 11, 2026#cybersecurity#phase-4#specialty#personas#learning-path

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

Fase 4 es la única fase que no se lee linealmente. Por diseño, se elige por contexto laboral: elegís la especialidad que tu rol realmente requiere, la aprendés con profundidad suficiente para ser efectivo y volvés a las demás solo cuando tu trabajo se expande hacia ellas.

Los generalistas que intentan leer todas las ramas de Fase 4 en paralelo producen conocimiento superficial de todas y profundidad en ninguna. El camino especialista es el correcto acá.

Seis tracks, cada uno con su persona, camino curado y condiciones de entrada:

API Security · Cloud Security · DevSecOps · Wireless Security · Identity & Active Directory · Binary Exploitation

Cada track asume que completaste primera pasada de Fases 0-2; algunos también asumen Fase 3. Las condiciones de entrada del track se declaran explícitamente. El track de Binary Exploitation tiene los prerequisitos externos al atlas más fuertes (alfabetización C/C++, fluidez con debugger, baseline x86-64); ver Track F.

Track A — API Security

Elegí esto si: construís, testeás u operás APIs (REST, GraphQL, gRPC). La mayoría de ingeniería web/mobile/SaaS moderna toca esto.

Condiciones de entrada:

Camino de primera pasada (8 de 14 notas):

  1. API Security Top 10 — el canon OWASP API; el punto de entrada correcto porque enmarca cada nota posterior.
  2. API Inventory Management — no podés securizar APIs que no sabés que existen. Inventory es la primera capacidad.
  3. Broken Object Level Authorization (BOLA) — la clase de vulnerabilidad API #1 por frecuencia real. El sibling API-shaped de IDOR.
  4. Broken Function Level Authorization — fallas de límites admin/rol en routing API.
  5. Broken Object Property Level Authorization — autorización fine-grained a nivel campo; cierra los gaps que las dos anteriores dejan abiertos.
  6. Broken Authentication — fallas de emisión, refresh, validación y rotación de tokens.
  7. JWT Attacks — las fallas más comunes de confianza en token, emparejada con JWT Cryptographic Correctness de Fase 1.
  8. Excessive Data Exposure — APIs que devuelven más de lo que deberían; la falla de data minimization.

Extendido (6 más): API auth flaws, API rate limiting, Authorization, Token lifecycle, Mass assignment, Polymorphic deserialization.

Terminaste primera pasada de API cuando: dado cualquier API endpoint, podés recorrerlo con las 8 notas de arriba como checklist y articular cuáles de los 8 controles implementa correctamente, cuáles implementa débilmente y cuáles saltea.

Track B — Cloud Security

Elegí esto si: tus sistemas corren en cloud (AWS, GCP, Azure, multi-cloud) y los límites de seguridad que te importan viven en control planes cloud, no en equipos de red on-prem.

Condiciones de entrada:

Camino de primera pasada (6 de 10 notas):

  1. Cloud Security Basics — modelo de responsabilidad compartida y qué garantiza realmente el cloud provider vs qué es tuyo.
  2. Cloud IAM Boundaries — IAM es el control primario de cloud security. Todo lo demás está downstream.
  3. Cloud Metadata Security — el metadata endpoint es la superficie cloud más atacada; SSRF + cloud metadata = compromiso.
  4. Cloud Network Boundaries — security groups, VPC peering, transit gateways y cómo la confianza de networking se traduce a cloud.
  5. Cloud Secrets Management — credenciales short-lived, KMS, rotación de secrets, por qué hard-codear keys es la falla cloud canónica.
  6. Public Cloud Storage Exposure — mala configuración estilo bucket S3, por frecuencia el hallazgo cloud público más encontrado.

Extendido (4 más): Cloud logging and detection, Cloud DNS and Certbot, SSH access to cloud hosts, Cloud lab infrastructure.

Terminaste primera pasada de Cloud cuando: para cualquier workload cloud, podés recorrer su IAM role / exposición de red / reachability de metadata / manejo de secrets / exposición de storage y evaluar cada uno en menos de 10 minutos contra las 6 notas de arriba.

Track C — DevSecOps

Elegí esto si: sos dueño (o contribuís a) un pipeline CI/CD, proceso de release, build de container o control de supply-chain. Este track es cada vez menos opcional para roles backend / platform / SRE.

Condiciones de entrada:

  • Primera pasada de Fase 1 completa (especialmente Digital signatures para razonamiento de integridad de artifacts).
  • Primera pasada de Fase 2 ayuda, pero no es estrictamente requerida.

Camino de primera pasada (7 de 12 notas):

  1. Secure by Design — la filosofía que impulsa todas las otras notas; sin esto el resto se vuelve checklist.
  2. CI/CD Hardening — el build pipeline es parte de la superficie de ataque. Esta nota nombra qué endurecer primero.
  3. Secrets Management — la falla canónica de CI/CD. Hard-coded keys, logs expuestos, tokens filtrados.
  4. Supply Chain Security — el threat model que motiva SBOM, signing y provenance.
  5. SBOM and Provenance — cómo saber qué estás shippeando realmente. SLSA, Sigstore, in-toto.
  6. Dependency Risk — la superficie de dependencias open-source como amenaza de primera clase.
  7. Container Security — amenazas de imagen, runtime y capa de orquestación.

Extendido (5 más): Artifact integrity, Image scanning, Branch protection and release controls, NIST SSDF, ASVS as dev process input.

Terminaste primera pasada de DevSecOps cuando: podés threat-model tu propio pipeline CI/CD end-to-end y nombrar los controles que protegen cada etapa (commit -> build -> test -> publish -> deploy).

Track E — Identity and Active Directory

Elegí esto si: hacés red-team / pentest en entornos AD, administrás AD, respondés incidentes basados en identidad o trabajás en ingeniería de identity-platform (AD, Entra ID, hybrid). Relevancia de alta frecuencia para roles de seguridad enterprise.

Condiciones de entrada:

  • Primera pasada de Fase 1 completa (especialmente password hashing y symmetric encryption modes; ataques a credenciales AD son problemas de economía KDF/cifrado).
  • Primera pasada de Fase 2 completa: los ataques AD no tienen detección signature-based útil; el encuadre behavioral es obligatorio.

Camino de primera pasada (4 notas, leer en orden):

  1. BloodHound and Attack Path Analysis — la capa de visibilidad. Te dice qué ataques AD valen la pena y qué ACLs defensivas arreglar primero.
  2. AS-REP Roasting — el ataque pre-foothold que no requiere credenciales, solo usernames.
  3. Kerberoasting — el ataque post-foothold contra cuentas con SPNs.
  4. DCSync and ntds.dit Extraction — el endgame: recuperar cada hash incluido krbtgt, habilitando Golden Tickets y compromiso permanente del domain.

Extendido (notas futuras sembradas): Golden Ticket forgery, Silver Ticket persistence, Pass-the-Hash, DCShadow, krbtgt rotation, Exchange permission legacy, UAC flags, shadow credentials / PKINIT, Tier 0 administration / PAW.

Terminaste primera pasada de Identity & AD cuando: dado cualquier entorno AD, podés recolectar con BloodHound, identificar el camino más corto desde cualquier usuario no privilegiado a Domain Admin, nombrar las dos ACE edges más baratas que defensores deberían remover y ejecutar una cadena ofensiva end-to-end contra un lab autorizado.

Track D — Wireless Security

Elegí esto si: trabajás con redes Wi-Fi en cualquier profundidad: assessment de Wi-Fi corporativo, seguridad de sucursales, wireless penetration testing o construcción de productos wireless. Elegí esto último si tu rol es web/cloud/API; wireless es genuinamente un specialty track.

Condiciones de entrada:

  • Primera pasada de Fase 1 completa (especialmente TCP/IP basics y Ports and services; Wi-Fi es L1/L2 debajo del mismo TCP/IP).
  • Hardware: se requiere un adaptador Wi-Fi que soporte monitor mode para que los labs de este track sean útiles.

Camino de primera pasada (5 de 10 notas):

  1. Wireless Security — el modelo mental de rama: Wi-Fi como radio + frames + asociación + autenticación.
  2. Wi-Fi Monitor Mode — la capacidad fundacional; sin capture en monitor-mode, el resto es teoría.
  3. WPA/WPA2 Handshakes — el target canónico de captura y cracking.
  4. Wi-Fi Deauthentication — el movimiento que convierte "esperar a que conecte un cliente" en "forzar uno a reconectar ahora". Fundacional para handshake capture y evil-twin attacks.
  5. Evil Twin Access Points — el ataque rogue-AP que convierte superficie wireless en compromiso de credenciales / sesión.

Extendido (5 más): Wi-Fi wordlist attacks, WEP security, MITM on local networks, ARP poisoning, Bettercap workflows.

Terminaste primera pasada de Wireless cuando: podés capturar un handshake WPA2 de una red de prueba autorizada, crackearlo contra una wordlist controlada y articular por qué tu Wi-Fi corporativo es o no vulnerable al mismo workflow.

Track F — Binary Exploitation

Elegí esto si: hacés vulnerability research, exploit development, security engineering para software low-level (kernels de OS, hypervisors, navegadores, runtimes de lenguajes), competencias CTF categoría pwn, autoría de tooling de seguridad o mantenés código memory-unsafe en cualquier contexto productivo. Los prerequisitos externos al atlas más fuertes de cualquier track: esta es la especialidad técnica más profunda del atlas por distancia de escalera desde código fuente.

Condiciones de entrada:

  • Primera pasada de Fase 1 completa.
  • Alfabetización de programación C/C++ — la rama asume que podés leer C, tenés un modelo mental funcional de stack frames y heap allocation, y estás cómodo con un debugger (gdb / lldb / WinDbg). Si no, trabajá Practical Binary Analysis u OpenSecurityTraining x86 / OS-internals primero.
  • Baseline Linux + x86-64. La mayoría de labs targetean Linux sobre x86-64. aarch64, macOS y especificidades Windows se llaman por nota cuando aparecen.
  • Primera pasada de Fase 2 útil pero no estrictamente requerida (la detección de exploits vive mayormente dentro de las notas de mitigación de la propia rama más el cross-link EDR / process correlation).

Camino de primera pasada (2 notas, leer en orden):

  1. Memory Corruption — el concepto raíz, la taxonomía de 6 clases (stack overflow / heap overflow / use-after-free / double-free / out-of-bounds read / integer overflow) y la cadena desde bug a exploit primitive a code execution.
  2. Stack Buffer Overflow — el ejemplo trabajado canónico de clase 1. El deep-dive que introduce layout de stack, control de return-address, cadena de mitigaciones (canary -> ASLR -> DEP -> CET -> MTE -> PAC), razonamiento estilo ROP y workflow de exploit-development estilo pwntools.

Extendido (notas futuras sembradas): Heap exploitation, use-after-free, double-free, info-leak primitives, ROP / ret2libc, ASLR / PIE leak chains, format-string bugs, exploit mitigations (el panorama completo), stack canaries / shadow stacks / PAC, ARM MTE, CFI, formato ELF, loop de reverse-engineering, fuzzing con libFuzzer / AFL++, sanitizers (ASAN / MSAN / UBSan), symbolic execution con angr.

Terminaste primera pasada de Binary Exploitation cuando: dado un programa C vulnerable, podés identificar la clase de bug, localizar la saved return address (o primitive equivalente de control-flow), construir un exploit funcional contra un build sin mitigaciones, articular qué mitigaciones derrotan ese exploit simple y nombrar al menos dos primitives que encadenarías para derrotarlas. El exploit script estilo pwntools para un challenge CTF básico de stack-overflow debería ser una tarea de 20 líneas, no una tarde.

Cómo Fase 4 conecta con fases anteriores

Track de Fase 4 Dependencias más fuertes de Fase 0-3
API Security Web Security (Fase 1), JWT correctness (Fase 1 Crypto), Broken Access Control + playbook IDOR (Fase 3)
Cloud Security Networking + Crypto (Fase 1), SSRF + metadata endpoints (Fase 1 Web), playbook Investigate-SSRF (Fase 3)
DevSecOps Crypto digital signatures + AEAD (Fase 1), threat-modeling (Fase 0), cada par de Fase 2 para pensar "¿mi pipeline es detectable?"
Wireless Security Networking L1/L2/L3 (Fase 1), pairing de evasión y detección (Fase 2)
Identity & Active Directory Password hashing + symmetric encryption modes (Fase 1 Crypto), behavioral-vs-signature detection (Fase 2), dualidad atacante-defensor (Fase 0)
Binary Exploitation Alfabetización C/C++ + fluidez con debugger + baseline x86-64 (prerequisitos externos al atlas), threat-modeling en la capa systems-software (Fase 0), telemetría de detección del lado EDR (Fase 2)

Elegí el track cuyas dependencias ya cubriste; ese es el camino más eficiente.

Elegir más de un track

La disciplina paralela always-on de Privacy, Anonymity & OPSEC es tu quinto track en espíritu: corre junto a todos los demás y nunca deja de ser relevante.

Si tu rol demanda dos especialidades (por ejemplo, API + Cloud es común en ingeniería backend moderna), hacelas secuencialmente, no en paralelo. Terminá primera pasada de una, luego empezá primera pasada de la otra. Leer en paralelo produce retención más superficial en ambas.

Qué hay después de Fase 4

No hay Fase 5 en este atlas. Después de primera pasada de especialidad de Fase 4, estás operando como especialista con amplitud completa en Fases 0-3 y profundidad en una (o dos, secuencialmente) áreas de especialidad. El próximo movimiento de aprendizaje está fuera de este atlas:

  • Engagements reales bajo autorización: bug bounty programs, ejercicios internos red/purple-team, drills IR.
  • Defender un sistema real que use tu especialidad: construir u operar uno es el contexto de aprendizaje de mayor leverage.
  • Las ramas futuras sugeridas en Índice de ciberseguridad (mobile, reverse-engineering, social-engineering, AI/agent-security): abrirlas cuando se vuelvan relevantes laboralmente.

La estructura del atlas termina acá. Todo lo demás es profundidad.

Notas relacionadas

CiberseguridadFase 1 — Sustrato (cómo funcionan realmente las cosas)Terminaste Fase 0 — Fundamentos y tenés los cuatro modelos mentales: ciberseguridad no es una lista de herramientas, CIA como herramienta de decisión, threat modeling como reflejo, dualidad atacante-defensor como metamarco. Fase 1 es donde esas abstracciones aterrizan en sistemas reales. CiberseguridadFase 2 — Offense / Defense (en pares)Tenés un modelo funcional del sustrato desde Fase 1. Fase 2 es donde la mayoría de learners de ciberseguridad se estanca, porque eligen un lado — offense o defense — y lo leen solo. Esta fase existe para prevenir eso. CiberseguridadFase 3 — Superficie de operador (concepto -> capacidad)Tenés un modelo de sustrato desde Fase 1 y podés leer offense y defense como pares desde Fase 2. Fase 3 es donde ese conocimiento se vuelve capacidad de operador: workflows que podés ejecutar de verdad contra targets autorizados, no solo razonar. CiberseguridadEmpezá acá — guía del atlas de ciberseguridadLlegaste a un atlas de ciberseguridad organizado por fases, ramas y playbooks. Leerlo linealmente es incorrecto. Esta página te enruta al camino correcto según quién sos ahora mismo. Privacidad, Anonimato y OPSECAccount CorrelationLa correlación de cuentas es el proceso de vincular actividades o personas separadas a través de cuentas compartidas, datos de recuperación, identificadores, dispositivos o patrones de uso repetidos. Seguridad Ofensiva / ReconActive ReconEl active recon es la recopilación de información que interactúa directamente con la infraestructura, servicios o aplicaciones del objetivo para validar o extender lo descubierto en el passive recon.