Art 8 /26. Ciberseguridad en tiempos de IA. El castillo de las mil puertas y algunas de ellas sin cerradura.

En el artículo anterior tratábamos la salud mental como algo que hacía inteligentes a las empresas. En este vamos a hacer un cambio de tercio (si me permitís el símil taurino) pero sin abandonar la criticidad y siempre con el ser humano como factor clave.

Hoy os hablaré de algo que sabemos que pasa, pero que solo llena titulares cuando sucede un incidente y no bueno precisamente. Si amigos y amigas de este espacio compartido; hoy os hablare de la ciberseguridad. Porque esto es así; en las compañías pasa como con el ABS o los airbags en los coches: nadie los aplaude cuando funcionan, pero cuando fallan piensas en esa revisión o reparación que te saltaste o en ese piloto encendido al que no le diste importancia.

Porque en estos tiempos, el “enemigo” ya no entra con pasamontañas (bueno, no tan frecuentemente) : entra con tu contraseña reciclada, una API mal protegida, un proveedor despistado, o un agente de IA con demasiados permisos. Y de todo eso trataremos hoy. Espero que os sea útil o, al menos, despierte conciencias.

 

1) La gran empresa: ese castillo enorme con miles de puertas (y algunas sin cerradura)

En las compañías, sean grandes o medianas, el problema no es “tener un muro muy alto”. En todas ellas el punto de acceso lo encontramos en que hay:

• Miles de identidades repartidas (empleados, terceros, partners, bots, etc... y todos con accesos con más o menos privilegios).
• Nubes, SaaS, APIs, móviles, teletrabajo y IPs con accesos de dudosa seguridad.
• Proveedores conectados a la empresa y cada uno con sus “cosas”.
• Cosas viejas, pero “críticas” -según para quien- que nadie se atreve a tocar y ahí siguen.
• Y departamentos que trabajan a ritmos distintos. Porque sí, aquí también encontramos silos.

Porque voy a comenzar por algo evidente pero que igual a algunos/as les parece un descubrimiento: el atacante no “hackea” tu empresa; hackea tu acceso. De hecho, en ataques a aplicaciones web, una de las empresas de referencia; Verizon, reporta que una parte enorme de las brechas dentro de ese patrón incluye el uso de credenciales robadas.
Y si hablamos de ransomware, también hay señales claras de que las credenciales expuestas/robadas están muy presentes en la cadena de ataque que no es que lo diga yo, sino que lo podéis leer en SpyCloud.

Algunos casos donde los “malos” encontraron una puerta son bien conocidos; Telefónica, Hospital Clinic de Barcelona, Santander, Iberia, SEPE… y paro aquí que tengo limitación de espacio.

En un primer resumen; el cibercrimen es cada vez menos “Misión Imposible” y más “si me dejas las llaves siempre debajo de la maceta me estás invitando a ver lo que hay en tu casa”.

 

2) Acceder desde fuera: tu “puerta principal” no puede ser solo una contraseña

Si se puede acceder a la empresa desde fuera (sea con VPN, apps internas, correo, RRHH, LMS… o lo que sea), tener solo la contraseña sin más es como cerrar con una cuerda y nudo facilón. Lo mínimo hoy es:

• MFA sí o sí (doble factor) para cualquier acceso externo y para cuentas con privilegios.
  Porque si te roban la contraseña, el segundo factor es el “no tan rápido, campeón”.
• Mejor aún si el MFA es anti-phishing de verdad, tipo llave física o sistemas FIDO2/WebAuthn.
  Porque el phishing ya no es un mail cutre: ahora parece escrito por tu jefe o el colega de toda confianza… y encima existe el “MFA fatigue”: te bombardean de avisos hasta que, por cansancio, alguien le da a “Aceptar”.

Y esto no es una opinión: NIST (los que saben y son referencia en seguridad) lo recomienda en sus guías de identidad digital: autenticación más robusta y resistente a engaños tipo “hombre en el medio” (MitM).
La referencia exacta os la dejo en la bibliografía al final del artículo.

Tambien os quiero hablar de la cero confianza práctica (Zero Trust, pero de verdad)

La cero confianza no es ningún producto. Es una idea simple:

• No confíes por defecto en redes “internas”.
• Verifica identidad, dispositivo y contexto (ubicación, riesgo, postura del endpoint).
• Da mínimos permisos y revisalos continuamente.

 

