Saltar al contenido

Temas

Auditoría de exposición y detección

Método de cinco fases para revisar tu propia exposición de IA (pasivo, activo, huella, metadatos, suministro), qué huella dejan esas actividades en los logs y las ocho correcciones de mayor impacto.

IntermedioEn progreso 6 min de lectura1 oct 2026#reconocimiento#auditoria#deteccion#siem#quick-wins#hugging-face#mitre-atlas

Esta nota cierra la sección. Junta lo anterior en un proceso que ejecutas contra tu propia organización, con alcance escrito, y lo mira por los dos lados: qué descubrirías tú y qué rastro dejaría en los logs de quien defiende. Aprender a ver tu actividad como la ve el defensor te hace mejor en ambos papeles.

Cinco fases de auditoría#

  1. Pasivo: qué ya es público. Sin tocar la red, comprueba qué ve un tercero.

    • Buscadores de dispositivos (Shodan, Censys, FOFA) sobre tus rangos y dominios, buscando banners de servicios de IA.
    • Tus repositorios y los de tu equipo: secretos de ML en ficheros de entorno, tokens y cadenas de conexión a MLflow. Usa un escáner de secretos en lugar de buscar a mano.
    • Publicaciones técnicas, papers, imágenes públicas en registros de contenedores y ofertas de empleo: cuentan qué frameworks usas (ATLAS AML.T0000, Search for Victim’s Publicly Available Research Materials).

  2. Activo: qué escucha. Barrido dirigido de los puertos de la tabla de referencia sobre tus rangos, con detección de versión. Revisa por separado los puertos gRPC (8001, 8500), que el escáner suele etiquetar de forma genérica, y los puertos de métricas.

  3. Huella: qué es cada cosa. Para cada puerto abierto, aplica las cinco señales de la nota de huella y enumeración: cabeceras, forma del JSON, errores, nombres de endpoint y gRPC/TLS. Apunta qué servicios responden 200 sin credenciales.

  4. Metadatos: qué cuentan. Para cada servicio confirmado, mira qué revela cada API de gestión (ver enumeración): esquemas, listados, versiones de modelos, notebooks. El objetivo es medir la fuga, no usarla: registra lo que sale y cierra.

  5. Suministro: de dónde viene todo. Orígenes de descarga de modelos en configuraciones y logs de build; buckets de artefactos (S3, GCS, MinIO) con lectura pública; nombres internos de paquetes sin reservar en el índice público; registros de contenedores que permiten pull sin credenciales.

Herramientas útiles por fase: buscadores de dispositivos (1), nmap con scripts NSE y grpcurl (2), curl y fuzzers de rutas con una lista propia de endpoints de IA (3), el cliente de tu plataforma de ML (4), y un escáner de plantillas como Nuclei para detectar malas configuraciones conocidas (2-3).

Tu actividad vista desde el SIEM#

Todo lo anterior deja firma. Estas son las que merece la pena tener como reglas:

Patrón Cómo se ve Por qué es sospechoso
Enumeración de modelos Ráfaga de 10-50 GET al mismo endpoint de listado desde un único origen en pocos segundos. Nadie consulta el listado de modelos así.
Acceso scripteado a MLflow Llamadas a la API de modelos registrados y versiones sin sesión de interfaz web asociada (sin cookies ni peticiones de recursos de la UI). La UI genera sesión y tráfico adicional; el API crudo indica automatización.
Lectura de métricas desde fuera Peticiones a /metrics desde IP fuera del CIDR del monitor. Tu Prometheus tiene IP conocida; cualquier otra es reconocimiento.
Escaneo con perfil de IA Sondeos secuenciales a 5000, 8000, 8001, 8080, 8265 y 8888 desde el mismo origen. No es un barrido aleatorio: es la lista de puertos de la fase 2.
Recorrido de rutas en artefactos Peticiones con ../ o %2e%2e%2f contra endpoints de artefactos. Intento de salir del directorio de artefactos; relacionado con CVE publicados de MLflow.
Jupyter sin sesión /api/kernels o /api/contents sin cookie de sesión válida. Alguien encontró el servidor, o una herramienta lo está enumerando.
regla de ejemplo (pseudocódigo)
evento: http_request
  donde ruta en ["/v2/models", "/v1/models", "/api/tags", "/collections"]
  agrupar por: ip_origen, ventana 10 s
  alertar si: cuenta >= 10 y no existe sesión UI asociada

