Capas OSI: el mapa que te falta para defender un sistema de IA

La mayoría de los incidentes de seguridad que parecen complicados no lo son porque el atacante fuera brillante, sino porque el defensor miró en la capa equivocada. Un certificado inesperado que el equipo de aplicación atribuye a un fallo de configuración y que en realidad nace de un envenenamiento ARP en la VLAN de usuarios. Una API que cae con errores 503 y que todo el mundo trata como bug de aplicación cuando es un SYN flood que agota las tablas de estado del balanceador. Un agente de IA que envía credenciales por un canal en claro que nadie auditó porque «ya hay TLS en el perímetro». El modelo OSI, ese que memorizaste para un examen y nunca volviste a usar, es precisamente la herramienta que ordena este caos: te dice dónde ocurre algo, qué afecta y qué control lo corta.

Básicos Protección Capas OSI es un curso interactivo gratuito, publicado en GitHub Pages, que convierte el modelo OSI en un mapa defensivo operativo. No se queda en la enumeración académica de las siete capas: cada capa se estudia como una unidad de análisis con tres preguntas (dónde ocurre, qué afecta y qué control lo corta), con técnicas reales clasificadas en MITRE ATT&CK, evidencias observables en un SIEM o un EDR, y controles concretos como Dynamic ARP Inspection, uRPF, SYN cookies o TLS 1.3. Todo funciona en el navegador, con HTML, CSS y JavaScript puro, sin registro, sin instalar nada y sin que ningún dato salga de tu equipo.

En este análisis recorro el curso sección por sección, explico cómo funciona su laboratorio de triage (que clasifica alertas por capa de forma local, con detección por palabras clave), y defiendo la tesis que atraviesa todo el proyecto: la defensa en profundidad es la disciplina de poner un control en cada capa, sabiendo que ninguna capa basta por sí sola, no una lista de productos.

Por qué el modelo OSI sigue siendo el mejor mapa defensivo

El curso parte de un modelo mental que la propia página resume en una frase: una señal en una capa suele tener causas y efectos en otras. Esa frase es la diferencia entre un analista que reacciona a alertas y uno que investiga. El modelo OSI, definido originalmente en la recomendación ITU-T X.200 (equivalente a ISO/IEC 7498-1), ofrece siete niveles de abstracción que encajan de forma sorprendentemente precisa sobre el trabajo defensivo diario:

• Capa 1, física: medio, señal, cableado, radiofrecuencia, energía y acceso físico a infraestructura. Señales típicas: desconexiones, ruido RF, enlaces intermitentes, equipos no inventariados.
• Capa 2, enlace de datos: tramas, MAC, switches, VLAN, ARP y controles locales que deciden quién habla en el segmento. Aquí viven el ARP caché poisoning, el MAC spoofing, el DHCP spoofing y los errores de VLAN.
• Capa 3, red: IP, routing, ICMP, TTL, fragmentación, túneles y decisiones de camino entre redes. IP spoofing, route injection y DNS inconsistente son sus señales.
• Capa 4, transporte: puertos, TCP, UDP, establecimiento de conexión y presión sobre servicios. SYN flood, UDP flood, RST anómalo y escaneo de puertos.
• Capa 5, sesión: estado conversacional, tokens, cookies, identidad de sesión y continuidad. Sesiones reutilizadas, tokens robados y replay.
• Capa 6, presentación: cifrado, certificados, formatos, codificación y serialización. Certificado inesperado, downgrade TLS, cifrados débiles.
• Capa 7, aplicación: protocolos y lógica de usuario: DNS, HTTP, correo, APIs, autenticación, inyección, phishing y abuso de lógica.

Lo que el curso añade a esta enumeración es el cruce sistemático: si un usuario reporta certificados inesperados (señal de capa 6), la causa raíz puede ser un adversario colocado en capa 2 mediante ARP o DHCP spoofing, clasificado como T1557 en MITRE ATT&CK. Si la web cae (síntoma de capa 7), el mecanismo puede ser un flood de capa 4 (T1498). El síntoma y la causa viven en capas distintas, y tratar el síntoma sin encontrar la capa raíz garantiza que el incidente se repita.

Anatomía del curso, sección por sección

El mapa interactivo de ataques por capa

La primera gran pieza es un grafo interactivo construido con Cytoscape.js que conecta tres tipos de nodos: las siete capas OSI, tres técnicas de ataque (adversary-in-the-middle, denegación de servicio y sniffing) y dos nodos defensivos (controles compensatorios y telemetría y correlación). Al seleccionar un nodo, un panel lateral muestra su ficha completa: descripción, señales típicas, impacto principal, controles recomendados y enlaces a fuentes primarias. Las aristas del grafo cuentan la historia: AiTM «abusa» de capa 2, «degrada» la 6 y «roba» en la 7; el sniffing «observa» la capa física y «captura» el enlace; el DoS «satura» la red, «agota» el transporte y «presiona» la aplicación; y la telemetría «detecta» ambas técnicas y «prioriza» los controles.

