Lapsus$ compromete Okta: la confianza en proveedores de identidad bajo escrutinio
A finales de marzo de 2022, el grupo Lapsus$ entregó su tercer golpe del trimestre, y probablemente el más significativo en términos de modelo de amenaza para empresas medianas: comprometieron a Okta, uno de los proveedores de identidad y autenticación más usados del mundo. El incidente se hizo público el 22 de marzo, cuando Lapsus$ publicó capturas de pantalla en Telegram demostrando acceso a paneles internos de Okta.
Lo más serio no fue el alcance técnico (Okta dijo que el acceso fue limitado a 25 minutos vía un sub-contratista llamado Sitel, con potencial impacto en hasta 366 clientes). Lo más serio fue el timing: Okta supo del incidente desde enero (16-21 de enero) y no avisó a sus clientes ni al público hasta marzo, cuando Lapsus$ los obligó publicando las capturas. Dos meses de silencio.
Para una empresa mexicana mediana que use Okta, Auth0, Azure AD, Google Workspace, AWS IAM Identity Center o cualquier proveedor de identidad como pieza central de su seguridad, el incidente abre tres preguntas grandes que vale la pena trabajar este Q2.
Qué pasó (versión ejecutable)
Reconstrucción según los comunicados de Okta y análisis de terceros:
- Entre el 16 y 21 de enero de 2022, un atacante (Lapsus$) obtuvo acceso al equipo de un ingeniero de soporte de Sitel, un sub-contratista que manejaba operaciones de soporte a clientes de Okta.
- Por aproximadamente 25 minutos, el atacante tuvo acceso a paneles internos de Okta usados por el equipo de soporte.
- Okta detectó actividad anómala y revocó accesos.
- Sitel contrató una firma forense, que produjo un reporte que llegó a Okta a finales de marzo.
- El 22 de marzo, Lapsus$ publicó capturas en Telegram. Okta hizo statement público horas después.
- Okta inicialmente comunicó que el alcance era nulo, después actualizó a "hasta 366 clientes potencialmente impactados".
Tres problemas graves visibles
1. La cadena de confianza tiene eslabón débil que no se ve
Tu empresa contrata Okta, no Sitel. Pero el acceso al panel de soporte que comprometieron pertenecía a un ingeniero de Sitel, no de Okta. Es risk by transitivity: confías en tu proveedor, pero no necesariamente sabes en quién confía tu proveedor a su vez.
Esto aplica a casi todos los SaaS que tu empresa usa. AWS subcontrata, Microsoft subcontrata, tu proveedor mexicano probablemente también. La cadena puede tener tres o cuatro eslabones, y cada uno es punto potencial de compromiso.
2. Comunicación tardía es traición a la confianza
Okta tomó dos meses en comunicar el incidente. La razón oficial: estaban esperando el reporte forense para tener "información completa". El resultado real: cientos de empresas operaron dos meses sin saber que su proveedor crítico había sido comprometido, sin oportunidad de tomar medidas mitigantes (rotar credenciales, revisar logs de acceso, alertar a sus equipos).
Para una empresa mediana que dependía de Okta para autenticación a sus sistemas críticos, esto es inaceptable. Y es la conducta default en la industria.
3. El IdP es punto único de fallo
Concentrar autenticación en un solo proveedor es eficiente operativamente: SSO consistente, gestión centralizada, MFA unificado. Pero también significa que comprometido el IdP, todo lo demás se compromete en cascada. Si el atacante se autentica como cualquier usuario en Okta, accede a Salesforce, Slack, Workday, AWS, GitHub y todo lo que esté detrás del SSO.
Qué hacer en tu empresa este Q2
1. Inventario de proveedores críticos de identidad
¿Quién hace qué para tu empresa en términos de identidad y autenticación? IdP principal (Okta, Azure AD, Google), MFA secundarios, gestores de contraseñas, SSO. Para cada uno, anota:
- Qué sistemas dependen de él.
- Qué pasa si está comprometido.
- Qué pasa si está caído.
- Quién es tu contacto humano en el proveedor.
2. Cláusulas de notificación en contratos
Revisa contratos de proveedores críticos. ¿Tienen cláusula de notificación de incidentes con plazo definido (24, 48, 72 horas)? La mayoría no. Para tus próximas renovaciones, exigirla. No es negociable para proveedores críticos.
3. Logging y monitoreo independiente
No dependas únicamente de los logs que te da el proveedor. Configura:
- Logs de Okta/IdP enviados a tu SIEM o a tu sistema central.
- Alertas propias para patrones anómalos (login a hora inusual, geolocalización extraña, accesos masivos a apps).
- Revisión periódica (al menos mensual) de cuentas con privilegios altos.
Si el proveedor es comprometido, vas a querer tener tus propios logs para entender el alcance.
4. MFA distribuido, no monomarca
Si tu MFA depende exclusivamente del proveedor de IdP, comprometido el IdP, comprometido el MFA. Para usuarios de privilegio alto, considera un segundo factor independiente: llave física FIDO2 que no esté gestionada por el IdP, MFA hardware-based para acceso a sistemas críticos.
5. Proceso de respuesta para "tu proveedor fue comprometido"
Documentado y ensayado:
- ¿Quién decide rotar credenciales masivamente?
- ¿Quién comunica al resto de la empresa?
- ¿Cuáles son los sistemas a revisar prioritariamente?
- ¿Cuál es el playbook para los primeros 12, 24 y 72 horas?
6. Revisión periódica de third-party risk
No solo a la firma del contrato. Revisión anual o semestral:
- ¿Sigue siendo SOC 2 Tipo II actualizado?
- ¿Han tenido incidentes públicos desde la última revisión?
- ¿Sus prácticas de seguridad han mejorado o empeorado?
- ¿Sus subcontratistas son aceptables?
Lo que vamos a ver en lo que queda de 2022
El incidente de Okta no es excepción, es señal. Esperamos:
- Más empresas confirmando que Sitel también las atendía. El blast radius probablemente es más grande de los 366 reportados.
- Más incidentes en proveedores de identidad y SaaS críticos este año, mismo modus operandi.
- Regulaciones más estrictas sobre notificación de incidentes (la SEC en EE.UU. ya está empujando 4 días; la UE con NIS2 va igual).
- Empresas medianas reevaluando arquitecturas SSO y sumando segundos factores independientes para roles críticos.
La lectura
Okta hizo dos cosas mal: tener un sub-contratista con seguridad débil, y demorar dos meses en comunicar el incidente. Para tu empresa, ambas son recordatorio de algo simple: confiar en un proveedor no es lo mismo que verificar que está cumpliendo lo que prometió.
Q2 es el momento para que las empresas mexicanas medianas que dependen de IdPs externos hagan revisión seria de la cadena de confianza, refuercen logging propio, y se aseguren de tener cláusulas y procesos para cuando vuelva a pasar (porque va a volver a pasar).
¿Tienes assessment de tus third-party providers? Hagámoslo. En ALCA acompañamos a equipos de seguridad y compliance a estructurar revisión de proveedores críticos con foco en identidad y SaaS. Conversemos sin costo.
