IA generativa, reglas deterministas e intervención humana: lo que aprendí modelando amenazas con un pipeline híbrido

Cuando uno termina un máster, como el Máster en IA aplicada a la Ciberseguridad del Campus de Cibersegurdiad, lo último que quiere (yo al menos) es que el TFM quede guardado en un cajón, así que contacté con Chema Alonso a través de MyPublicInbox para publicarlo, y aquí lo tienes. Una prueba de concepto de modelado de amenazas con IA local, validación humana y núcleo determinista, como excusa para hablar de dónde conviene poner cada tipo de IA en un proceso y dónde no poner ninguna.

Figura 1: IA generativa, reglas deterministas e intervención humana.

Lo que aprendí modelando amenazas con un pipeline híbrido

Mi aporte en el proyecto está centrado en el modelado de amenazas en sistemas porque está vinculado a la gestión de riesgos, que es un poco a lo que me dedico, pero la pregunta que lo originó es más amplia y, creo, más interesante que el caso concreto: 

"¿Cuándo conviene dejar que un modelo generativo haga el trabajo, cuándo conviene dejarlo trabajar pero con validación humana, y cuándo conviene no usar IA en absoluto?"

El modelado de amenazas resultó ser un buen banco de pruebas para esa pregunta al convivir tareas de naturaleza muy distinta dentro de un mismo flujo. 

Figura 2: Cómo ser un experto en Inteligencia Artificial aplicada a Ciberseguridad.

Máster Online de Inteligencia Artificial Aplicada a la Ciberseguridad

Fecha de Comienzo - 15 de Octubre 2026 - 12 meses de duración

Algunas tareas le sientan bien a un LLM; otras lo hacen picar el anzuelo y otras, directamente, no necesitan IA. Este artículo cuenta cómo quedó repartido ese trabajo y por qué. La PoC es la anécdota y el reparto (por así decirlo) es la idea.

El problema concreto: el modelado de amenazas no escala

El modelado de amenazas identifica riesgos y propone mitigaciones en fases tempranas del diseño de sistemas, cuando la arquitectura todavía es flexible y cambiar algo cuesta poco. Suena a buena práctica obvia, y lo es. El problema es que cuesta hacerlo de forma sistemática.

Para analizar un sistema con un modelo de clasificación de amenazas como STRIDE hay que partir de un diagrama de arquitectura y convertirlo en un inventario estructurado. En otras palabras, hay que determinar qué componentes hay, de qué tipo es cada uno, cómo fluyen los datos entre ellos, qué límites de confianza se cruzan, si el transporte va cifrado o en claro, etcétera. 

Esa conversión manual del dibujo al inventario lleva tiempo, depende de experiencia especializada y, sobre todo, varía según el analista que la haga. Dos expertos pueden tipificar el mismo diagrama de forma distinta, punto a partir del cual el análisis entero diverge. Si esa traducción no se apoya en reglas explícitas, la reproducibilidad se ve comprometida.

La tentación en 2026 es obvia: que un modelo multimodal lea el diagrama y escupa el análisis completo de punta a punta. Y aquí es donde aparece la primera decisión de diseño importante.

El marco: tres decisiones, no una regla

La respuesta a "¿uso IA o no?" depende de la tarea, de "qué pasa cuando el modelo se equivoca" y de "si el problema ya se puede resolver con reglas estables". Con estos criterios las tareas de mi pipeline se acomodaron en tres enfoques distintos.

Figura 3: El mismo pipeline aplica tres criterios distintos.

IA con supervisión humana y validación (P1), reglas deterministas sin IA (P2-P3)

y la IA como capa auxiliar acotada (P4). Diagrama conceptual del autor.

• Primer enfoque - delegar en la IA, pero con supervisión y validación humana. 

Interpretar una imagen es justo lo que un modelo de visión hace bien y una regla determinista hace mal. No voy a escribir un parser para reconocer cajas, flechas y etiquetas escritas a mano alzada en cualquier diagrama posible. Para esa tarea, la IA aporta valor real. 

 

El problema no es usarla, es que un error suyo en este punto es silencioso y se propaga. Si tipifica mal un componente, todo el análisis posterior queda contaminado sin que nadie se entere. Por eso, en este enfoque, la IA trabaja pero no tiene la última palabra, y un humano valida antes de continuar.

