Art 8 /26. Ciberseguridad en tiempos de IA. El castillo de las mil puertas y algunas de ellas sin cerradura.
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:
- tu
proveedor más flojo, y
- 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)
.png)
Audio podcast en spotify
.png)
.png)
.png)
