El TFG de ciberseguridad tiene una trampa que ningún otro trabajo de Informática comparte: la mitad de lo que te enseñan a hacer —escanear, explotar vulnerabilidades, capturar tráfico— es delito si lo haces contra un sistema que no es tuyo. La diferencia entre un TFG brillante y un problema con la ley no está en la técnica, está en dónde la aplicas. Esta guía explica cómo montar el laboratorio, dónde están los límites legales en España y de qué datasets públicos puedes tirar para no tener que atacar nada real.

La regla de oro: tu laboratorio, tus reglas

Todo lo que hagas —análisis de malware, pentesting, fuzzing, ataques de red— ocurre en un entorno controlado y aislado que tú controlas por completo: máquinas virtuales en tu equipo, una red interna sin salida, o servicios diseñados para ser atacados legalmente. Nunca contra sistemas de terceros, ni siquiera «para probar», ni siquiera si parecen abandonados.

Esta no es una recomendación de estilo: es la línea que separa un trabajo académico de un tipo penal. El artículo 197 bis del Código Penal castiga con prisión a quien, «vulnerando las medidas de seguridad establecidas para impedirlo, y sin estar debidamente autorizado, acceda o facilite a otro el acceso» a un sistema de información, y también a quien intercepte transmisiones no públicas de datos. El artículo 264 castiga el daño a datos, programas o documentos informáticos ajenos. La palabra que te protege aparece en ambos: autorización. En tu laboratorio, el titular del sistema eres tú, así que la autorización existe por definición.

Cómo montar el laboratorio

El montaje mínimo para casi cualquier TFG ofensivo o defensivo:

1. Hipervisor (VirtualBox, VMware, KVM…) sobre tu equipo, con varias máquinas virtuales.
2. Una máquina atacante con las herramientas de análisis y una o varias máquinas víctima deliberadamente vulnerables.
3. Red interna aislada (host-only o internal), sin NAT ni puente a tu red doméstica. Si necesitas descargar algo, lo haces y vuelves a aislar.
4. Snapshots antes de cada experimento, para volver a un estado limpio y hacer el trabajo reproducible.

Para las víctimas, no hace falta que ataques a nadie: existen máquinas y aplicaciones creadas expresamente para ser vulneradas con fines didácticos (aplicaciones web deliberadamente inseguras, imágenes de máquinas vulnerables, retos de plataformas de entrenamiento que autorizan explícitamente su explotación). Usa esas, documenta su procedencia y su licencia, y tendrás objetivos legales con vulnerabilidades conocidas y reproducibles.

Las cinco familias de TFG de ciberseguridad

• Ofensivo (pentesting). Auditoría de una máquina o aplicación vulnerable de laboratorio, siguiendo una metodología reconocida y documentando cada fase.
• Defensivo (blue team). Detección de intrusiones, análisis de logs, reglas de correlación, respuesta a incidentes sobre tráfico o eventos simulados.
• Análisis de malware. Estático y dinámico, en un entorno aislado y con muestras obtenidas de repositorios académicos, nunca ejecutadas fuera de la sandbox.
• Detección con aprendizaje automático. Modelos entrenados sobre datasets públicos de tráfico o de intrusiones para clasificar ataques.
• Estudio o comparación de herramientas/técnicas. Evaluación metodológica de defensas, cifrados, protocolos o herramientas, con criterios explícitos.

Las tres últimas familias son especialmente cómodas para un TFG con calendario ajustado, porque no dependen de montar un laboratorio ofensivo completo: se sostienen sobre datasets ya publicados.

Datasets públicos: investigar sin atacar nada

Buena parte de la investigación en detección de intrusiones y malware se hace sobre conjuntos de datos publicados por instituciones académicas. Para un TFG de detección o de aprendizaje automático, son tu materia prima:

• Datasets de instituciones de ciberseguridad (por ejemplo, los publicados por el Canadian Institute for Cybersecurity de la Universidad de New Brunswick): capturas de tráfico etiquetado con distintos tipos de ataque, pensadas para entrenar y evaluar detectores. Comprueba siempre la licencia y las condiciones de uso académico antes de descargar y cita el dataset con su versión.
• Repositorios de muestras de malware para investigación, de acceso restringido a fines académicos: se manejan solo dentro de la sandbox aislada.
• Recursos oficiales de referencia: el INCIBE (Instituto Nacional de Ciberseguridad, con sede en León) publica guías, avisos y materiales que sitúan tu trabajo en el contexto español y sirven como fuente de marco.

Tres reglas con estos datos: verifica la licencia, cita el dataset como conjunto de datos (organismo, versión, fecha) siguiendo la mecánica de cómo citar un dataset en APA 7, y describe sus limitaciones (un dataset de tráfico de hace años puede no representar los ataques actuales, y eso se discute).