• Segundo enfoque - no usar IA en absoluto. Una vez que tengo el inventario validado, decidir qué categorías STRIDE aplican a un `DataStore`, o qué controles mitigan la amenaza `Spoofing` sobre una entidad externa, ya es un problema resuelto.

Existe una correspondencia conocida y estable entre el tipo de activo y las amenazas que le aplican, y entre cada amenaza y sus controles. Meter un LLM ahí no agregaría capacidad, sino variabilidad donde quiero exactamente lo contrario. Para esto alcanzan reglas fijas, las cuales tienen una propiedad que ningún modelo generativo garantiza, que el mismo input produce siempre el mismo output.

• Tercer enfoque — la IA como ayudante, no como autor. Existe una tarea final donde la IA vuelve a ser útil pero de forma acotada, que es mejorar la redacción del informe y su lectura. Ahí puede sugerir texto más claro, siempre que no toque los hallazgos técnicos. Redacta, no decide. Eso sí, que no toque los datos no significa que la redacción salga siempre bien, ya que un modelo local puede introducir errores de interpretación al redactar una conclusión sin alterar un solo dato técnico. 

Por eso el enriquecimiento es opcional y siempre queda sujeto a una última lectura humana. La diferencia con P1 es de gravedad, aquí un error se queda en la prosa y un lector atento lo detecta, mientras que allí un error de tipificación se propagaba sin ser percibido en todo el análisis.

Una aclaración importante, porque es fácil sacar la conclusión equivocada. "Delegar sin control" no está mal en general. Hay tareas de bajo riesgo donde el costo de un error es trivial y revisar todo a mano no compensa. La decisión depende del riesgo, no de un principio absoluto. Lo que pasa es que en este caso de uso concreto siempre conviene controlar la extracción, porque el modelo puede equivocarse (y más todavía cuando, por privacidad, uno corre modelos locales más pequeños que los de la nube). Volveré sobre esto al final con un ejemplo que me pasó de verdad.

Y hay un requisito que atraviesa todo lo anterior: la privacidad por diseño. Un diagrama de arquitectura es información sensible. Mandarlo a una API en la nube para que lo analice significa sacarlo de la organización. Por eso, toda la inferencia de la PoC corre en local. Esa restricción es la que vuelve la pregunta del reparto todavía más aguda, porque los modelos locales pequeños son justamente los que más se benefician de esa supervisión humana con validación. 

Veamos cómo se ve esto en la práctica.

El caso de uso, paso a paso

El sistema se organiza en cuatro procesos secuenciales: extracción y validación (P1), identificación de amenazas (P2), recomendación de controles (P3) y generación del informe (P4). El punto de partida es una imagen de un diagrama de flujo de datos (DFD) de cajas y flechas. 

Figura 4: El diagrama de entrada del caso de estudio.

Nótese que el flujo hacia "Centralized Logs" va por HTTP en claro,

mientras que el resto va cifrado (ese detalle va a importar).

Para la evaluación usé un caso representativo: un frontend, dos microservicios, tres almacenes de datos y distintas configuraciones de seguridad de transporte, como se ve en el diagrama de la imagen anterior.

P1 — La IA extrae, el humano valida

Un modelo de visión local analiza el diagrama y devuelve un inventario inicial en formato JSON, es decir, componentes normalizados a una taxonomía acotada (`ExternalEntity`, `Process`, `DataStore`, `UI`, `API Gateway`, `Queue`) y flujos con sus atributos, incluido si el transporte va cifrado o claro.

Esta es la fase más frágil de todo el sistema, y conviene hablar con franqueza sobre el motivo. Los modelos generativos son probabilísticos. Pueden alucinar, devolver el JSON cortado a la mitad cuando la salida es larga, o tipificar un componente de una forma una vez y de otra a la siguiente. Buena parte del desarrollo fue destinada precisamente a domar esa variabilidad.

