Llevo un tiempo leyendo sobre seguridad en modelos de lenguaje (LLMs), en particular sobre los llamados ataques de jailbreak: estrategias diseñadas para eludir los mecanismos de alineación de seguridad. Lo que más me sorprendió al revisar la literatura reciente (2022–2026) es que estos ataques han alcanzado tasas de éxito alarmantes ataques automatizados avanzados logran entre 90–99% de efectividad en modelos de pesos abiertos y entre 80–94% en modelos propietarios. Por eso quiero dejar por escrito lo que he encontrado, y sobre todo el concepto que más me llamó la atención: la robustez adversarial, que me parece el núcleo teórico que explica por qué estos ataques persisten a pesar de todos los esfuerzos de alineación, y que creo que puede ser la base de un proyecto de investigación serio.^[1]

1. Lo que encontré al revisar el campo (2024–2026)

1.1 Cómo han evolucionado las taxonomías de ataques

Algo que noto al leer varios surveys recientes es un cambio de enfoque: se está pasando de clasificaciones descriptivas (basadas en la forma del prompt) hacia taxonomías causales (basadas en el mecanismo de fallo del modelo). Este cambio me parece central para entender dónde encaja la idea de robustez adversarial.

Uno de los trabajos fundacionales que revisé es el de Wei et al. (2023), que identifica dos modos de fallo primarios de la alineación:^[2,3]

• Competing objectives (objetivos en competencia): la alineación de seguridad entra en conflicto con el objetivo fundamental del modelo de seguir instrucciones. Los jailbreaks explotan ese conflicto creando prompts donde obedecer la instrucción resulta plausible bajo la distribución de preentrenamiento.
• Mismatched generalization (generalización desajustada): el entrenamiento de seguridad usa un conjunto limitado de comportamientos inseguros, pero el modelo tiene capacidades que van más allá de esa distribución. Si le pides algo que el modelo puede hacer pero que no fue cubierto durante la alineación, responde sin restricciones.

Después encontré una taxonomía más reciente (arXiv 2504.04976, abril 2025) que extiende este marco y añade una tercera categoría que me resultó muy útil:^[4,5]

• Adversarial robustness (robustez adversarial): vulnerabilidades asociadas a perturbaciones adversariales específicas del espacio de entrada —texto— que el modelo no puede resistir por falta de entrenamiento adversarial suficiente. A diferencia de la generalización desajustada, aquí el ataque explota directamente la fragilidad del modelo ante entradas diseñadas deliberadamente para inducir fallos, no simplemente ante distribuciones no vistas.
• Mixed attacks (ataques mixtos): combinaciones de los tres mecanismos anteriores. En la práctica, la mayoría de los ataques sofisticados que se ven hoy caen aquí.

También leí el survey de arXiv 2407.04295, que propone una taxonomía dual ataque/defensa organizada según el nivel de acceso al modelo (caja blanca vs. caja negra). Me parece una distinción importante: los ataques de caja blanca, basados en gradientes y logits, requieren acceso a los pesos del modelo, mientras que los de caja negra —los que llegan a 80–94% de efectividad en modelos propietarios— solo necesitan acceso a la API, es decir, son los que más me preocupan como usuario común de estos sistemas.^[6,1]

Por último, hay una taxonomía jerárquica aún más amplia (arXiv 2510.13893) que propone 50 técnicas organizadas en siete familias: suplantación/escenarios ficticios, escalada de privilegios, persuasión, sobrecarga cognitiva, codificación/ofuscación, ataques de conflicto de objetivos, y envenenamiento de datos. Me parece útil tanto para clasificar ataques como para pensar en cómo diseñar detectores.^[7]

1.2 El problema de la robustez adversarial

Por lo que he entendido, la robustez adversarial en LLMs es la capacidad del modelo de mantener su comportamiento alineado (rechazar solicitudes dañinas) ante entradas diseñadas deliberadamente para inducir un fallo, sin importar la forma que tome el ataque. A diferencia de la robustez en visión por computadora —donde la perturbación adversarial es una pequeña modificación en el espacio de píxeles— en los LLMs el «espacio de perturbación» es el lenguaje natural mismo, con todas sus transformaciones semánticas y sintácticas posibles.^[8,9,10]

Algo que me parece clave —y que tendré que tener muy en cuenta si avanzo con un proyecto sobre esto— es que esta robustez es fundamentalmente no uniforme: varía mucho entre modelos, entre categorías de daño y entre tipos de ataque. Esto significa que las evaluaciones de robustez deben hacerse por tarea y por categoría, no de forma agregada.^[10]

Revisando trabajos de ICLR 2025 me encontré con algo bastante contundente: tanto los modelos de pesos abiertos como los propietarios resultan «completamente no robustos» ante ataques adversariales suficientemente sofisticados. El método R2D2 intenta adaptar el entrenamiento adversarial de Madry (que funciona bien en visión) a los LLMs, pero se topa con un problema de fondo: el espacio de ataque en texto es discreto y no diferenciable, lo que complica muchísimo la optimización.^[9,8]