3) “Que no entren por las cabeceras, IPs o cualquier sitio” dicen los técnicos. Vamos a ponerlo en castellano entendible

Aquí hablamos de perímetro moderno y sobre todo de aplicaciones y APIs, porque la guerra ya no va solo de que pongo un firewall y todos felices.

A) Cabeceras / tráfico web / reverse proxies

Medidas clave:

• WAF (Web Application Firewall) bien afinado y testeado.
• Protecciones anti-bots y rate limiting.
• Validación estricta de inputs (y salida), y políticas de seguridad web (CSP, HSTS, etc.).
• TLS fuerte en todo (cifrado en tránsito).

B) Bloquear acceso solo por  IPs: útil, pero no es una solución definitiva. Imagina que solo hay un camino para llegar al castillo, pero otro coge tu coche. Problema al canto.   

Filtrar por IP ayuda claro, pero, ojo, como lo que os comentaba del coche, no te resuelve todos los problemas:

• Hay VPNs, proxies, móviles, redes dinámicas.
• Un atacante puede entrar desde una IP “buena” si entra en una sesión o te roba las credenciales (ese es el coche, por si hay algún/a despistado/a).

Lo recomendable es usar la IP como señal, no como candado.

C) APIs: la puerta trasera que se ha convertido en una de las vulnerabilidades favoritas.

Hoy casi todo se conecta con APIs (que son como “pasillos” por donde las aplicaciones se hablan entre sí). El problema es que muchas empresas los tienen mal vigilados… y por ahí se cuela medio mundo.

OWASP (gente muy seria en seguridad) dice que lo que suele ocurrir para que ese agujero acabe en drama es:

• Permisos mal puestos (te dejan ver cosas que no son tuyas),
• Autenticación floja (o lo que es lo mismo; fácil de suplantar),
• Demasiados datos devueltos (te enseñan más de la cuenta).

Os pongo un ejemplo típico (y peligroso) pero sencillo:
Imagina que existe una ruta tipo: /api/users/12345 y el sistema te devuelve datos de ese usuario sin comprobar que tú eres ese usuario (o que tienes permiso), un atacante solo tiene que cambiar el número:

• /api/users/12346
• /api/users/12347

Y empieza a cotillear (o robar) datos como quien va pasando páginas.

Es decir, si tu API “confía” en lo que le piden sin comprobar nada más, tu API es como si un camarero te entrega una cartera que se ha encontrado simplemente porque le has guiñado un ojo y ya da por hecho que eres su dueño.

4) Lo que más tumba empresas no es el “virus” o el “malware”: es el “mañana lo arreglamos”

Muchas brechas de seguridad no pasan porque el malware lo haya hecho un genio… pasan porque en la empresa pasan cosas de este estilo:

• “Esto está mal configurado, pero funciona… no lo toques”
• “Ese servidor lleva años sin actualizar, ya si eso lo miramos”
• “Ese acceso era temporal… bueno, lo dejamos así”

ENISA (la agencia europea de ciberseguridad) lleva tiempo avisando de lo mismo: lo que más está pegando hoy es el ransomware, los ataques a través de proveedores, y que cada vez tenemos más sistemas conectados (más puertas, más ventanas y más rendijas). Lo podéis revisar en enisa.europa.eu.

Y aquí viene el golpe bajo: la cadena de suministro (proveedores) es el ninja silencioso. Si un proveedor pequeño tiene menos defensas y le entran… pueden usarlo como pasarela para llegar a ti. Por eso este tema está cada vez más en el foco de informes y prensa económica como un reciente artículo en el Financial Times.

Así que vamos a definir una regla dura pero realista. Tu seguridad es tan fuerte como:

1. tu proveedor más flojo, y
2. tu configuración más olvidada.

Así que sí, puedes tener un castillo precioso… pero si te dejas una puerta del garaje medio abierta, te la van a encontrar. Dalo por hecho.

 

5) Departamentos a los que les afecta todo esto. Que ya lo saben, pero repasémoslos.

• IT / Infra / Cloud: configuración, parches, redes, identidades, logging.
• Ciberseguridad (obvio): prevención, detección, respuesta, gobierno.
• RRHH: altas/bajas, accesos, phishing (y el “usuario nuevo” es un target muy jugoso).
• Legal & Compliance: NIS2, protección de datos, evidencias, contratos con proveedores.
• Compras / Vendor Management: due diligence de terceros, SLAs de seguridad, auditorías.
• Finanzas: fraude (BEC), pagos, suplantaciones.
• Formación / L&D: cultura, simulaciones, hábitos, onboarding seguro (sí, ese usuario nuevo que hemos dicho antes).
• Dirección: priorización y presupuesto (sin el apoyo de arriba, todo se vuelve imposible).

 