Ocho correcciones de mayor impacto#

  1. Autenticación en MLflow (usuario y contraseña del producto, o proxy inverso autenticador). No expongas el 5000 sin ella.
  2. Jupyter: sin --ip=0.0.0.0 ni --allow-root en producción, con token. Nunca en 0.0.0.0 sin VPN o autenticación en el ingress.
  3. Perímetro: bloquea los puertos de IA (5000, 8000-8002, 8080, 8265, 8500/8501, 8888, 9000) de cara a internet salvo decisión explícita.
  4. Triton: modo de control de modelos desactivado en producción (--model-control-mode none) para impedir cargar y descargar modelos sin autenticación.
  5. Métricas: /metrics solo accesible desde el CIDR de monitorización; revelan nombres de modelo, uso de GPU, lotes y topología.
  6. Tokens de Hugging Face: rotarlos y usar tokens de grano fino, solo lectura y alcance mínimo.
  7. Respuestas: quita cabeceras de depuración y errores detallados antes de que lleguen a redes no confiables.
  8. Almacenamiento: revisa políticas de MinIO y S3 de artefactos; los pesos nunca en buckets de lectura pública.

La mayoría son cambios de unas horas, y cada uno elimina un tipo entero de hallazgo de las fases anteriores. Para el hardening en profundidad, ver el modelado de amenazas de IA y los controles en AWS.

Caso: Hugging Face Spaces (junio de 2024)#

En junio de 2024 hubo acceso no autorizado a la plataforma Spaces de Hugging Face, y se accedió a secretos de autenticación que los desarrolladores guardaban en sus aplicaciones alojadas, entre ellos tokens de HF capaces de abrir modelos, datasets y configuraciones privadas. Hugging Face respondió revocando los tokens comprometidos, recomendando migrar a tokens de grano fino con alcance mínimo y desaconsejando guardar tokens en los secretos de las aplicaciones.

Es la conexión con las fases 1 y 5: el tipo de credencial que aparece en un fichero de entorno público o en un log de CI/CD es el mismo que se pierde en una brecha de plataforma. Rotar y acotar tokens es a la vez la contramedida al reconocimiento y a la exposición por brecha: un token con alcance mínimo y caducidad limita lo que sirve después de la filtración.

Tu turno#

Tu turno

Ejecuta tu propia auditoría

Elige un entorno de laboratorio o un proyecto con alcance claro y completa las cinco fases en una hoja:

  1. Fase 1: ¿qué encuentras de ti mismo sin tocar la red? Lista tres cosas.
  2. Fases 2-3: tabla de host:puerto, producto y si responde sin credenciales.
  3. Fase 4: de cada servicio abierto, qué dato sensible devuelve.
  4. Fase 5: orígenes de modelos, buckets y paquetes internos.
  5. Para cada hallazgo: técnica ATLAS, corrección de la lista de ocho y la regla de detección que lo vería.

Reto

¿Por dónde empiezo si solo tengo una tarde?

▸Mostrar solución

Fase 1 sobre tus propios rangos y repositorios (gratis y sin riesgo), luego la fase 2 contra los puertos de IA. En la mayoría de organizaciones esas dos fases ya producen la lista de cierre urgente: servicios sin autenticación en un puerto público y un secreto en un repositorio.

En resumen#

  • La auditoría tiene cinco fases: pasivo, activo, huella, metadatos, suministro; las cuatro últimas solo con alcance.
  • Cada actividad tiene firma en logs: ráfagas de listados, API de MLflow sin sesión UI, /metrics desde fuera, escaneos de puertos de IA, ../ en artefactos y Jupyter sin sesión.
  • Ocho cambios rápidos (autenticación, Jupyter, perímetro, Triton, métricas, tokens, errores, buckets) eliminan la mayoría de los hallazgos.
  • La brecha de Hugging Face Spaces demuestra que tokens acotados y rotados protegen frente al reconocimiento y frente a la brecha de plataforma.
  • Mapea cada hallazgo a ATLAS, empezando por AML.T0000 en la fase pasiva.

Referencias#

Notas relacionadas

Mapa de la infraestructura de IA

Qué componentes tiene un despliegue de IA (servidores de modelos, MLOps, bases vectoriales, registros, notebooks), en qué puertos escuchan y por qué un escaneo clásico no los reconoce.

Huella y enumeración de APIs de IA

Cómo identificar qué framework de IA hay detrás de un puerto (cabeceras, forma del JSON, errores, endpoints, gRPC/TLS) y qué revela cada API sin autenticación: modelos, esquemas vectoriales, experimentos, métricas y notebooks.

Configuraciones inseguras, suministro y ATLAS

Qué configuraciones por defecto de plataformas de ML convierten un despliegue en objetivo de reconocimiento, por qué el registro de modelos y la cadena de suministro son críticos, y cómo mapear todo a MITRE ATLAS.

Cadena de pivotes y defensa del reconocimiento

Cómo un notebook abierto lleva a MLflow, al registro y al bucket de modelos, y qué controles (inventario, autenticación, segmentación, secretos, detección) cortan la cadena.

ESC
↑↓ para navegar↵ para abriresc para cerrar