1.3 Cómo organizo en mi cabeza las defensas

Para no perderme, organicé las defensas siguiendo la taxonomía del survey arXiv 2511.18933, que las clasifica según su posición en el pipeline de inferencia:^[11]

Algo que me hizo reflexionar bastante: un trabajo de NDSS 2026 identifica el Security-Utility Pareto Trade-off como la tensión central de cualquier diseño defensivo. En cristiano: mejorar la seguridad casi siempre aumenta los falsos rechazos en prompts benignos, y eso degrada la utilidad del modelo. El benchmark USEBench (2025) muestra con números que las defensas convencionales no logran garantizar al mismo tiempo alta seguridad y alto rendimiento.^[12,13]

También vi un trabajo de ACL 2025 que evalúa 17 ataques contra ocho defensas avanzadas, y encuentra algo que me parece muy revelador: los ataques que generan prompts diversos y naturales (como PAIR y TAP, basados en retroalimentación) logran ASRs superiores al 15% incluso con todas las defensas activas, mientras que los ataques más predecibles sí pueden reducirse a 0% con defensores como PromptGuard.^[14]

2. Cómo entiendo la robustez adversarial

Para ordenar mis propias ideas, llegué a esta formalización: sea M un modelo de lenguaje alineado y x una consulta dañina. La alineación logra que M(x) = rechazo. Un ataque adversarial construye x’ = x + δ, donde δ es una perturbación que preserva la intención dañina de x pero altera la representación de superficie o semántica lo suficiente para que M(x’) ≠ rechazo.^[15,10]

La métrica principal que voy a usar es la Attack Success Rate (ASR):

ASR(y, g, f) = (1/N) · Σᵢ c( f_T(xᵢ), y )

donde y es un comportamiento dañino, g un método de ataque, f el modelo objetivo, xᵢ el i-ésimo prompt adversarial, f_T la respuesta del modelo bajo decodificación greedy, y c un clasificador binario. Su complemento es la Robustness Score:^[15]

Robustness(f, g) = 1 − (1/M) · Σⱼ ASR(yⱼ, g, f)

donde M es el número de comportamientos evaluados.^[15]

Lo que más me ayudó a ordenar las ideas fue distinguir tres tipos de fallo, que aunque suenan parecidos son cualitativamente distintos:^[5,4]

• La generalización desajustada es un fallo del entrenamiento: la distribución de seguridad no cubre toda la distribución de capacidades del modelo.
• Los objetivos en competencia son un fallo de diseño: los objetivos de seguir instrucciones y los de seguridad son, por naturaleza, conflictivos.
• La robustez adversarial es un fallo del modelo ante perturbaciones optimizadas: incluso si el modelo estuviera perfectamente alineado para distribuciones normales, un adversario puede construir entradas que lo quiebren.^[3,16]

Y esto no es solo un ejercicio teórico: las soluciones son distintas para cada caso. La generalización desajustada se mitiga ampliando la cobertura del entrenamiento de seguridad; los objetivos en competencia requieren rediseñar el proceso de alineación; y la robustez adversarial exige entrenamiento adversarial específico. Si voy a proponer una defensa, necesito tener claro a cuál de estos tres problemas le estoy apuntando.^[17,8]

3. Cómo estoy pensando estructurar mi proyecto de investigación

3.1 Dónde creo que puedo aportar

Después de toda esta lectura, veo tres vacíos en la literatura que me parecen buenos puntos de entrada para un proyecto académico:

1. Falta de evaluación estandarizada: las métricas de robustez cambian de un trabajo a otro, lo que dificulta comparar resultados. HarmBench y JailbreakBench ayudan, pero aún hay mucha heterogeneidad en las evaluaciones multi-turno.^[18,19,15]
2. Falta de cobertura multilingüe: casi todos los datasets y defensas están en inglés. El trabajo de arXiv 2510.13893 lo señala explícitamente, y me parece un ángulo natural dado que trabajo en español.^[7]
3. Falta de análisis causal: la mayoría de las evaluaciones se quedan en qué ataques funcionan, pero pocas explican por qué la robustez adversarial cambia entre categorías de daño y entre modelos. Este es el ángulo que más me interesa, porque conecta con mi formación más estructural.^[10]

Taxonomía de defensas contra jailbreaks y robustez adversarial en LLMs (2024-2026), clasificada por etapa del pipeline de procesamiento.

3.2 Las preguntas que me estoy haciendo

Por ahora estoy organizando mi proyecto alrededor de estas cuatro preguntas:

• PI-1 (Caracterización): ¿Cómo se distribuyen las vulnerabilidades de robustez adversarial entre categorías de daño, tipos de ataque y familias de modelos?
• PI-2 (Mecanismo): ¿Qué patrones internos (representaciones, capas) predicen la susceptibilidad de un LLM a ataques adversariales específicos?
• PI-3 (Defensa): ¿Cuál es el trade-off entre robustez adversarial y utilidad bajo distintas estrategias defensivas, y qué condiciones minimizan ese trade-off?
• PI-4 (Transferibilidad): ¿En qué medida los ataques entrenados contra un modelo se transfieren a otros, y qué características estructurales explican esa transferibilidad?