Por un lado, fijé la generación a `temperature = 0`, con `seed` fijo y muestreo restringido para favorecer la reproducibilidad. Por otro, evité el truncado de la respuesta y monté un mecanismo de reintento en el que, si el JSON no parsea o no valida contra el esquema, lanza un segundo intento de reparación y, si vuelve a fallar, corta con error explícito en vez de seguir con datos corruptos.

Pero ningún ajuste de parámetros elimina del todo la posibilidad de que el modelo se equivoque al interpretar el dibujo. Y aquí está lo que comentaba. En la primera extracción del caso de estudio, el modelo tipificó el `Frontend` como `Process`.

Figura 5: La extracción inicial del modelo de visión.

El `Frontend` aparece como `Process` (no como `UI`),

y el flujo de logs queda correctamente marcado como `Plain`.

El sistema todavía no permite continuar porque falta la validación.

No es un error catastrófico ni una alucinación grosera; es una interpretación razonable que, sin embargo, cambia el análisis porque un `Process` y una `UI` no tienen el mismo conjunto de categorías STRIDE aplicables. Si ese inventario pasara directo a las fases siguientes, generaría un conjunto de amenazas distinto del correcto y nadie lo notaría.

Por eso P1 termina en una instancia de validación humana obligatoria (human-in-the-loop, HITL). El sistema bloquea el acceso a las fases deterministas hasta que el analista revisa el inventario y confirma explícitamente que es correcto. La revisión se hace mediante un chat de comandos estructurados acotado a renombrar componentes y corregir sus tipos, y la confirmación se persiste en el artefacto de trabajo para dejar traza de que la validación ocurrió.

Figura 6: El inventario tras la corrección humana - el `Frontend` ahora es `UI`.

El checkbox de confirmación está marcado y recién entonces se habilita el botón

para continuar. Esa única corrección cambia las amenazas que se van a generar.

Este HITL no es un detalle de usabilidad, es la supervisión humana con validación que hace que tenga sentido usar un modelo generativo en P1. La IA aporta la velocidad de no transcribir el diagrama a mano y el humano aporta la garantía de que el análisis no arranca sobre una premisa equivocada. Ni el modelo solo, ni el humano transcribiendo todo a mano. Cada uno donde rinde.

P2 y P3 — El núcleo determinista, sin una sola línea de IA

Con el inventario validado como "contrato de entrada", arrancan las dos fases que no usan IA.

P2 recorre cada activo del inventario y, según su tipo, determina qué categorías STRIDE aplican mediante un mapeo fijo. Un `ExternalEntity` recibe `Spoofing` y `Repudiation`. Un `Process` recibe las seis categorías. Un `DataStore` recibe `Tampering`, `Repudiation` e `Information Disclosure`. Los flujos reciben `Tampering`, `Information Disclosure` y `Denial of Service`.  Por cada combinación "tipo de activo – amenaza STRIDE" aplicable se genera un escenario de riesgo, y se le estima una severidad combinando probabilidad e impacto en una escala de 1 a 5, con reglas que se apoyan en el tipo de activo y en señales del propio diagrama (por ejemplo, si un flujo va cifrado o en claro). La severidad sale de multiplicar ambos factores y se clasifica por umbrales que van de informativa a crítica.

P3 toma cada escenario priorizado y lo mapea a controles concretos mediante otra correspondencia determinista en la que cada par "tipo de activo – amenaza STRIDE" tiene asociados sus controles del catálogo local, y la severidad gradúa cuántos se recomiendan (más para los críticos, menos para los de baja severidad). Si una combinación no tiene entrada directa, hay un mecanismo de respaldo que también es determinista.

Lo importante no es el detalle de los mapeos, sino que toda esta lógica es conocida, estable y reproducible. No hay nada que "interpretar". Meter un modelo generativo aquí no resolvería ningún problema que las reglas no resuelvan ya, y a cambio reintroduciría justo la variabilidad que tanto trabajo costó sacar de P1. Para el caso de estudio, estas dos fases produjeron 44 escenarios de riesgo y 83 recomendaciones de control a partir de un catálogo de 15 controles únicos, siempre igual ante la misma entrada.

P4 — El informe, y la IA de vuelta, pero atada