6) IA y agentes: el nuevo becario que trabaja a la velocidad de la luz… y puede liarla igual de rápido.

Este es uno de mis temas favoritos. Y aquí, la IA viene con, al menos, dos cambios de nivel:

-          Amenazas potenciadas por IA

• Phishing más creíble y personalizado. Su perfección es nuestra ruina.
• Automatización de reconocimiento y ataques.
• Deepfakes de voz/video para fraude. Esto ya lo veis en otros ámbitos.

-          Riesgos nuevos por “agentes” (IA con herramientas)

Un agente conectado a sistemas (correo, drive, tickets, ERP, LMS) puede:

• Ejecutar acciones no deseadas por prompt injection (“haz esto aunque no debas”).
• Filtrar datos si no hay control de permisos/registro.
• Convertirse en un “superusuario accidental” si le das llaves maestras.

Así que visto lo anterior os comparto una regla de oro: un agente de IA es un software con esteroides. Dale permisos como si fuera un humano… pero con auditoría extra y correa corta.

 

7) Checklist para que esto no sea solo un artículo bonito sino práctico

Os paso una lista de cosas a tener en cuenta que resume lo anterior y lo pone en orden:

A) Identidad y acceso (la madre del cordero)

• MFA obligatorio en todo acceso externo y privilegiado.
• Preferir MFA resistente a phishing (p. ej., FIDO2/WebAuthn) cuando sea posible.
• SSO centralizado + políticas condicionales (riesgo, dispositivo, geolocalización).
• “Least privilege”: permisos mínimos y temporales (PAM para admins o sea dar permisos solo cuando hace falta y con control).
• Proceso rápido y auditable de altas/bajas (joiner/mover/leaver).

B) Endpoint y dispositivo

• Equipos gestionados (MDM/EDR), cifrado de disco, parcheo automatizado.
• Bloqueo de acceso a datos críticos desde dispositivos no gestionados.
• Navegador y correo endurecidos (protección contra phishing y adjuntos maliciosos).

C) Red, perímetro y aplicaciones

• WAF + rate limiting + anti-bots en frontales.
• Segmentación (no todo en la misma “red feliz”).
• DLP donde toque (datos sensibles).
• SDLC seguro: revisión de código, SAST/DAST, gestión de dependencias.

D) APIs (donde se escurre medio mundo)

• Autorización por objeto (BOLA acrónimo inglés de Broken Object Level Authorization ) revisada sistemáticamente.
• API Gateway con autenticación fuerte, quotas y logging.
• Inventario real de APIs (las “shadow APIs” existen).
• Minimización de datos: devolver solo lo necesario.

E) Proveedores y cadena de suministro

• Due diligence de seguridad y cláusulas contractuales (incidentes, auditorías, subprocesadores).
• Evaluación periódica y SLA’s exigentes (no solo al firmar sino durante toda la vida del contrato).
• Accesos de terceros: mínimos, caducables, monitorizados.

F) Detección y respuesta (porque nada es 100% impenetrable)

• Logs centralizados (SIEM), alertas útiles (no 5.000 al día).
• Playbooks de incidentes (ransomware, robo de credenciales, fuga de datos).
• Copias 3-2-1, pruebas de restauración (la copia que no se prueba es sencillamente tener fe).
• Simulacros: tabletop con negocio + técnico.

G) IA y agentes

• Catálogo de usos permitidos (y prohibidos) de IA.
• Datos sensibles: reglas claras (qué no se debería subir jamás).
• Agentes con permisos mínimos, acciones “peligrosas” con aprobación humana.
• Registro/auditoría de acciones del agente (quién, qué, cuándo, con qué prompt).
• Evaluación de riesgos de prompt injection y exfiltración.

 

8) Apartado especial: Ciberseguridad en un LMS conectado al PC corporativo

Y termino con un tema más que interesante porque ocurre en muchas organizaciones; cuando hay un LMS “pegado” al entorno corporativo. Esto puede ser una bendición (control) y a la vez una tentación para algunos/as (si cae, escala a más).

Lo imprescindible en un LMS corporativo moderno