3.3 Cómo pienso abordarlo

Mi plan de trabajo tiene varias fases, combinando revisión sistemática con experimentación:

Fase 1 Revisión sistemática de literatura. Voy a seguir un protocolo tipo Kitchenham para construir un corpus de estudios (2022–2026) de venues de seguridad e IA (IEEE S&P, USENIX Security, ACL, EMNLP, NeurIPS, ICLR), centrándome en trabajos que evalúen robustez adversarial de LLMs de forma empírica.^[20,21,22]

Fase 2 — Marco de evaluación unificado. Pienso adoptar y extender HarmBench, incluyendo:^[19]

• Un conjunto de comportamientos dañinos por categoría (física, informacional, social).
• Varios métodos de ataque, al menos uno por cada categoría de la taxonomía causal (generalización desajustada, objetivos en competencia, robustez adversarial).
• Métricas de ASR y del Security-Utility Pareto (usando el índice USEIndex).^[13]

Fase 3 Experimentación comparativa. Quiero evaluar modelos open-weight (Llama 3, Mistral, Falcon) con el framework unificado, incluyendo:

• Análisis de ablación por tipo de ataque.
• Análisis de transferibilidad entre modelos.
• Análisis de degradación de utilidad bajo defensas.

Fase 4 Análisis estructural. Aquí quiero meterme con las representaciones internas (activaciones, capas de atención) para encontrar correlatos de vulnerabilidad, siguiendo el enfoque de LED (Layer-specific Editing) y el trabajo de NDSS 2026 sobre discriminabilidad en estados ocultos.^[23,12]

Fase 5 Propuesta defensiva. Con todo lo anterior, diseñar una estrategia defensiva y evaluarla contra el trade-off seguridad-utilidad.

3.4 Herramientas y benchmarks que tengo en mi radar

3.5 Cómo planeo organizar el documento final

Para cuando llegue el momento de escribir el artículo o capítulo de tesis, pienso seguir esta estructura:

1. Introducción :motivación, problema de investigación, contribuciones.
2. Marco conceptual :definición operacional de robustez adversarial, taxonomía de vulnerabilidades.
3. Revisión de literatura : organizada por eje (taxonomías de ataques / de defensas / evaluación).
4. Metodología :framework de evaluación, selección de modelos y ataques, métricas.
5. Resultados — ASR por categoría, trade-offs seguridad-utilidad, análisis de transferibilidad.
6. Discusión :patrones, implicaciones teóricas, limitaciones.
7. Conclusiones y trabajo futuro.

4. Lo que tengo que cuidar

Revisando un meta-análisis de papers de 2023-2024 (arXiv 2512.09549), encontré una lista de errores recurrentes en investigación de seguridad de LLMs que me anoto para no repetir:^[21]

• Evaluar un solo modelo: las conclusiones sobre robustez no generalizan si solo pruebo un modelo.
• Reportar ASR sin contexto de utilidad: un modelo que rechaza todo tiene ASR de 0% pero es inútil.
• No tener línea base adversarial: comparar defensas sin un atacante adaptativo da resultados demasiado optimistas.
• Inconsistencia en el «juez» de éxito: el clasificador binario que decide si un ataque tuvo éxito necesita validarse de forma independiente.^[14]

También tengo presente el dilema ético de fondo: publicar detalles de ataques efectivos puede facilitar su uso malicioso. Quiero integrar protocolos de divulgación responsable desde el diseño mismo del proyecto, no como algo que se piensa al final.

5. La conexión que más me interesa: sistemas sociotécnicos

Como me interesan los sistemas sociotécnicos y el análisis organizacional, hay una dimensión que muy pocos trabajos del área exploran y que quiero desarrollar: pensar los ataques de jailbreak no solo como fenómenos técnicos, sino como comportamientos de agentes dentro de redes sociotécnicas. Los ataques de persuasión basados en taxonomías de ciencias sociales, y los ataques multiturno guiados por agentes, son ejemplos donde dinámicas sociales manipulación, autoridad, reciprocidad— se trasladan al espacio adversarial. Me parece que esto se puede articular bien con marcos teóricos de sistemas complejos (Conway, Kauffman), conectando el análisis de vulnerabilidades con patrones de interacción humano-sistema. Este es, probablemente, el ángulo que más quiero desarrollar a futuro.^[6,1]

6. Otros frentes que estoy explorando

Más allá de todo lo anterior, hay otros cinco frentes que me parecen muy activos ahora mismo y que quiero dejar anotados, porque cualquiera de ellos podría convertirse en el eje central de mi proyecto.

6.1 Robustez adversarial en sistemas multimodales (MLLMs)