La última fase consolida todo en un informe en Markdown con la arquitectura detectada, las amenazas clasificadas y el plan de mitigación. Acá la IA reaparece, pero en su tercer enfoque, como ayudante de redacción opcional. El sistema puede pedirle a un LLM local que mejore la prosa de las descripciones (impacto, mitigación, etcétera) para que el informe se lea mejor, pero con dos límites estrictos. 

Figura 7: El informe final. El inventario validado, las amenazas y los controles

quedan como tablas auditables. Los hallazgos técnicos son inmutables.

Primero, no puede alterar los hallazgos, de modo que el inventario, las amenazas y los controles que vienen del núcleo determinista permanecen intactos. Eso protege los datos, pero no la prosa, ya que el texto enriquecido es lenguaje libre y nada impide que el modelo afirme en una descripción algo que el inventario no dice. Por eso esa capa es prescindible y la versión sin enriquecer del informe sigue siendo la fuente de verdad.

Segundo, se hace amenaza por amenaza en vez de todo de una vez, porque pedirle al modelo que reescriba un bloque grande resultó frágil, y cualquier desvío de formato echaba a perder todo el lote. Si el enriquecimiento de un caso falla, el informe sale con el texto original y la ejecución no se interrumpe. Es la misma filosofía de P1 vista desde otra perspectiva. La IA puede ayudar a redactar, pero no a decidir. La fuente de verdad sigue siendo el inventario validado y los resultados deterministas.

La evidencia: dónde vive la variabilidad

Todo el argumento anterior se puede resumir en una sola tabla, que para mí es el resultado más contundente del trabajo. Ejecuté el pipeline varias veces sobre el mismo diagrama.

Figura 8: Tabla de Repetibilidad y variación controlada

(en las tres ejecuciones o runs: 7 componentes y 6 flujos).

Con la misma entrada y la misma validación humana,

el resultado es idéntico (Run 1 y Run 2). La diferencia

del Run 3 viene exclusivamente de una decisión distinta

en el punto de validación: dejar el `Frontend` como

`Process` en lugar de corregirlo a `UI`.

Las dos primeras ejecuciones son idénticas hasta el último número porque el núcleo determinista no fluctúa. La tercera difiere (47 escenarios en vez de 44, 92 recomendaciones en vez de 83) y la diferencia tiene una sola causa. En esa ejecución no se aplicó la corrección humana y el `Frontend` quedó como `Process`, que arrastra más categorías STRIDE. La variabilidad no aparece dispersa por todo el sistema, sino confinada al punto exacto donde decidí que viviera**, el HITL. 

Figura 9:  Ejecución de un proceso paso a paso

Esa es la prueba de que el reparto funciona. La parte que debe ser estable, lo es, y la que legítimamente depende del criterio humano está aislada y es trazable. En este vídeo dejo las capturas de una ejecución, una tras otra, como apoyo visual al recorrido descrito arriba.  

Una nota sincera sobre la fragilidad de los modelos

Hay un detalle que prefiero contar antes que esconder porque ilustra mejor que cualquier argumento por qué el HITL no sobra. Al preparar el material de este artículo, meses después de la evaluación original, volví a mirar las ejecuciones y el modelo de visión extraía los componentes de forma algo distinta a como lo había hecho la primera vez y yo no había tocado una sola línea de código. En ese lapso solo había habido actualizaciones de herramientas del entorno. No tengo una explicación cerrada de la causa exacta, y no voy a inventarla.

Pero el fenómeno, sea cual sea su origen, es exactamente la fragilidad que el trabajo documenta como limitación, esto es, que la salida de la fase generativa puede cambiar entre sesiones por motivos que están fuera del control del analista. Y ese es justamente el argumento a favor de no confiar ciegamente en ella. Si el comportamiento del modelo puede derivar con el tiempo aunque tu código sea idéntico, quieres un punto de control humano entre esa salida y todo lo que depende de ella. La fragilidad no es un contratiempo del proyecto, sino la mejor evidencia de por qué se diseñó así.

Qué queda fuera

Esto es una prueba de concepto, con su alcance acotado (aplicaciones web de tres capas, APIs y microservicios ligeros, partiendo de un DFD de cajas y flechas). No pretende ser una herramienta lista para producción. Aquí tienes el TFM completo publicado en Slideshare.

