Postura crítica

Universidad de la Amazonia

Organos Autonomos · Sector educacion · Universidad pública

ResumenRiesgo MEDIO

U. Amazonia presenta riesgo medio: tiene 3 hallazgos activos publicados, de los cuales 2 requieren atención prioritaria (2 altos). Además, 1 hallazgo está pendiente de revisión antes de decidir si se publica o se descarta. La prioridad es fortalecer autenticación de correo y reducir el riesgo de suplantación institucional. Los temas que más inciden son suplantación institucional, confianza del dominio y capacidad de recibir reportes de seguridad.

Siguiente paso: asignar responsable, fecha de corrección y evidencia de cierre; si un riesgo no se corrige, aceptarlo formalmente con dueño y fecha de revisión.

Descripción técnica

Se registran 3 hallazgos activos publicados: 2 altos y 1 medio. Hay 1 hallazgo pendiente de revisión que todavía no debe tratarse como publicado.

Señales técnicas principales: U. Amazonia: Dominio con riesgo de suplantación por correo: El riesgo de suplantación por correo sigue visible en 1 dominio: udla.edu.co. Sin registros CAA: dig CAA udla.edu.co retorna vacío. Sin canal estándar de divulgacion responsable: Ninguno de los 4 subdominios alcanzables publica /.well-known/security.txt (RFC 9116).

Focos técnicos dominantes: autenticación de correo; certificados, DNSSEC y confianza del dominio; y canal de reporte de vulnerabilidades.

Publicados: 3Altos: 2Medios: 1Pendientes: 1
Cobertura60
Postura de seguridad5
Divulgación responsable0
Consistencia operativa10

Hallazgos (3)

Sin registros CAA

Alta

dig CAA udla.edu.co retorna vacio.

Cualquier autoridad certificadora publica puede emitir certificados a nombre del dominio sin restriccion. Combinado con monitoreo CT incompleto, certificados fraudulentos pueden pasar inadvertidos.

U. Amazonia: Dominio con riesgo de suplantacion por correo

Alta

Email spoofing risk is still visible for 1 domain(s): udla.edu.co.

SPF/DMARC debil permite suplantacion de correo institucional y fraude dirigido.

Sin canal estandar de divulgacion responsable

Media

Ninguno de los 4 subdominios alcanzables publica /.well-known/security.txt (RFC 9116).

Un investigador que descubra una vulnerabilidad no tiene canal estandarizado para reportar antes de publicar. Crisis va a prensa antes que a la entidad.

Soluciones recomendadas

Qué necesita U. Amazonia

Acciones derivadas directamente de los hallazgos observados en esta entidad.

Inmediatas

Cifrado obligatorio en todos los portales

  • Activar HTTPS correctamente en todos los portales y subdominios.
  • Corregir certificados vencidos o mal configurados.
  • Habilitar HSTS para obligar conexiones seguras.
  • Revisar que no haya contenido mixto cargando por HTTP.

Mantenimiento técnico

Control de certificados

  • Publicar registros CAA para definir qué autoridades pueden emitir certificados del dominio.
  • Monitorear Certificate Transparency.
  • Renovar certificados automáticamente.
  • Detectar certificados sospechosos o no autorizados.

Canal de divulgación responsable

  • Publicar security.txt (RFC 9116).
  • Definir un correo oficial para reportes de seguridad.
  • Crear un procedimiento interno para recibir, validar y corregir vulnerabilidades.

Cómo sostenerlo

  • Política de mínimos de seguridad web. Estándar obligatorio para todos los portales (HTTPS, HSTS, DMARC, headers, backups, logs, actualizaciones, monitoreo), exigible a proveedores.
  • Cláusulas de ciberseguridad en contratos. Obligar mínimos técnicos, SLA de corrección por severidad, evidencias de parcheo y derecho de auditoría.
  • Monitoreo continuo. No una revisión anual: alertar ante cada nuevo subdominio, certificado, API o tecnología vulnerable, y medir la postura por entidad y proveedor.
  • Modelo de remediación coordinada. Cuando un hallazgo se repite en muchas entidades, corregir la causa raíz (proveedor, plantilla o configuración común) para cerrar el riesgo en bloque.
  • Indicadores para la alta dirección. Tiempo promedio de corrección, hallazgos críticos abiertos, % de entidades con DMARC y HSTS, activos expuestos sin responsable, riesgo por proveedor.
  • EstadoSeguro no solo detecta vulnerabilidades; permite priorizar soluciones.
  • No reemplaza a su equipo de TI: le da visibilidad, evidencia y orden.
  • No es una auditoría anual: es monitoreo continuo de la superficie pública.
  • No busca señalar culpables: busca cerrar brechas antes de que se conviertan en incidentes.
  • Convierte el riesgo técnico en decisiones ejecutivas: qué corregir, quién responde y qué hacer primero.
Solicitar diagnóstico

Cronología de hallazgos

2026-05-022026-07-05

Nuevos

4

Activos

3

Pendientes

1

Solucionados

0

Revisión de hallazgos pendientes

Revisado: 2026-07-05

Conservado en revisión

Hay 1 hallazgo pendiente con revisión conservadora: se mantiene fuera de publicación hasta cerrar evidencia suficiente. Esta decisión no los marca como solucionados ni como falsos positivos.

1 pendientes

f-univ-udla-03

requiere método seguro de validación · Datos personales

AltaConservado en revisión

Activos públicos (4)

udla.edu.co

portal principal

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Targeted passive refresh for univ-udla. Server: unknown.

Observado: 2026-07-05

www.udla.edu.co

portal principal

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

HTTPS error: <urlopen error timed out>. FQDN publicado en DNS publico (IP 131.100.48.194).

Observado: 2026-05-02

autodiscover.udla.edu.co

email

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

Targeted passive refresh for univ-udla. Server: unknown.

Observado: 2026-07-05

apps.udla.edu.co

subdominio

0/8
HTTPS
Certificado
HSTS
CSP
X-Frame-Options
X-Content-Type
Referrer-Policy
security.txt

HTTPS error: <urlopen error [Errno 65] No route to host>. FQDN publicado en DNS publico (IP 131.100.48.194).

Observado: 2026-05-02