Este me parece el frente más activo en 2025–2026. Cuando se combinan texto + imagen + audio, aparecen vulnerabilidades nuevas que los ataques monomodales no capturan. Los ataques de inconsistencia cross-modal —una imagen benigna combinada con texto dañino que se potencian mutuamente— son difíciles de defender porque los filtros de prompt solo ven una modalidad a la vez. Un survey publicado en Transactions on Machine Learning Research (2026) organiza estos ataques según el objetivo del adversario y las debilidades arquitectónicas en la fusión de modalidades, analizando 88 trabajos.^[25] Este eje me parece especialmente rico porque la evaluación de robustez en multimodalidad todavía está sin estandarizar.

6.2 Robustez en agentes autónomos multi-componente

Los ataques contra agentes LLM son cualitativamente distintos a los ataques contra chatbots: el agente tiene componentes (retriever, evaluador, árbol de búsqueda) y cada uno es un vector de ataque independiente. El framework ARE (Agent Robustness Evaluation) demuestra que con perturbaciones imperceptibles a una sola imagen menos del 5% de los píxeles de una página web— se logra redirigir agentes con tasas de éxito de hasta 67%.^[26] Lo que más me llama la atención es que agregar componentes que mejoran el rendimiento benigno puede abrir nuevas vulnerabilidades, algo que conecta directamente con el análisis de sistemas complejos y la dinámica sociotécnica que mencioné en la sección anterior.

6.3 Robustez adversarial multilingüe

Casi toda la literatura de evaluación está en inglés. Trabajos recientes empiezan a explorar la robustez adversarial y la alineación de seguridad en LLMs multilingües y multimodales, un territorio todavía casi vacío.^[27,28] Para alguien que investiga desde una región hispanohablante, esto me parece un nicho diferenciador claro: construir benchmarks de robustez adversarial en español (o en lenguas de bajos recursos) y evaluar si los mecanismos de defensa entrenados en inglés realmente generalizan.

6.4 Jailbreak en dominios de alto riesgo

La investigación en salud y ciberseguridad muestra que los LLMs son muy vulnerables cuando el dominio tiene vocabulario especializado que no está bien cubierto en el entrenamiento de seguridad básicamente, otra forma de generalización desajustada, pero en contextos técnicos. Construir pipelines de evaluación específicos de dominio por ejemplo, ingeniería de software o educación en programación, que es justamente mi campo— me parece un eje viable y con buena conexión con mi perfil docente.

6.5 El trade-off seguridad-utilidad: análisis formal

Este es, para mí, el problema teórico más abierto de todos: todavía no he visto ningún trabajo que demuestre formalmente bajo qué condiciones es posible o imposible alcanzar simultáneamente alta robustez y alta utilidad. Formalizar este trade-off como un problema de optimización multiobjetivo, inspirándome en los trabajos de Pareto en sistemas complejos, me parece que podría ser una contribución teórica sólida por sí misma, incluso independiente de cualquier experimentación.

Referencias

1. Jailbreaking LLMs & VLMs: Mechanisms, Evaluation, and…
2. Jailbroken: How Does LLM Safety Training Fail? — GUIDE (recurso curado sobre desinformación)
3. [2307.02483] Jailbroken: How Does LLM Safety Training Fail? — arXiv
4. A Domain-Based Taxonomy of Jailbreak Vulnerabilities in Large LLMs
5. A Domain-Based Taxonomy of Jailbreak Vulnerabilities in Large LLMs — arXiv
6. Jailbreak Attacks and Defenses Against Large Language Models
7. A Taxonomy-Driven Approach to Jailbreak Detection — arXiv
8. Published as a conference paper at ICLR 2025
9. Published as a conference paper at ICLR 2025 (arXiv)
10. Towards Robust LLMs: an Adversarial Robustness Measurement Framework
11. arXiv:2505.01177v1 [cs.CR]
12. Vanishing Discriminability in LLM Hidden States Fuels Jailbreak — NDSS
13. The Performance Degradation of LLMs with Jailbreak Defense
14. Comprehensive Assessment of Jailbreak Attacks Against LLMs — ACL
15. HarmBench: Standardized LLM Red Teaming Framework
16. CodeAttack: Revealing Safety Generalization Challenges of Large LLMs
17. OpenReview paper 000
18. An Open Robustness Benchmark for Jailbreaking LLMs
19. HarmBench: A Standardized Evaluation Framework for Automated Red Teaming and Robust Refusal
20. Investigating the use of LLMs in software security
21. Chasing Shadows: Pitfalls in LLM Security Research — arXiv
22. Large Language Models (LLMs) For Cybersecurity: A Systematic Review
23. Defending Large Language Models Against Jailbreak — EMNLP Findings
24. LLMs Caught in the Crossfire: Malware Requests and Jailbreak Challenges — ACL
25. A survey on attacks and vulnerabilities of multimodal LLMs organized by adversarial objective — TMLR 2026
26. Dissecting Adversarial Robustness of Multimodal LM Agents (ARE) — arXiv
27. Multilingual Safety Alignment Via Sparse Weight Editing — arXiv
28. SpeechJBB: Probing Safety Alignment in Large Audio Language Models under Code-Switched Speech — arXiv