Este grafo es la traducción visual de un principio serio de arquitectura defensiva: los ataques atraviesan capas y las defensas deben cubrir el recorrido completo. La ficha del nodo de controles compensatorios lo dice sin rodeos: un control en una capa no elimina todos los riesgos de las capas superiores, y la mejor defensa combina prevención, detección, contención y recuperación. Si el CDN de Cytoscape no carga, la página muestra un mapa alternativo con botones, de modo que el contenido no depende de la conexión.

La cadena de señales: una investigación de nueve pasos

El simulador defensivo recorre una investigación típica dividida en nueve pasos: alerta inicial, capa física, capa de enlace, capa de red, capa de transporte, sesión y presentación juntas, capa de aplicación, correlación y, por último, contención y mejora. Cada paso incluye una traza defensiva (evidencia, impacto y control) y una lista de comprobaciones prácticas. El paso de alerta inicial insiste en algo que muchos analistas aprenden por las malas: no asumas capa raíz todavía; anota hora, activo, usuario, segmento, origen de la alerta y evidencia disponible. El paso de correlación añade otra regla de oro: sin sincronización horaria, la investigación pierde secuencia, y una sola alerta rara vez basta para cerrar la investigación.

El paso final (contención y mejora) convierte el caso en mejoras verificables: registra el timeline, la capa raíz, los controles aplicados y las lagunas, y documenta qué control habría detectado o bloqueado antes el incidente. Es el ciclo completo de respuesta a incidentes comprimido en una interfaz navegable.

Anatomía por capa: dónde mirar primero

La tercera sección es un selector de las siete capas donde cada una se despliega con tres bloques: ataques, evidencia y defensa. Para capa 2, por ejemplo: ataques como ARP poisoning, DHCP spoofing, MAC flooding, VLAN hopping y rogue switch; evidencia como gateway con MAC cambiante, DHCP no autorizado, MAC duplicadas o troncales inesperadas; defensa con 802.1X, port security, DHCP snooping, Dynamic ARP Inspection y VLAN bien definidas. Para capa 6: ataques de TLS downgrade, certificado falso, encoding evasivo y parser confusión; evidencia de cipher débil o errores de validación; defensa con TLS 1.3, HSTS, validación de certificados y parsers seguros. Cada ficha está escrita en el vocabulario de quien ha mirado una consola de switch o un dashboard de SIEM, no en el de un libro de texto.

El laboratorio de triage: clasificar una alerta real

El laboratorio local es la pieza más original del curso. Presenta un formulario con cinco entradas: capa inicialmente sospechada (con opción de detección automática por síntomas), exposición del activo (red interna, perímetro o DMZ, expuesto a Internet, Wi-Fi corporativa o laboratorio controlado), criticidad del servicio, síntomas observados y controles existentes. Al pulsar «Analizar», un motor de reglas escrito en JavaScript puro procesa el texto localmente: detecta la capa probable mediante diccionarios de palabras clave por nivel (ARP, MAC, VLAN o DHCP apuntan a capa 2; SYN, UDP o flood a la 4; inyección, SSRF o auth a la 7) y aplica reglas de correspondencia entre síntomas y controles ausentes.

El informe resultante, la «lectura defensiva», incluye la capa probable con recuento de señales coincidentes, una tabla de capas detectadas y hallazgos concretos. Por ejemplo: si los síntomas mencionan ARP, DHCP, MAC o VLAN y los controles no incluyen Dynamic ARP Inspection, el laboratorio marca «Control L2 ausente» y recomienda priorizar la contención de VLAN. Si hay menciones de HTTP en claro, credenciales o tokens sin TLS, HSTS, MFA o rotación, marca «Material sensible expuesto» y aconseja tratar las credenciales como comprometidas y rotar secretos. Si hay SYN o flood sin CDN, mitigación DDoS, rate limit ni SYN cookies, señala que el volumen de capas 3 y 4 puede requerir scrubbing aguas arriba. El curso incluye dos casos precargados: un caso AiTM (certificados inesperados, cambios ARP en la puerta de enlace, HTTP claro con credenciales en una VLAN de usuarios y respuestas DNS inconsistentes) y un caso DoS (ráfagas SYN desde miles de orígenes, enlace saturado durante 18 minutos, errores 503 con bases de datos sanas y UDP hacia servicios no publicados).

Checklist de señales, quiz y guía de método

