/ Proyectos / Ciberseguridad / Enriquecimiento cross-domain con embeddings de comportamiento
Detección de anomalías en redes: enriquecimiento cross-domain con autoencoders adversariales
Cómo enriquecer tráfico de red con embeddings de comportamiento de usuario, mediante autoencoders adversariales, cuando no tienes suficientes datos de comportamiento etiquetados.
El objetivo era detectar tráfico de red anómalo a partir de un dataset público de eventos etiquetados, normal o ataque. El problema real no era técnico, era de contexto: un modelo entrenado solo con features de tráfico llegó a 100% de accuracy en validación. Eso no se sintió como un logro, se sintió como una alerta.
Un accuracy perfecto en un problema de seguridad rara vez significa que el modelo entendió el problema. Casi siempre significa que memorizó el dataset. La pregunta dejó de ser "¿cómo subo la métrica?" y pasó a ser "¿cómo obligo al modelo a aprender algo que no pueda memorizar?". La respuesta fue enriquecer cada registro de tráfico con contexto de comportamiento de usuario, un dominio de datos completamente distinto, sin correspondencia etiquetada entre ambos.
Mapa del casoContenido
- Diagrama de la solución. Los bloques del pipeline, de las dos fuentes de datos a la predicción final
- Construcción de la solución. Cómo un accuracy sospechosamente perfecto dirigió cada decisión
- Condiciones del proyecto. Restricciones reales y opciones descartadas antes de construir
- Pasos. Qué se dejó al agente y qué criterio se aplicó en cada uno
- Proceso de iteración. El hallazgo que obligó a cambiar cómo se medía el éxito
- Descargables. Notebook, diagrama y repositorio del proyecto
- Lecciones importantes. La lección concreta que deja este caso
Estructura de alto nivelDiagrama de la solución
Pasa el cursor sobre cada bloque para ver qué hace ese paso. El bloque punteado naranja es el mecanismo adversarial.
El discriminador nunca ve las etiquetas de normal/anómalo, solo aprende a distinguir de qué dominio (tráfico o comportamiento) viene cada embedding. Ese único mecanismo adversarial es lo que fuerza la alineación entre dos espacios de datos que, de otra forma, no tendrían nada en común.
Cómo se construyóConstrucción de la solución
Condiciones del proyecto
| Restricción | Dato |
|---|---|
| Objetivo inicial | Prueba de concepto técnica, no exigía llevar el modelo a producción |
| Datos de tráfico | Público y etiquetado (normal/ataque), pero sin ningún contexto sobre el usuario que lo generó |
| Datos de comportamiento | Solo un grupo reducido y controlado de usuarios monitoreados por ventanas cortas de tiempo, sin representar a escala poblacional |
| Correspondencia entre dominios | Ninguna: no existe un id de usuario compartido entre el tráfico y los perfiles de comportamiento |
| Opción | Por qué se descartó |
|---|---|
| Etiquetar manualmente qué usuario generó cada evento de tráfico | No hay forma confiable de reconstruir esa correspondencia, y no escala |
| Usar solo el promedio del perfil de comportamiento como enriquecimiento global | Le da el mismo contexto a todos los registros, no aporta variabilidad real |
| Confiar en el accuracy final para decidir si la técnica funciona | Es justo la métrica que ya había dado una señal falsa de éxito con el baseline |
| Alineación adversarial de dominios (autoencoders + discriminador) + emparejamiento por similitud coseno instancia a instancia | Da contexto específico a cada registro sin necesitar correspondencia etiquetada entre dominios |
Pasos
Representación del comportamiento de usuario
Agente: propuso aplicar K-means directamente sobre los vectores crudos de frecuencia de uso por servicio.
Criterio aplicado: reducir primero a un espacio latente de 2D con un autoencoder antes de agrupar. El clustering directo sobre datos crudos (K-means, DBSCAN, jerárquico) daba silhouette scores mediocres o incluso negativos; el híbrido autoencoder + clustering jerárquico subió el silhouette de ~0.50 a ~0.86.
Alineación de dos dominios sin correspondencia real
Agente: sugirió simplemente concatenar el perfil de comportamiento promedio a todos los registros de tráfico.
Criterio aplicado: entrenar autoencoders adversariales, uno por dominio, con un discriminador que fuerza a que ambos espacios latentes compartan geometría, y luego emparejar cada registro de tráfico con su perfil más similar por coseno, en vez de un promedio fijo.
Cómo decidir si el enriquecimiento realmente ayuda
Agente: tendía a reportar solo el accuracy final del modelo enriquecido, sin comparación.
Criterio aplicado: diseñar un experimento de ablación con la misma arquitectura, con y sin enriquecimiento, e interpretar la dinámica de entrenamiento (velocidad de convergencia, brecha train/validación), no solo la métrica final, porque un 100% de accuracy ya había demostrado ser una señal engañosa.
Validar que el resultado no fuera un golpe de suerte del split
Agente: reportó las métricas de un único train/test split como resultado final.
Criterio aplicado: correr validación cruzada estratificada (5 folds) sobre el dataset enriquecido y confirmar la estabilidad de accuracy, precisión, recall y F1 entre folds, antes de aceptar el resultado como confiable.
Proceso de iteración
Ajuste documentado, no forzado
La expectativa inicial era que el enriquecimiento subiera el accuracy por encima del baseline de solo-tráfico. Ocurrió lo contrario: el modelo enriquecido cerró en 97.17% de accuracy, mientras que el baseline llegó a 100%. En vez de descartar el enfoque, se analizó por qué. El baseline convergía a pérdida casi cero en menos de 10 épocas, con las curvas de entrenamiento y validación pegadas, el patrón clásico de memorización. El modelo enriquecido necesitó más de 30 épocas para converger, mantuvo una brecha pequeña pero constante entre pérdida de entrenamiento y validación, y su distribución de errores quedó balanceada entre falsos positivos y falsos negativos. El mismo patrón se repitió al validar contra un segundo dataset público de tráfico, distinto en distribución y tipos de ataque: el baseline volvió a llegar a 100%, el modelo enriquecido a 99.93%, con la misma brecha sostenida. Una métrica más baja, pero con evidencia de generalización real, terminó siendo el resultado más honesto del proyecto.
CierreLecciones importantes
La lección central no fue de arquitectura, fue de criterio: cuando un resultado se ve demasiado bien, la pregunta correcta no es cómo mantenerlo, es qué está escondiendo. Un accuracy perfecto en un problema de seguridad casi nunca es una victoria, es una pista de que el modelo encontró el camino más fácil, no el más útil.
Herramientas como los modelos de lenguaje ayudan a explorar ideas ya documentadas, pero no reemplazan entender el propio problema. La decisión de desconfiar del 100% de accuracy, y de diseñar un experimento de ablación para probarlo, no salió de pedirle ideas a una IA: salió de conocer las circunstancias reales del proyecto, los datos disponibles y sus límites, y de ahí proponer algo que respondiera a ese contexto específico.
Si quieres ver un enfoque publicado con una idea similar, alineación de dominios con estructura de clustering aplicada a detección de intrusos, este paper reciente es una buena referencia del nivel de la contribución: Clustering-Enhanced Domain Adaptation for Cross-Domain Intrusion Detection in Industrial Control Systems.
Termina ya tu proyecto
¿Tienes un proyecto similar y no sabes por dónde empezar? Yo te ayudo a diseñarlo.
El 92% de los profesionales de datos desbloquea sus proyectos al ver ejemplos completos resueltos.
Sin registro. Acceso inmediato