Figura 10:  Modelado de Amenazas Automatizado con Inteligencia Artificial,Validación Humana y Núcleo Determinista

Quedan muchas líneas abiertas por si a alguien le sirven de punto de partida, como la ampliación de la corrección humana a flujos y atributos, la validación de que la imagen de entrada sea realmente un DFD antes de procesarla, la incorporación de activos y amenazas propios de IA/LLM, o la conexión del sistema a bases de conocimiento (OWASP, NIST) vía RAG para justificar cada control con evidencia documental. El detalle de todo esto está en el TFM.

Conclusión

El modelado de amenazas funcionó aquí como el escenario idóneo para poner a prueba el concepto del reparto. Un mismo proceso puede, y a veces debe, alternar el uso de la IA generativa, es decir, emplearla en un paso, prohibirla en el siguiente y acotarla en el último. La decisión en cada etapa responde a dos preguntas pragmáticas: 

• ¿qué impacto tiene un error del modelo en esta instancia?
• ¿Puede resolverse este paso mediante reglas tradicionales?

Este pipeline situó a la IA donde aporta valor, interpretando imágenes bajo validación humana; la excluyó de donde solo hacen falta reglas conocidas, porque ahí solo agregaría ruido; y la incorporó como redactora del informe sin permitirle modificar un solo hallazgo. La tabla de repetibilidad muestra que este reparto se sostiene porque los componentes deterministas producen resultados idénticos en cada ejecución, y la única variabilidad se concentra, deliberadamente, en el punto de validación humana.

En definitiva, no he inventado nada espectacular; no obstante, la lógica de dónde poner cada cosa me parece que trasciende el caso del modelado de amenazas y por eso vale la pena insistir en ella.

Autor: Matias Daniel Ades

Figura 11: Contactar con Matias Daniel Ades

Referencias

Las referencias completas están en el TFM. Estas son las que más sostienen las ideas de este artículo.

• I. Elsharef, Z. Zeng y Z. Gu, *Facilitating Threat Modeling by Leveraging Large Language Models*, Workshop on AI Systems with Confidential Computing (AISCC), 2024.
• S. Berger et al., *Efficient and Extensible Security Analysis with Enhanced Data Flow Diagrams*, Proc. ESSoS, 2016.
• Microsoft, *Microsoft Threat Modeling Tool* (documentación técnica), 2022.
• OWASP, *Threat Dragon Documentation*.
• AWS, Accelerate threat modeling with generative AI (AWS Threat Designer), 2025.
• A. Crossman et al., *Auspex: Building Threat Modeling Tradecraft into an Artificial Intelligence-based Copilot, arXiv:2503.09586, 2025.
• E. Bandara et al., *ASTRIDE: A Security Threat Modeling Platform for Agentic-AI Applications*, arXiv:2512.04785, 2025.
• R. Troncoso, *Módulo 6. Seguridad de Aplicaciones y Desarrollo Seguro*, Máster en IA Aplicada a la Ciberseguridad, ENIIT & UCAM, 2025.
• S. Bai et al., *Qwen2.5-VL Technical Report*, arXiv:2502.13923, 2025.

Entornos de aprendizaje práctico en Seguridad Ofensiva con Metasploitable 2

La ciberseguridad no sólo se trata de comprender los ataques, sino de anticiparse a ellos. La mejor forma de hacerlo es mediante la práctica de ejercicios de ataque en entornos controlados, donde los profesionales pueden analizar, explotar y mitigar vulnerabilidades sin poner en riesgo sistemas reales. Los ejercicios de Red Team tan importantes para las empresas y los equipos.

Figura 1: Entornos de aprendizaje práctico en

Seguridad Ofensiva con Metasploitable 2

Por eso a los estudiantes del Máster en Seguridad Ofensiva del Campus Internacional de Ciberseguridad les incentivamos con ello, e incluso son parte de los Trabajos de Fin de Máster (TFM), como este de Jaime del Puerto.  

Figura 2: Contactar con Jaime del Puerto

Su proyecto se centró en el estudio y la explotación de vulnerabilidades en entornos de aprendizaje utilizando Metasploitable 2, una máquina virtual diseñada específicamente para probar herramientas y técnicas de hacking ético, que es básica para todos los futuros Pentesters & Red Teamers.