La sección de riesgos es una checklist de ocho señales de campo, cada una con puntuación y consejo: equipo o AP no inventariado (22 puntos), ARP o gateway MAC cambiante (28), DNS o ruta inesperada (24), SYN o UDP flood (26), credenciales por canal claro (30), certificados inesperados (25), payload de inyección o SSRF (24) y ausencia de logs o tiempo incoherente (16). La suma se traduce en niveles: 62 o más es riesgo alto con posible impacto multicapa; 30 o más es riesgo medio; cualquier puntuación positiva con nivel bajo exige confirmación. Es un ejercicio gamificado, pero las puntuaciones codifican un criterio real: las credenciales en claro pesan más que cualquier otra señal porque comprometen todas las capas superiores de golpe.

El quiz autocorregido tiene ocho preguntas con explicación inmediata, y no son preguntas de trivia: incluye el caso límite más formativo del curso (¿por qué una alerta TLS puede tener raíz en capa 2?) con su respuesta correcta: porque ARP o DHCP pueden posicionar a un intermediario antes del handshake; la señal se ve en capa 6 pero la raíz está en capa 2. La guía rápida de análisis cierra el recorrido con seis tarjetas de método: ubica la señal (separando evidencia de hipótesis), determina impacto (confidencialidad, integridad, disponibilidad), cruza capas, contén primero, endurece controles y documenta el aprendizaje. El glosario define seis términos de campo (adversary-in-the-middle, sniffing, spoofing, downgrade, segmentación e indicador) en el lenguaje preciso que exige una investigación seria.

Fuentes primarias, filtrables

La sección de referencias reúne quince fuentes primarias filtrables por tema (OSI, protocolos, seguridad, testing): la ITU-T X.200 como referencia del modelo; los RFC 826 (ARP), 791 (IPv4), 8200 (IPv6), 9293 (TCP), 768 (UDP), 9110 (HTTP), 9846 (TLS 1.3) y 4949 (glosario de seguridad); las técnicas MITRE ATT&CK T1557 (adversary-in-the-middle), T1040 (network sniffing) y T1498 (network denial of service); NIST SP 800-115 para pruebas de seguridad; la OWASP Web Security Testing Guide; y el registro IANA de números de protocolo. Todo el curso cita fuentes primarias, no resúmenes de terceros, lo que lo hace útil también como lanzadera hacia la documentación oficial.

La mecánica interactiva: cómo está construido

Técnicamente, el proyecto es una aplicación estática sin backend: un index.html, una hoja de estilos, un script.js de poco más de mil doscientas líneas y una imagen. El grafo usa Cytoscape 3.34.1 desde CDN con un fallback de botones si no carga. El laboratorio de triage no envía nada a ningún servidor: la detección de capas es una función de puntuación de palabras clave sobre el texto introducido, y las reglas de control son expresiones regulares que cruzan síntomas contra controles. El quiz calcula la puntuación en la sesión. Lo único que se persiste en el navegador, vía localStorage, es la preferencia de tema claro u oscuro. Para uso offline o en aula basta con abrir el index.html directamente; el README del repositorio documenta la estructura y las referencias. Esta decisión de arquitectura (todo local, sin cuentas ni telemetría) es coherente con el propio tema del curso: minimizar la superficie y no recoger más datos de los necesarios.

Por qué importa si trabajas con sistemas de IA

Un sistema de IA en producción es, desde el punto de vista de red, una pila OSI completa con superficie de ataque en cada nivel, y suele desplegarse más rápido de lo que se asegura. Considera el recorrido típico de una petición a un agente: el usuario se autentica en un frontend (capa 7), la sesión viaja en una cookie o un token (capa 5), el canal se protege con TLS y un certificado (capa 6), la conexión pasa por balanceadores y firewalls que mantienen estado (capas 3 y 4), todo converge en una VLAN del clúster donde residen la API de inferencia y el almacén de vectores (capa 2), y los pesos del modelo, los embeddings y los datos de entrenamiento viven en discos físicos de máquinas concretas (capa 1). Cada uno de esos puntos tiene un fallo típico documentado en el curso.

Los riesgos específicos de IA encajan en el mapa capa a capa. El envenenamiento del cacheado de DNS o un AiTM en capa 2 puede redirigir el tráfico de tu proveedor de modelos a un servidor adversario que registre cada prompt, aunque tu código use HTTPS. Un endpoint de inferencia sin rate limit es un objetivo de denegación de servicio de capa 4 cuyo síntoma (errores 503) se atribuirá al modelo. Un agente que recibe contexto de usuario sin validación sufre inyección de prompts en capa 7, la misma lógica de entrada no confiable que una inyección SQL. Las claves de API que el pipeline envía por canales internos en claro son capturables por sniffing en capa 2 si un adversario consigue posición en el segmento. Y el robo de tokens de sesión en capa 5 permite suplantar a un usuario legítimo ante el propio agente. El curso no menciona la IA explícitamente, pero su método (mapear señal, impacto y control por capa) es exactamente el ejercicio que cualquier equipo que despliega LLMs debería hacer antes del primer despliegue, no después del primer incidente.