Una precisión que evita sustos: el marco legal protege tu trabajo en laboratorio, pero no cubre automáticamente cualquier técnica por el hecho de aplicarla con fines académicos. El Código Penal castiga incluso la fabricación o facilitación de programas concebidos principalmente para cometer estos delitos —el artículo 197 ter menciona expresamente los programas y las contraseñas de acceso— cuando existe intención de facilitar la comisión de un delito. La lección para tu TFG es doble: primero, mantén todo dentro del entorno controlado y decláralo; segundo, si tu trabajo produce una herramienta ofensiva, enmárcala en su finalidad defensiva y de investigación, y no la publiques como un producto listo para atacar. La diferencia entre investigar una técnica y armar a un atacante está en el contexto, la intención y la documentación, y esos tres los controlas tú.

La memoria técnica: cómo se estructura

Un TFG de ciberseguridad es, en el fondo, un TFG de Informática, y su memoria comparte el esqueleto de cualquier proyecto técnico —control de versiones, documentación del código, defensa con demo— descrito en los temas de TFG de Ingeniería Informática. Lo específico que no puede faltar:

1. Descripción del entorno de laboratorio: topología, máquinas, aislamiento. Reproducibilidad total.
2. Consideraciones legales y éticas: apartado explícito declarando que todo se hizo en entorno propio y aislado, con referencia al marco penal. Esto no es relleno: es lo que blinda tu trabajo.
3. Metodología: la que uses (una metodología de pentesting reconocida, un pipeline de aprendizaje automático), citada y aplicada de verdad.
4. Resultados y evaluación: métricas, no impresiones. En detección, precisión, recall y falsos positivos; en pentesting, vulnerabilidades encontradas y su severidad.

Si en algún momento tu trabajo implicara datos de personas reales (por ejemplo, una encuesta sobre hábitos de seguridad), entra en juego el circuito de ética y protección de datos que describe la guía de investigación con sujetos humanos; el laboratorio técnico no lo exime.

Errores que se repiten (y alguno que sale caro)

• Probar «solo un escaneo» contra un sistema real. Un escaneo de puertos no autorizado ya es problemático; no lo hagas ni contra tu universidad ni contra una web cualquiera.
• Laboratorio con salida a internet. Una máquina víctima comprometida y conectada a la red puede convertirte en origen de un ataque real.
• Malware fuera de la sandbox. Ejecutar una muestra en tu equipo anfitrión es un accidente esperando ocurrir.
• Datasets sin licencia ni cita. Descargar un conjunto de datos de cualquier sitio y no declarar procedencia ni condiciones de uso.
• Resultados sin métricas. «El modelo detecta bien los ataques» no es un resultado; una matriz de confusión sí.
• Omitir el apartado legal. Un TFG ofensivo sin declaración explícita de entorno controlado deja al tribunal —y a ti— en una posición incómoda.

Del laboratorio al documento terminado

Montar el entorno y ejecutar los experimentos es la parte que dominas. El atasco llega al redactar una memoria técnica que documente el laboratorio de forma reproducible, justifique la metodología y presente resultados con métricas, sin olvidar el apartado legal que sostiene todo lo demás.

Empieza tu TFG en Tesify con tus capturas, tus métricas y tu topología delante, y construye la memoria sección a sección. La técnica la pones tú; la redacción deja de frenarte.

Preguntas frecuentes

¿Es legal hacer pentesting para un TFG?

Sí, siempre que lo hagas contra sistemas de tu propiedad o expresamente diseñados y autorizados para ser atacados (máquinas vulnerables de laboratorio, plataformas de entrenamiento con permiso explícito). Contra sistemas de terceros sin autorización, no: el acceso no autorizado y el daño a datos están tipificados en el Código Penal.

¿Necesito permiso de mi universidad para montar el laboratorio?

Para un laboratorio virtual en tu propio equipo, normalmente no. Si vas a usar infraestructura de la universidad o auditar sus sistemas —aunque sea con buena intención— necesitas autorización expresa y por escrito de quien corresponda.

¿De dónde saco muestras de malware para analizar?

De repositorios académicos de acceso restringido a investigación, y siempre manejadas dentro de la sandbox aislada. Nunca de adjuntos reales ni de fuentes dudosas, y jamás ejecutadas en tu equipo anfitrión.

¿Puedo hacer el TFG sin montar un laboratorio ofensivo?

Sí: las líneas de detección con aprendizaje automático, análisis de datasets de tráfico o comparación de herramientas se sostienen sobre datos ya publicados y no requieren atacar nada. Son además las más rápidas de arrancar.

¿Cómo cito un dataset de ciberseguridad?

Como conjunto de datos: institución responsable, nombre y versión del dataset, y fecha de consulta, respetando además su licencia de uso. Muchos datasets académicos piden citar un artículo concreto; hazlo.

¿Qué pasa si encuentro una vulnerabilidad real durante el TFG?

Si la encuentras por accidente en un sistema de terceros, no la explotes ni la publiques: existen cauces de divulgación responsable. Tu TFG se hace en laboratorio; hallazgos fuera de él se comunican por los canales adecuados, no se convierten en material del trabajo sin autorización.