¿Qué es Metasploitable 2 y por qué es clave en Seguridad Ofensiva?

Metasploitable 2 es una máquina virtual vulnerable que permite a los profesionales de seguridad informática y a futuros pentesters practicar técnicas de explotación sin infringir la ley - que ya sabéis cómo es la legislación hoy en día con las pruebas de hacking en real -. 

Figura 3: Metasploitable 2

En este entorno se pueden analizar múltiples vectores de ataque, realizar pruebas de penetración y desarrollar estrategias de mitigación. Este entorno incluye:

• Sistemas con vulnerabilidades conocidas, desde servicios mal configurados hasta fallos en el software.

• Pruebas de explotación en un entorno seguro, sin afectar sistemas reales.

• Análisis de malware y técnicas de ataque para comprender cómo operan los ciberdelincuentes.

Lo que les pedimos a los alumnos es que trabajen esos entornos y lo documenten, tal y cómo se hace en los trabajos de pentesting en las empresas. En este caso, Jaime aprovechó este entorno para llevar a cabo un análisis detallado de diversas vulnerabilidades y demostrar cómo pueden explotarse en un escenario controlado, tanto para su aprendizaje, como para compartir con los demás.

El TFM de Jaime: Análisis de vulnerabilidades en Metasploitable 2

El trabajo de Jaime se enfocó en realizar un estudio técnico de las vulnerabilidades presentes en Metasploitable 2 y su aplicación en el aprendizaje de técnicas de seguridad ofensiva, para ayudar a otros a mejorar y aprender también. Sus principales objetivos fueron los de un informe completo hecho por un profesional, que es para lo que se hacen estos TFMs.

1. Análisis de visibilidad: Identificó aplicaciones y servicios vulnerables en la máquina virtual, evaluando los vectores de ataque más comunes utilizados por los ciberdelincuentes.

2. Búsqueda de vulnerabilidades: Utilizó herramientas especializadas como Nmap, Nessus y Metasploit Framework para detectar fallos de seguridad en los servicios expuestos.

3. Explotación de vulnerabilidades: Implementó ataques prácticos sobre los sistemas descubiertos, incluyendo la ejecución remota de código, escalada de privilegios y técnicas de evasión de detección.

4. Análisis de malware y persistencia: Examinó cómo los atacantes pueden mantener el acceso a un sistema comprometido, aplicando técnicas de backdoors y rootkits.

5. Identificación de contramedidas: Tras explotar las vulnerabilidades, Jaime propuso medidas de mitigación, desde configuraciones seguras hasta estrategias avanzadas de detección y respuesta a incidentes.

Figura 4: Metodologías de explotación

Conclusiones del TFM

El trabajo que hizo Jaime no hubiera sido suficiente con la explotación de fallos de seguridad - que es condición fundamental -, sino que tenía que aportar un enfoque educativo sobre cómo las organizaciones pueden fortalecer sus defensas aprendiendo de estos escenarios y manteniendo a sus equipos de ciberseguridad entrenados constantemente. Sus conclusiones destacaron:

• La importancia de los entornos de aprendizaje como Metasploitable 2 en la formación de expertos en seguridad ofensiva.

• La necesidad de mantener una monitorización activa para detectar intentos de explotación de vulnerabilidades.

• La relevancia de la formación en pentesting para comprender cómo piensan y actúan los atacantes.

¿Qué aporta el Máster en Seguridad Ofensiva?

El ejemplo de Jaime es un claro reflejo del enfoque práctico del Máster en Seguridad Ofensiva del Campus Internacional de Ciberseguridad. Este programa, impartido por profesionales de esta profesión, proporciona un entrenamiento intensivo en técnicas de hacking ético, pruebas de penetración y análisis de vulnerabilidades.

Figura 5: La 11º edición comienza el 25 de marzo

Con herramientas reales y escenarios de ataque controlados, los alumnos adquieren las habilidades necesarias para enfrentarse a las amenazas más sofisticadas del sector. La 11º edición comienza el 25 de marzo, si quieres convertirte en profesional de este área tan bonita como es la seguridad ofensiva. 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