La lección central de la defensa en profundidad aplica con especial crudeza a los sistemas de IA: la cadena es tan fuerte como la capa más débil. Puedes tener TLS 1.3 en el frontend, un WAF en el perímetro y MFA en la autenticación, y perder todos los prompts porque nadie activó Dynamic ARP Inspection en la VLAN donde vive el clúster. El nodo de telemetría del curso lo resume: correlacionar capas reduce falsos positivos y acelera la contención, y nunca se capturan más datos personales o secretos de los necesarios, un principio que en un sistema que procesa prompts de usuarios no es opcional.

Cómo usar el curso: un plan de una semana

El curso está pensado para completarse en una o dos horas de interacción continua, pero rinde más repartido en sesiones cortas. Un plan razonable de cinco días: primero, recorre el mapa interactivo y lee la ficha de cada capa y cada técnica, siguiendo las aristas para ver cómo un ataque atraviesa niveles. Segundo, avanza por la cadena de señales completa, los nueve pasos de la investigación simulada, deteniéndote en las comprobaciones de cada paso. Tercero, juega con el laboratorio de triage: carga el caso AiTM y el caso DoS, modifica los síntomas y observa cómo cambia la capa probable y qué hallazgos aparecen o desaparecen; después escribe los síntomas de un incidente real que hayas vivido y contrasta el informe con lo que hizo tu equipo. Cuarto, marca la checklist de señales contra tu entorno actual y anota tu puntuación de riesgo; si supera 30, tienes trabajo priorizado. Quinto, haz el quiz sin prisa, lee cada explicación (sobre todo la de la alerta TLS con raíz en capa 2) y repasa la guía de método como chuleta de bolsillo. Al terminar, guarda la sección de referencias como punto de partida para profundizar en los RFC y en MITRE ATT&CK.

Los controles por capa, en una tabla mental

Si tuviera que quedarme con una sola idea ejecutable del curso, sería su repertorio de controles organizado por capa, porque convierte la defensa en profundidad de eslogan en lista de compra. En capa 1, seguridad física, inventario, NAC y alertas de puerto: un equipo no inventariado en la sala de servidores es un incidente que aún no ha pasado nada. En capa 2, la combinación 802.1X, port security, DHCP snooping y Dynamic ARP Inspection, con VLAN bien definidas: es la única respuesta estructural al envenenamiento ARP, porque ARP no tiene autenticación propia. En capa 3, ACL, filtrado anti-spoofing, uRPF, RPKI y monitorización de rutas: comprueban que el paquete entra por donde debe entrar. En capa 4, firewall con estado, rate limiting, SYN cookies, límites de conexión y telemetría de flujos con NetFlow: la diferencia entre absorber un flood y perder el servicio. En capa 5, expiración y rotación de sesiones, revocación, MFA resistente al AiTM y detección de anomalías como accesos imposibles. En capa 6, TLS 1.3, HSTS, validación estricta de certificados y parsers robustos frente a codificaciones ambiguas. Y en capa 7, validación de entrada, autorización en cada endpoint, WAF, MFA, logging y pruebas guiadas por riesgo con la OWASP WSTG. Ninguno de estos controles por separado detiene un ataque decidido; el curso lo explícita en su nodo de controles compensatorios: la mejor defensa combina prevención, detección, contención y recuperación, y la validación debe hacerse con pruebas controladas.

El corolario operativo también está en el curso: aplica controles cerca de donde nace el riesgo. No se corrige un problema de capa 2 con más reglas en el WAF, ni un agotamiento de estado en capa 4 endureciendo la aplicación. Diagnóstico por capas primero, control en la capa correcta después. Es la misma lógica de un médico que trata la causa y no el síntoma, aplicada a una pila de red.

En resumen

Básicos Protección Capas OSI hace algo poco común: toma el concepto de red más memorizado y menos usado de la formación técnica y lo convierte en un método de trabajo defensivo. Sus tres preguntas (dónde ocurre, qué afecta y qué control lo corta) son aplicables a cualquier incidente, y su insistencia en cruzar capas antes de cerrar causa raíz es la disciplina que separa a un equipo que reacciona de uno que responde. El repositorio público en GitHub permite estudiar el código, proponer mejoras o usarlo como plantilla para formación interna. Si construyes o despliegas sistemas de IA, este mapa capa a capa es, literalmente, la lista de cosas que tu despliegue hace bien y de las que nadie ha comprobado todavía.