Lo que pasó después cambió la clase

Por Jaider Enrique Reyes Herazo — Docente de Ingeniería en Sistemas

Hay clases que uno planea con cuidado durante días. Hay otras que simplemente ocurren solas. Y esas, casi siempre, son las más memorables.

Esta es la historia de una de esas clases.

El contexto: laboratorio de Sistemas Operativos

Estábamos en la unidad de operación y protección de servidores. El laboratorio de ese día tenía un objetivo claro: el estudiante configurara correctamente el firewall de su máquina usando ufw o nftables, levantara un servicio web básico con Apache, y demostrara que sabía qué puertos estaban abiertos y cuáles cerrados usando herramientas como ss, curl y nc.

Nada fuera de lo ordinario. Una práctica técnica de la clase , estructurada, evaluable.

Hasta que …

El reto

«Profe, ya terminé. Tengo el firewall configurado, el servidor corriendo y bloqueé todas las entradas. Nadie puede acceder a mi máquina.«

Lo dijo con esa seguridad particular que tienen los estudiantes cuando creen que han cerrado todas las puertas. Con orgullo legítimo, además había hecho bien su trabajo.

Y entonces, casi como provocación amistosa, agregó:

«Les reto a que intenten entrar. Tengo una página web de memes de la carrera corriendo en el puerto 80. A ver quién llega.«

El salón despertó. Ese tipo de reto no se rechaza.

Yo miré mi celular. Tenía Termux corriendo. Tenía acceso a mi Kali Linux desde ahí mismo. Y tenía una oportunidad pedagógica que ninguna diapositiva hubiera podido crear.

«Bueno«, dije. «Veamos.«

Primer movimiento: lo más directo primero

Lo primero que hice fue intentar conectarme por SSH directamente como root. Sin rodeos:

bash

ssh -p 22 root@10.10.10.156

Permission denied, please try again.
Permission denied, please try again.
Permission denied

Tres intentos. Tres rechazos. El estudiante sonrió desde su puesto.

Pero eso no era un fracaso era información. El servidor existía, respondía, y tenía SSH activo pero protegido. Primer dato confirmado.

Le expliqué al grupo lo que acababa de pasar: «El firewall no me dijo ‘no existo’. Me dijo ‘no puedes entrar por aquí’. Eso es diferente. Significa que hay algo adentro.»

Segundo movimiento: el firewall bloquea Nmap

El siguiente paso era un escaneo con Nmap para ver qué puertos estaban realmente expuestos:

bash

nmap -sV -sC 10.10.10.156

Y aquí llegó la primera lección no planeada del día:

route_dst_netlink: cannot bind AF_NETLINK socket: Permission denied

Nmap fallaba. El entorno desde el que operaba no tenía los privilegios de red necesarios para hacer escaneos de bajo nivel — exactamente el tipo de restricción que un firewall bien configurado puede imponer sobre el tráfico de red raw.

El estudiante celebró desde su silla.

Pero yo sabía que el juego no había terminado.

«Esto es lo que pasa en el mundo real», le dije al grupo. «Los firewalls no siempre te bloquean completamente. A veces solo te complican el camino. Un ingeniero se adapta.»

Tercer movimiento: pensar diferente

Nmap tiene múltiples modos de operación. El escaneo SYN estándar (-sS) requiere privilegios de red de bajo nivel — raw sockets. El TCP Connect Scan (-sT) no los necesita. Usa las llamadas normales del sistema operativo y funciona incluso bajo restricciones:

bash

nmap -sT -sV 10.10.10.156

Esta vez, el resultado apareció:

22/tcp  open  ssh    OpenSSH (Ubuntu)
80/tcp  open  http   Apache/2.4.58 (Ubuntu)

Dos puertos. Dos puertas visibles.

El puerto 22 ya lo conocíamos — SSH, con acceso root bloqueado. El puerto 80 era el interesante. HTTP. El servidor web del reto.

Proyecté la pantalla del celular para que todos vieran en tiempo real.

El descubrimiento: la página de memes

Usé curl para inspeccionar el servidor. Sin navegador, sin interfaz gráfica — solo el protocolo HTTP en su forma más pura, desde la terminal:

bash

curl -I http://10.10.10.156

http

HTTP/1.1 200 OK
Server: Apache/2.4.58 (Ubuntu)
Last-Modified: Mon, 27 Apr 2026 19:38:17 GMT
Content-Length: 1897
Content-Type: text/html

El servidor respondía perfectamente. Luego fui por el contenido completo:

bash

curl -s http://10.10.10.156

Y apareció en pantalla:

html

<title>Memes Ingeniería en Sistemas</title>

El salón estalló en carcajadas.

Ahí estaba — la página de memes, completamente accesible desde el puerto 80. El estudiante había bloqueado SSH, había configurado reglas de firewall, había hecho bien gran parte del laboratorio. Pero había dejado el puerto 80 abierto al mundo porque ese era, precisamente, el propósito del reto.