Identidad y acceso

• SSO con el directorio corporativo (SAML/OIDC) y MFA heredado de la empresa.
• SCIM (o automatización equivalente) para altas/bajas de usuarios y grupos: si alguien se va, se va también del LMS.
• RBAC (roles) fino: alumno, manager, formador, admin… y nada de “admin por si acaso”.

Seguridad del endpoint

• Si el LMS se usa desde equipos corporativos:
• Integrar con políticas de dispositivo (MDM/EDR).
• Evitar descargas locales de contenidos sensibles si no hace falta.
• Proteger sesiones (timeout, refresh tokens bien gestionados).

Aplicación y datos

• Cifrado en tránsito (TLS) y en reposo.
• Separación de entornos (dev/test/prod) y datos anonimizados en no-prod.
• Logs de actividad: accesos, cambios de rol, exportaciones de datos, integraciones.
• Protección ante OWASP Top 10 (web) y OWASP API Top 10 si hay APIs.

Integraciones

• LMS suele integrarse con HR, correo, Teams/Slack, BI, LXP, etc.
• Cada integración es como poner una nueva puerta:
• Tokens con alcance mínimo.
• Rotación de credenciales.
• Monitorización de llamadas API.
• Principio de “si se rompe, que se rompa de forma segura”.

IA dentro del LMS

• Si hay tutor/coach/chatbot IA:
• No entrenar ni “reutilizar” conversaciones con datos sensibles sin control.
• Filtros de contenido y prevención de fuga.
• Reglas claras de qué puede hacer el agente (¿crear cursos? ¿matricular? ¿exportar?).

Os pongo un ejemplo para entenderlo mejor; Si un “agente” del LMS puede matricular gente y exportar listados, eso ya es dato personal + capacidad operativa. Mínimos permisos, aprobación humana para exportaciones masivas, y registro de cada acción.

Conclusión:

La ciberseguridad “top” en grandes compañías no es comprar la herramienta de moda. Es diseñar el acceso, blindar identidades, separar sistemas, vigilar lo importante, ensayar incidentes, y ahora además… ponerle correa y bozal a los agentes de IA.

Porque el futuro no va a tener menos puertas. Va a tener más, y como digo en el encabezado, algunas no tienen cerradura o han dejado la llave debajo de una maceta.

 

Fuentes y bibliografia

• Verizon, Data Breach Investigations Report (DBIR) 2025 (hallazgos sobre patrones de ataque y credenciales). (Verizon)
• NIST, SP 800-63B-4 Digital Identity Guidelines (2025) (autenticación, canales protegidos y prácticas recomendadas). (NIST Publications)
• ENISA, Threat Landscape 2025 (panorama de amenazas en Europa, supply chain, OT, etc.). (enisa.europa.eu)
• OWASP, API Security Top 10 (2023) y OWASP Top 10 (riesgos clave en APIs y apps web). (owasp.org)
• Financial Times (cobertura sobre aumento de ataques vía terceros / supply chain). (Financial Times)

• Comunicado oficial Banco Santander sobre acceso no autorizado (14 mayo 2024). (Santander)
• Reuters: Telefónica investiga posible ciberataque por datos filtrados (3 jun 2025). (Reuters)
• INCIBE-CERT: ciberataque ransomware al Hospital Clínic + evolución del incidente. (INCIBE)
• Associated Press: impacto operativo del ataque al Hospital Clínic (marzo 2023). (AP News)
• El País: conclusiones sobre medidas mínimas y contexto del ataque al Clínic (noviembre 2024). (El País)
• INCIBE-CERT: SEPE comienza recuperación tras ciberataque (marzo 2021). (INCIBE)
• SecurityWeek: Iberia notifica brecha por compromiso de proveedor (noviembre 2025). (SecurityWeek)
• CISA: lecciones aprendidas del ataque a Colonial Pipeline. (cisa.gov)
• SEC (8-K): estimación de impacto económico de MGM por incidente (octubre 2023). (SEC)
• FTC: caso Equifax y acuerdo global (hasta 700M$). (Federal Trade Commission)
• Forbes / LA Times: pérdidas estimadas Maersk por NotPetya (200–300M$). (Forbes)
• Bloomberg: pérdidas reclamadas por Merck (~1.3B$) por NotPetya. (Bloomberg.com)
• OWASP: riesgos principales en seguridad de APIs. (cisa.gov)

 

 

Audio podcast en spotify