El poder de la formación: Cómo crear una herramienta de escaneo para GNU/Linux

El aprendizaje teórico es solo el inicio, el verdadero valor de la formación en ciberseguridad se alcanza cuando llevamos ese conocimiento a la práctica, adaptándolo a problemas reales del mundo tecnológico. Y los Trabajos de Fin de Curso/Carrera (TFC), Trabajos de Fin de Grado (TFG), o como hoy, un Trabajo de Fin de Máster (TFM) del Máster de Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad, son una oportunidad fantástica.

Figura 1: El poder de la formación. Cómo crear

una herramienta de escaneo para GNU/Linux

En mi caso particular he aprovechado todos esos trabajos para avanzar las investigaciones que estaba llevando a cabo, y usarlos en mi vida personal. Mi Trabajo de Fin de Carrera de la Ingeniería Técnica de Informática de Sistemas en la UPM fue la implementación nLog(n) de un algoritmo para calcular de un par de puntos de una nube dada. En el Trabajo de Fin de Grado de la Ingeniería de Informática en la URJC se lo dediqué a las técnicas de Time-Based Blind SQL Injection Using Heavy Querys y el Trabajo de Fin de Máster de mi Máster en Tecnologías de la Información y Sistemas Informáticos de la URJC a las técnicas de LDAP Injection y Blind LDAP Injection.

Ver esta publicación en Instagram

Una publicación compartida de Chema Alonso (@chemaalonso)

Todos ellos me sirvieron profesional para mucho, pero también para luego hacer mi Doctorado con el análisis y modelado de algoritmos para detectar ataques explotados a ciegas, que aunaba y recolectaba todo el trabajo que había hecho antes. Cuando haces una formación, lo importante no es el título, sino el aprovechamiento que sacas de ella, y yo os garantizo que he aprovechado todos los trabajos para hacer cosas chulas. Y por eso hoy quiero compartir con vosotros el TFM de Víctor Laguna Bandrés, alumno de la primera edición del Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad.

Figura 3: Contactar con Victor Laguna Bandrés

Este máster es para personas que empiezan desde cero, así que su proyecto era un desafío clave para él y algo fundamental en el ámbito de la seguridad de sistemas GNU/Linux. En este caso la creación de una herramienta propia para escanear y analizar la arquitectura de máquinas GNU/Linux. Este proyecto era para no sólo demostrar su capacidad técnica, sino también de visión, ya que un buen profesional de ciberseguridad puede y muy a menudo tiene que crear soluciones nuevas que mejoren la herramientas de seguridad con las que se cuenta.

El reto del escaneo en arquitecturas GNU/Linux

Las arquitecturas GNU/Linux se han convertido en uno de los sistemas operativos más utilizados tanto en entornos empresariales con en Internet como en servidores de muchos de los servicios digitales que se consumen o publican en la red.

A medida que las amenazas evolucionan, la capacidad de evaluar la seguridad de estos sistemas en tiempo real también debe hacerlo. El escaneo de arquitecturas GNU/Linux es crucial para detectar vulnerabilidades, identificar brechas de seguridad y proteger las infraestructuras.

Por supuesto, existen infinidad de herramientas, y algunas de ellas muy conocidas para estas tareas como Nmap, OpenVAS y Lynis, que realizan escaneos para detectar vulnerabilidades y mejorar la seguridad de las máquinas GNU/Linux.

Sin embargo, a pesar de la eficacia de estas soluciones, con este proyecto se quería unificar las funcionalidades más potentes de estas herramientas en una única plataforma que permita personalizar los escaneos en función de las necesidades específicas de cada entorno.

El TFM: Creación de una herramienta de escaneo de arquitecturas GNU/Linux

El objetivo del TFM de Víctor Laguna Bandrés era desarrollar una herramienta integral para el escaneo de arquitecturas en máquinas GNU/Linux, utilizando las mejores características de las herramientas existentes, pero combinadas en un solo sistema y adaptadas a las necesidades de proyectos futuros. A continuación, destaco algunos de los aspectos técnicos del trabajo:

• Selección de la tecnología adecuada: Este trabajo se realizo en Python debido a su versatilidad, facilidad de implementación y capacidad de escalabilidad. Esta elección permite diseñar una herramienta flexible que pueda ajustarse a diferentes requisitos de escaneo y adaptarse fácilmente a futuros desarrollos.

Figura 4: Libros de Python para Pentesters y Hacking con Python
de Daniel Echeverri publicados en 0xWord.

• Escaneo de características de fortificación: La herramienta realiza un análisis exhaustivo de diversas características críticas en la fortificación de cualquier máquina GNU/Linux. Esto incluye la obtención de información sobre usuarios y grupos (pwd y grp), la verificación de permisos en directorios sensibles (os.stat()), y la identificación de módulos y drivers cargados en el sistema mediante lsmod y modinfo. Además, se escanea la versión del Kernel para detectar vulnerabilidades conocidas a través de /proc/version.

Figura 5: El TFM está hecho en python3

• Red y dispositivos conectados: En este trabajo se implementa un escaneo de red utilizando herramientas como ifconfig, netstat y lsof, y también se realiza una identificación de puertos abiertos y dispositivos conectados. Esto se complementó con un análisis de las configuraciones de la red y las interfaces de acceso mediante sockets en Python.

Figura 6: Fichero main.py

• Escaneo de recursos y configuración del sistema: La herramienta permite evaluar el uso de recursos como la memoria RAM, los discos duros y la configuración del cortafuegos. Utiliza psutil para obtener datos sobre el sistema, garantizando que los recursos estén configurados de manera segura.

Conclusiones del TFM

Este TFM no sólo está enfocado en demostrar conocimientos para dar una solución técnica que puede ser requerida en un puesto profesional de ciberseguridad en un momento dado, sino también una visión pragmática sobre cómo mejorar la seguridad de un sistema GNU/Linux de una manera práctica y útil para una empresa en un momento dado. La herramienta creada no es solo un ejercicio académico; es una solución práctica que puede ser utilizada para reforzar la seguridad en entornos reales como lo haría cualquier profesional de ciberseguridad.

Figura 7: 7 libros de 0xWord en el Máster de Fundamentos de Ciberseguridad

Lo que se busca con estos proyectos, es que los alumnos de un Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad cuando hagan el TFM lo hagan pensando en su futuro como profesionales de ciberseguridad, y en este caso concreto, en cómo su herramienta se puede seguir adaptando y mejorando con el tiempo, lo que refleja lo que se busca con esta formación, que es preparar a los estudiantes no sólo para enfrentar los retos de ciberseguridad de hoy, sino para anticiparse a los del mañana.

¿Qué aporta el Máster en Fundamentos de Ciberseguridad?

El TFM de Víctor Laguna Bandrés no es por casualidad, el Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad ofrece una formación integral en los pilares de la seguridad informática, brindando a los alumnos las herramientas necesarias para desarrollar proyectos técnicos como el de hoy comenzando desde cero, para que lo puedan aplicar en una carrera profesional en ciberseguridad.

Figura 8:  Máster en Fundamentos de Ciberseguridad

del Campus Internacional de Ciberseguridad 

Además, con un enfoque netamente práctico, este máster permite a los estudiantes enfrentarse a problemas reales del trabajo en cibeseguridad y construir soluciones que marquen la diferencia. Si estás interesado en iniciarte en el apasionante mundo de la ciberseguridad pero empiezas casi desde cero, el Máster en Fundamentos de Ciberseguridad del Campus Internacional de Ciberseguridad te proporciona una base sólida, impartida por profesionales de reconocido prestigio, y con el respaldo de una escuela de negocios líder en el sector.

Figura 9: 7ª Edición del Máster Online de Fundamentos de Ciberseguridad.

Reserva de plazas para Marzo 2025

Si quieres adquirir los conocimientos y habilidades para proteger sistemas críticos y desarrollar proyectos innovadores en ciberseguridad, puedes reservar una de las plazas que quedan libres en la 7º edición del Máster en Fundamentos de Ciberseguridad que comienza elpróximo 25 de marzo y formar parte de una comunidad de expertos que están construyendo su futuro en el mundo profesional de la seguridad informática.

Figura 10: Estudio personalizado de Singularity Hackers en

el Máster de Fundamentos de Ciberseguridad 

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)