Y ese puerto abierto era todo lo que necesitábamos.

La enumeración: buscar lo que no está a la vista

Con acceso confirmado al servidor web, continué la demostración con Gobuster — una herramienta que realiza fuerza bruta de rutas web, preguntando al servidor por miles de direcciones posibles hasta encontrar las que realmente existen:

bash

gobuster dir \
  -u http://10.10.10.156 \
  -w /usr/share/wordlists/dirb/common.txt \
  -x php,html,txt,zip,bak \
  -t 50

Y en paralelo, Nikto, que analiza el servidor buscando configuraciones inseguras, archivos expuestos y cabeceras de seguridad faltantes:

bash

nikto -h http://10.10.10.156

Mientras las herramientas corrían, aproveché para lanzar una pregunta al grupo:

«¿Qué creen que le ha pasado a ese servidor?»

Las respuestas fueron reveladoras. Algunos dijeron «nada, si el estudiante solo subió la página de memes». Otros, los más curiosos, empezaron a especular: «¿Y si tiene un /admin sin contraseña? ¿Y si dejó un archivo de configuración expuesto?»

Esa conversación espontánea valía más que cualquier diapositiva sobre seguridad web que yo hubiera podido preparar.

La lección que no estaba en el plan de clase

Cuando los primeros resultados comenzaron a aparecer, hice una pausa.

No para mostrar qué habíamos encontrado sino para hablar de lo que significaba todo el proceso.

Le pregunté directamente al estudiante que había lanzado el reto: «¿Qué aprendiste hoy sobre tu propio servidor?»

Se quedó pensando un momento. Luego respondió:

«Que configurar el firewall no es suficiente si no sé qué está corriendo adentro.»

Exactamente.

Un firewall es una herramienta. Puede bloquear puertos, filtrar IPs, rechazar conexiones. Pero si el servicio que corre detrás de ese firewall tiene vulnerabilidades — archivos expuestos, contraseñas débiles, configuraciones por defecto sin cambiar — el atacante no necesita «romper» el firewall. Solo necesita encontrar la puerta que quedó entreabierta.

En este caso: el puerto 80, abierto por diseño, pero sin considerar todo lo que podía hacerse desde él.

Lo que esta clase me recordó sobre enseñar

Soy docente de Ingeniería en Sistemas. Trabajo con ufw, nftables, ss, curl, nc  las mismas herramientas de la rúbrica de ese laboratorio. Las enseño porque las uso. Porque sé que un egresado que no entiende cómo funciona un firewall desde adentro y desde afuera, está a medias en su formación profesional.

Pero lo que más valoro de ese día no fue el comando que funcionó, ni haber accedido al servidor desde el celular con Termux.

Fue la pregunta que un estudiante se hizo a sí mismo cuando vio su propio servidor desde el otro lado.

Esa pregunta  «¿qué dejé mal configurado?» es exactamente la misma que se hace un profesional de seguridad cada vez que audita un sistema. Aprenderla en el aula, con un servidor de memes de la carrera como campo de práctica, es el tipo de aprendizaje que no se olvida.

Reflexión final: la ética no es opcional

Todo lo que hicimos ese día ocurrió en un entorno controlado, con autorización explícita. El estudiante mismo lanzó el reto públicamente frente al grupo, ante mí como docente. Eso no es un detalle menor — es el detalle que lo hace todo válido.

En Colombia, la Ley 1273 de 2009 tipifica como delito el acceso abusivo a sistemas informáticos, la interceptación de datos y el daño a la integridad de sistemas. Las mismas herramientas que usamos ese día — Nmap, Gobuster, Nikto — son ilegales cuando se usan sin autorización.

La diferencia entre un hacker ético y un atacante no está en las herramientas. Está en el consentimiento, la transparencia y el propósito.

Enseñar seguridad informática sin enseñar ética no es enseñar seguridad. Es enseñar a romper cosas.

Ese día, creo, enseñamos las dos.

Guía técnica completa del laboratorio

Si eres docente o estudiante y quieres replicar este ejercicio en tu propio entorno, preparé una guía técnica detallada con todos los comandos, explicaciones paso a paso y el flujo metodológico completo:

📄 Descargar Guía — Lab Ethical Hacking en Red Local

La guía incluye:

• Reconocimiento con Nmap con y sin restricciones de firewall
• Inspección de servidores web con curl
• Enumeración de directorios con Gobuster
• Análisis de vulnerabilidades con Nikto
• Técnicas de acceso SSH y hardening del servidor objetivo
• Template de reporte de hallazgos para usar en clase

Jaider Enrique Reyes Herazo Docente — Ingeniería en Sistemas | Sincelejo, Colombia

#SeguridadInformática #EthicalHacking #IngenieríaEnSistemas #SistemasOperativos #Docencia #KaliLinux #Termux #Laboratorio

La capacidad que tiene una sistema de acoplarse a otros sistemas, no es un tema nuevo no tampoco extraño para nadie, pero para poder entender esto vamos al año del 2002 cuando Jeff besos con su mandato API https://gist.github.com/chitchcock/1281611

Pero en una ocasión —creo que allá por 2002, un año más o menos—, [Bezos] emitió un mandato tan ambicioso, tan enorme y descomunal, que hizo que todos sus demás mandatos parecieran bonificaciones no solicitadas. Su Gran Mandato decía algo así:

• A partir de ahora todos los equipos expondrán sus datos y funcionalidades a través de interfaces de servicio.
• Los equipos deben comunicarse entre sí a través de estas interfaces.
• No se permitirá ninguna otra forma de comunicación entre procesos: enlaces directos, lecturas directas del almacén de datos de otro equipo, modelo de memoria compartida ni puertas traseras de ningún tipo. La única comunicación permitida es mediante llamadas a la interfaz de servicio a través de la red.
• No importa qué tecnología usen. HTTP, Corba, Pubsub, protocolos personalizados… da igual. A Bezos le da igual.
• Todas las interfaces de servicio, sin excepción, deben diseñarse desde cero para que sean externalizables. Es decir, el equipo debe planificar y diseñar para poder exponer la interfaz a los desarrolladores externos. Sin excepciones.
• «Quien no haga esto será despedido».

Ni Jeff Bezos ni sus ingenieros de alto nivel han negado el Mandato, y se ha convertido en un clásico de la tecnología. Con razón, porque lo que encapsula ha transformado la informática —y los negocios— para siempre.

es importante entender que La interoperabilidad es la capacidad de que sistemas, aplicaciones o componentes “se entiendan” lo suficiente como para comunicarse, ejecutar funciones o transferir datos sin que el usuario tenga que aprenderse las rarezas internas de cada uno, el modelo asociado a ISO/IEC 25010 ubica la interoperabilidad como parte de compatibilidad, y la describe como el grado en que un sistema puede intercambiar información y usarla mutuamente con otros productos o componentes. 

La interoperabilidad suele confundirse con “conectar sistemas”, pero en realidad es una capacidad más exigente: que diferentes componentes puedan comunicarse, ejecutar funciones o transferir datos de forma que el usuario necesite poco o ningún conocimiento de las particularidades internas de cada uno. Así la describen definiciones normativas clásicas en estándares internacionales. En términos de calidad de software, además, la interoperabilidad se asume como un atributo medible: el grado en que un sistema puede intercambiar información y usar la información intercambiadacon otros sistemas o componentes, lo que obliga a pensar en diseño, pruebas y gobierno, no solo en “pasar mensajes”. 

Para que esa capacidad sea real (y no una demo bonita), conviene abordarla por capas: legal, organizacional, semántica y técnica. En el sector salud, esta visión es crítica porque el valor no está en mover datos, sino en preservar significado clínico, habilitar continuidad del cuidado y reducir fricciones entre historia clínica, laboratorio, imágenes, farmacia, facturación y vigilancia en salud pública. La agenda global también empuja en esa dirección: la OMS ha enfatizado la adopción de estándares abiertos y la necesidad de guías y enfoques prácticos para convertir recomendaciones clínicas y de salud pública en sistemas digitales interoperables, articulándolo con su estrategia global de salud digital 2020–2025. 

Desde mi experiencia implementando interoperabilidad en entornos sanitarios, el salto de “integración” a “interoperabilidad” ocurre cuando se define un lenguaje común y se sostiene con arquitectura y gobierno. En la práctica, esto suele traducirse en adoptar un estándar de intercambio clínico moderno como HL7 FHIR (hoy ampliamente usado como base para APIs), apoyarse en guías de implementación para aterrizar los “campos opcionales” a reglas concretas, y complementar con un esquema robusto de autorización y contexto clínico para aplicaciones (por ejemplo, marcos tipo SMART App Launch). Dicho sin vueltas: interoperabilidad no es “API y ya”; es API + perfiles/IG + terminología + seguridad + trazabilidad.

Un patrón que me ha funcionado para salud es avanzar por casos de uso de alto impacto y baja ambigüedad (p. ej., resumen clínico, resultados de laboratorio, medicación activa, citas/encuentros), y construir una “columna vertebral” interoperable: (1) modelo canónico (basado en recursos/perfiles), (2) servicio de terminologías para garantizar semántica consistente, (3) identidad y consentimiento (quién accede y por qué), (4) auditoría y (5) conectores hacia sistemas heredados (HIS/LIS/RIS) para evitar el “big bang”. En el frente de seguridad, cuando se habilitan apps o integraciones de terceros, el uso de estándares abiertos como OAuth 2.0 y OpenID Connect dentro del ecosistema SMART on FHIR ayuda a sostener el principio mínimo necesario y a controlar accesos por alcance (scopes). 

En síntesis, una estrategia seria de interoperabilidad en salud se mide menos por cuántas integraciones existen y más por tres resultados: (a) datos clínicos reutilizables sin reinterpretaciones manuales, (b) flujos interinstitucionales sostenibles (gobierno y acuerdos), y (c) confianza (seguridad, auditoría, cumplimiento). El camino recomendado es incremental, guiado por estándares y con disciplina de ingeniería: definir qué se comparte, con qué significado, bajo qué reglas y cómo se opera en el tiempo. Y cuando eso se hace bien, la interoperabilidad deja de ser un proyecto “de TI” y se convierte en una capacidad organizacional que mejora la atención y habilita innovación (analítica, IA clínica, telemedicina, salud pública digital) sin romper la coherencia del dato.

Aplicación práctica en el sector salud: lo que sí funciona en campo

Desde mi experiencia implementando interoperabilidad en entornos sanitarios, el avance sostenido ocurre cuando se construye una “columna vertebral” que combine estándar, seguridad y gobierno. Un estándar moderno y ampliamente adoptado para intercambio de información clínica es FHIR, desarrollado por Health Level Seven International, diseñado para facilitar el intercambio electrónico de datos de salud y habilitar integraciones más ágiles (incluyendo enfoques basados en APIs). Pero el estándar por sí solo no resuelve el problema: en la práctica, la interoperabilidad clínica se consolida cuando se adoptan perfiles/guías de implementación (para fijar reglas de uso), un enfoque de terminologías(para coherencia semántica), y mecanismos de auditoría y trazabilidad (para confianza operativa).

En seguridad, mi enfoque ha sido asumir que “interoperabilidad sin control de acceso” es como dejar la historia clínica en una mesa de cafetería: innovador, sí… pero no en el buen sentido. Para integraciones y aplicaciones que acceden a datos clínicos, es común apoyarse en OAuth 2.0, estándar publicado por la Internet Engineering Task Force para delegar acceso limitado a servicios HTTP. Cuando además se requiere una capa de autenticación interoperable, OpenID Connect define ese rol sobre OAuth 2.0, estandarizando cómo verificar identidad y transportar “claims” de usuario. Y en el mundo FHIR, el marco SMART App Launch formaliza el “enganche” de aplicaciones de terceros a sistemas clínicos, incluyendo contexto de lanzamiento y autorización. En conjunto, esto permite que el acceso sea sustituible, controlado y auditable, algo clave para escalar sin convertir el ecosistema en una colección de accesos especiales.

Por qué esto importa a nivel global

La interoperabilidad es un habilitador directo de continuidad del cuidado, salud pública digital, analítica y (sí) IA clínica, pero solo si se sostiene con estándares y gobernanza. La World Health Organization, en su estrategia global de salud digital 2020–2025, resalta la importancia de la interoperabilidad (incluida la sintáctica y semántica) y el uso de normas/estándares para posibilitar el intercambio y uso de información en salud a escala. Eso conecta con una realidad operativa: la salud es un sistema multi-actor (IPS, aseguradores, laboratorios, imágenes, farmacia, vigilancia), y sin interoperabilidad lo que crece no es el valor… es la duplicación de datos, la fricción y el riesgo.

En salud, hablar de interoperabilidad no es un lujo académico: es la diferencia entre atención continua y “vuelva a traer los exámenes”. Con esa idea como brújula, cerré esta investigación construyendo un prototipo de historia clínica distribuida que pone el foco donde normalmente se rompe todo: el modelo de datos, el significado clínico y la capacidad de integrar componentes sin que cada integración sea una cirugía a corazón abierto. La meta no fue “conectar sistemas” por deporte, sino demostrar cómo una arquitectura bien pensada puede permitir que la información clínica viaje y se entienda de forma consistente, con trazabilidad y estructura.

El resultado es un repositorio público que documenta el proceso y deja el proyecto reproducible: código, módulos, evidencias visuales y una ruta clara para ejecutar y extender el prototipo. Este trabajo refleja una idea simple: la interoperabilidad en salud es una disciplina de ingeniería, no un parche; combina estándares, diseño modular, validación, seguridad y gobierno del dato. Para quienes enseñamos e implementamos, es la mejor forma de cerrar el ciclo: no solo “lo expliqué”, también lo construí y lo dejé listo para que otros lo revisen, lo desplieguen y lo mejoren.

Repositorio del proyecto: https://github.com/jaiderreyes/historia-clinica-distribuida.

Este proyecto está pensado como base para investigación aplicada y laboratorios de formación: un punto de partida para discutir interoperabilidad, arquitectura distribuida y modelado clínico sin depender de presentaciones bonitas… porque el código, como la historia clínica, no debería improvisarse.

Asistiendo al V congreso de ciencias multidisciplinarias y apropiacion de conocimiento. agradezco al equipo de Corporación Universitaria Antonio Jose De sucre Uajs por la invitación siempre es grato compartir temas que nos apasionan

Presentando los resultados del estudio sobre Integración e Interoperabilidad Legal de Historias Clínicas Electrónicas, un análisis crítico sobre los desafíos normativos, socio-técnicos y organizacionales que enfrenta Colombia para avanzar hacia ecosistemas de salud más articulados.
Un espacio para debatir evidencia, producir conocimiento y fortalecer la investigación aplicada en salud digital