Ciberseguridad centrada en la identidad

De dónde venimos y por qué este artículo es el puente

En los dos artículos anteriores construimos la base: definimos qué es una identidad digital y vimos los cuatro tipos modernos (personas, dispositivos, workloads, agentes IA), cerrando con la afirmación de que la identidad es hoy el “nuevo perímetro”. Esa afirmación es atrevida; en este artículo la vamos a respaldar con tres lentes complementarios:

1. Un marco organizacional — NIST Cybersecurity Framework — que muestra cómo IAM se inserta en la disciplina más amplia de ciberseguridad.
2. Un catálogo del adversario — MITRE ATT&CK — que nos enseña a pensar como un atacante y entender por qué las credenciales son su objetivo número uno.
3. Dos reportes de la industria — Verizon DBIR y Mandiant M-Trends — que aportan datos duros: qué pasa en la realidad, no en la teoría.

NIST Cybersecurity Framework: el lenguaje común de la ciberseguridad

El NIST Cybersecurity Framework (CSF) es probablemente el marco más adoptado para hablar de ciberseguridad en términos organizacionales. Nació en 2014 a pedido del gobierno de Estados Unidos para infraestructura crítica, pero rápidamente se convirtió en el lenguaje común de empresas, auditores y reguladores en buena parte del mundo. Si un CISO te pregunta “¿cómo cubres Detectar?”, está hablando NIST CSF.

La razón por la que CSF se volvió tan popular es práctica: no te dice qué herramienta comprar ni qué proceso adoptar. Te da un mapa de las funciones que cualquier programa de seguridad debe cubrir, y deja que tú elijas cómo cubrirlas según tu contexto.

Las seis funciones del CSF, de un vistazo

Hasta 2023, CSF tenía cinco funciones: Identificar, Proteger, Detectar, Responder y Recuperar. En febrero de 2024, NIST publicó la versión 2.0 y agregó una sexta función transversal — Gobernar — que envuelve a las otras cinco. La razón: muchas organizaciones tenían capacidades técnicas pero les faltaba la gobernanza para hacerlas sostenibles.

La imagen de abajo muestra a Gobernar como el sombrero que cubre todo (políticas, roles, riesgo, supply chain), mientras las otras cinco fluyen como un ciclo lógico. La flecha punteada de retorno desde Recuperar hacia Identificar es importante: cada incidente alimenta tu próximo ciclo. Si no aprendes de lo que pasó, vas a vivir el mismo incidente otra vez.

Pantalla completa

Las funciones, una por una, con su versión IAM

Para que no se queden en abstracciones, aquí va cada función con un ejemplo del dominio identidad:

Función	¿Qué busca?	Ejemplo IAM concreto
Gobernar	Establecer y comunicar políticas, roles y supervisión del riesgo	Política corporativa de “MFA obligatorio para todo acceso a producción”, aprobada por el comité ejecutivo
Identificar	Conocer activos, riesgos y dependencias	Inventario de identidades — humanas y no humanas — y mapeo de qué pueden acceder
Proteger	Implementar salvaguardas	MFA, SSO, vault de contraseñas, mínimo privilegio, segregación de funciones
Detectar	Descubrir actividad anómala	Alertas por login imposible geográficamente, MFA bombing, escalación inesperada
Responder	Contener y mitigar el incidente	Revocar sesiones, deshabilitar cuentas comprometidas, aislar la identidad
Recuperar	Restablecer servicios y aprender	Re-emisión de credenciales, restauración de accesos limpios, post-mortem y mejoras

Dónde encaja IAM dentro del CSF

Aquí viene la afirmación que conviene grabar: IAM cubre principalmente las primeras tres funciones (Identificar, Proteger, Detectar), e ITDR — Identity Threat Detection and Response — cierra las dos últimas (Responder, Recuperar) cuando la amenaza es de identidad.

El esquema de abajo dibuja esa división. A la izquierda, el clúster “IAM clásico” (IGA, Gestión de Accesos, PAM) alimenta a Identificar, Proteger y parte de Detectar. A la derecha, el clúster ITDR cierra el círculo alimentando Detectar, Responder y Recuperar. En la realidad, una herramienta IGA puede aportar también a Detectar vía analytics y un IdP puede aportar a Responder revocando sesiones, pero como mapa mental esta división es la que más se usa en la industria.

Pantalla completa

Identificar con IAM

Identificar responde a la pregunta “¿qué tengo y qué puede pasarle?”. En clave IAM, eso significa:

• Inventario de identidades — humanas y no humanas — sus atributos, sus dueños y su ciclo de vida.
• Inventario de aplicaciones y de qué identidades acceden a qué.
• Mapeo de cuentas privilegiadas y dónde viven.
• Risk scoring por identidad: quién tiene más exposición.

Si tu organización no puede contestar “¿cuántos exempleados todavía tienen acceso a alguna app?” en menos de 24 horas, te falta cubrir Identificar.

Proteger con IAM

Proteger responde a la pregunta “¿qué pongo en el camino para que el daño no ocurra?”. En clave IAM:

• Autenticación fuerte: MFA universal, passkeys, eliminación gradual de contraseñas.
• Autorización granular: principio del mínimo privilegio, separación de funciones (SoD).
• Aprovisionamiento automatizado: las identidades reciben los accesos correctos al ingreso, los pierden al egreso.
• PAM: cuentas privilegiadas en bóveda, sesiones grabadas, acceso just-in-time.
• Educación al usuario: phishing simulation, capacitación.

Esta es la función donde más invierte la mayoría de programas IAM. Es donde se ven los entregables tangibles (“desplegamos MFA en 50 apps”).

Detectar con IAM

Detectar responde a la pregunta “¿cómo me entero rápido cuando algo no anda?”. En clave IAM:

• Logs de cada autenticación, cada autorización, cada cambio de configuración.
• Alertas por patrones anómalos: login imposible (Madrid a las 14:00, Tokio a las 14:05), MFA bombing (10 push en 60 segundos), creación inusual de cuentas, escalación de privilegios fuera de horario.
• Integración con SIEM/SOAR para correlacionar identidad con red, endpoint y datos.

Aquí es donde IAM “clásico” (IdP + IGA) ya no alcanza por sí solo. Los logs están — pero alguien tiene que mirarlos. Eso nos lleva a ITDR.

ITDR cierra el círculo: Responder y Recuperar

Identity Threat Detection and Response (ITDR) es una categoría que Gartner formalizó alrededor de 2022. La idea: la infraestructura de identidad (Active Directory, Entra ID, Okta, etc.) es ya un blanco prioritario, y necesita su propio plano de detección y respuesta — análogo a EDR (Endpoint Detection and Response) pero para identidades.

¿Qué hace ITDR concretamente?

• Discovery de exposiciones: golden tickets activos, paths de Kerberoasting, shadow admins, cuentas con permisos inflados.
• Detección de comportamiento anómalo: aplica analytics (UEBA) sobre el plano de identidad para detectar lo que reglas estáticas no atrapan.
• Respuesta orquestada: ante una alerta puede revocar sesiones, deshabilitar cuentas, forzar re-autenticación, alertar al SOC, todo automáticamente.
• Investigación forense: cuando el incidente termina, permite reconstruir qué identidad hizo qué y cuándo.

Ejemplos de plataformas ITDR (mencionadas como referencia, no como recomendación): Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, Silverfort, Semperis, Quest. Todas comparten el patrón: instrumentar la infraestructura de identidad y detectar anomalías que el IdP por sí solo no cataloga como sospechosas.

Una analogía para no perderse

Una imagen mental que ayuda a separar IAM de ITDR: piensa en IAM como el equipo de vigilantes que dejan entrar y salir a la gente del edificio — verifican credenciales, registran horarios, dan las llaves de cada piso. Y piensa en ITDR como las cámaras y los sensores de movimiento que detectan algo raro — alguien rondando una zona donde no debería estar a las 3 AM, alguien intentando abrir 20 puertas seguidas, una llave usándose en dos pisos a la vez.

Los vigilantes (IAM) son indispensables, pero por sí solos no pueden estar en todos lados al mismo tiempo. Las cámaras y sensores (ITDR) son los que escalan tu capacidad de ver. Y un buen equipo de seguridad necesita ambos — no son alternativas.

MITRE ATT&CK: pensar como un atacante

Si NIST CSF es el lenguaje del defensor, MITRE ATT&CK es el lenguaje del atacante. ATT&CK (Adversarial Tactics, Techniques, and Common Knowledge) es un catálogo gigante mantenido por MITRE Corporation desde 2013, donde se documentan tácticas (los objetivos que persigue un atacante) y técnicas (los métodos específicos que usa para lograrlos).

Para entender por qué importa para IAM: ATT&CK te permite mirar tu programa de seguridad desde el otro lado de la mesa. En vez de preguntar “¿tengo MFA?”, preguntas “¿cómo intentaría burlar mi MFA un atacante real, según los casos documentados?”. Cambia tu pensamiento de defensa estática a defensa basada en escenarios reales.

El viaje del atacante, en lenguaje sencillo

ATT&CK organiza el comportamiento del adversario en 14 tácticas. Con lente de identidad, el viaje suele verse así — entrar, mirar alrededor, escalar, robar más llaves, moverse, quedarse oculto, llevarse o romper cosas. El esquema de abajo dibuja ese viaje sin la jerga. En incidentes reales el orden no es tan limpio, pero las etapas son útiles como mapa.

Pantalla completa

Las técnicas que conviene conocer

Cada técnica de abajo tiene un identificador (T-número) que es estándar en la industria — verás estos códigos en reportes de threat intelligence todo el tiempo. No necesitas memorizarlos; trata la tabla como un glosario al que volverás.

ID	Técnica	Qué hace	Defensa IAM
T1078	Cuentas válidas	Usar credenciales legítimas robadas	MFA universal, detección de geo imposible
T1110	Fuerza bruta	Probar contraseñas hasta acertar	Bloqueo progresivo, captcha, detección de password spraying
T1566	Phishing	Engañar al usuario para que entregue credenciales	Passkeys (resistentes a phishing), educación
T1003	Volcado de credenciales del SO	Extraer credenciales del SO comprometido (LSASS, SAM, ntds.dit)	EDR, Credential Guard, no usar admin local
T1558	Robo o falsificación de tickets Kerberos	Golden ticket, silver ticket, Kerberoasting	Rotación de KRBTGT, ITDR, monitoreo de tickets
T1098	Manipulación de cuentas	Modificar cuentas para mantener acceso (agregar admin, cambiar contraseña)	Alertas por cambios sensibles, certificación frecuente
T1556	Modificación del proceso de autenticación	Manipular el flujo de auth (Skeleton Key, MFA bypass)	ITDR especializado, alertas en cambios al IdP
T1550	Uso de material de autenticación alterno	Pass-the-hash, pass-the-ticket, robo de tokens OAuth	Tokens cortos, mTLS, device binding

Por qué los atacantes prefieren credenciales

Hay una frase popular en la industria: “los atacantes ya no hackean, se loguean”. El razonamiento es directo:

• Una vulnerabilidad técnica (un buffer overflow, un SQL injection) requiere encontrar el bug, escribir el exploit, esperar que la víctima no haya parchado.
• Una credencial válida abre la puerta sin levantar alarmas. Para el sistema, alguien con la credencial correcta es legítimo por definición.

Por eso la economía del cibercrimen pivotó hacia las credenciales. Existe un mercado negro maduro donde se venden credenciales válidas para empresas concretas (los “initial access brokers”), por entre 10 y varios miles de dólares según el valor. Los grupos de ransomware cada vez menos buscan vulnerabilidades — compran acceso ya hecho.

Una historia para fijar los conceptos: el ataque a una fintech ficticia

Para que las técnicas no se queden en una tabla, recorramos un escenario realista. Pongamos que somos una fintech mediana en Centroamérica con 400 empleados y 200,000 clientes activos. Tenemos Microsoft Entra ID como IdP, MFA por aplicación móvil para empleados y un SOC compartido con un MSSP regional.

Un lunes a las 7:43 AM, un atacante envía un correo de phishing creíble a 30 empleados, suplantando al equipo de RR. HH. con un PDF supuestamente sobre “actualización de prestaciones”. Tres empleados hacen click. Uno de ellos — David, del equipo de finanzas — ingresa sus credenciales en un sitio falso que reproduce la pantalla de Entra ID. Esto es T1566 Phishing.

A las 7:51 AM, el atacante ya tiene la credencial de David. Inicia sesión desde una IP en otro país. El IdP exige MFA. El atacante dispara push notifications consecutivas al teléfono de David. Después de la quinta notificación seguida, David — medio dormido y asumiendo que es un error del sistema — aprueba. Esto es MFA bombing, una variante de T1078 Valid Accounts combinada con presión psicológica.

A las 7:55 AM, el atacante está dentro como David. David es analista de finanzas, no admin. Pero el atacante no necesita ser admin todavía: empieza a leer correos en busca de información sensible. Encuentra un hilo donde se discuten credenciales de un sistema de tesorería. Esto es discovery y reconocimiento interno.

A las 9:12 AM, usando información de los correos, el atacante intenta acceso al sistema de tesorería con una credencial débil de servicio (un usuario tesoreria_app con contraseña que no rotaba hace 4 años). Logra entrar. Esto es T1078 (Valid Accounts) más una cuenta no humana mal gestionada.

Si la fintech tuviera ITDR instrumentado en su Entra ID, las alertas habrían saltado en al menos cuatro puntos: login geo-imposible, MFA bombing, comportamiento atípico de David (acceder masivamente a correos en una hora), y uso de cuenta de servicio fuera de su patrón típico. Sin ITDR, todo eso quedó en logs que nadie miró hasta el martes en la tarde.

Esta es la realidad cotidiana del SOC moderno. La diferencia entre “lo detectamos en 5 minutos” y “lo detectamos cuando ya extrajeron datos” está en si tienes los lentes adecuados puestos.

Los reportes que dictan la conversación: DBIR y M-Trends

Para que las conversaciones sobre IAM no se queden en opiniones, conviene anclarlas en datos. Hay dos reportes anuales que toda persona en este dominio debería leer al menos en su resumen ejecutivo: el Verizon DBIR y el Mandiant M-Trends.

Verizon DBIR (Data Breach Investigations Report)

El Verizon DBIR sale cada abril desde 2008. Es la investigación más amplia que existe sobre brechas de datos: en la edición 2024 analizaron más de 30,000 incidentes y casi 11,000 brechas confirmadas, contribuidas por 94 organizaciones de todo el mundo (incluyendo CSIRTs nacionales y proveedores de detección).

Hallazgos clave de las últimas ediciones, resumidos:

• El elemento humano está en el 68% de las brechas. No siempre malicioso — puede ser error de configuración, caída en phishing, o uso indebido por descuido.
• Las credenciales comprometidas son el vector inicial más común de brechas en sistemas web. La cadena típica: phishing → credencial robada → acceso a SaaS → exfiltración.
• El ransomware mantiene presencia constante, pero crecientemente combinado con extorsión basada en exfiltración (no solo cifran, también amenazan publicar).
• El tiempo medio para detección sigue siendo medido en semanas, no minutos, lo que da margen de maniobra al atacante.

Mandiant M-Trends

El Mandiant M-Trends es complementario al DBIR. Mientras el DBIR es una visión amplia y estadística, M-Trends viene desde el punto de vista forense: Mandiant (parte de Google Cloud desde 2022) hace investigación de incidentes en empresas grandes, y cada año publica un reporte con tendencias observadas en sus casos.

Hallazgos típicos relevantes a identidad:

• Tiempo de permanencia (dwell time): cuántos días el atacante estuvo dentro antes de ser detectado. En sus mejores años el promedio bajó a unos 10 días; en años recientes ha vuelto a subir, especialmente cuando el vector inicial fue una credencial válida (porque pasa más desapercibido).
• Abuso de cuentas válidas como táctica dominante: en la mayoría de los casos investigados, el atacante usó en algún punto T1078 (Valid Accounts).
• Ataques a la infraestructura de identidad: ataques dirigidos al IdP, a directorios federados, y a flujos de SSO. Casos como SolarWinds (Golden SAML) o el breach de Okta entran aquí.
• MFA bypass: técnicas crecientes para sortear MFA — push fatigue, ataques de adversary-in-the-middle (AitM) con kits como Evilginx, robo de tokens de sesión.

Por qué los dos reportes importan juntos

Los dos reportes se complementan:

• DBIR: amplitud. Te da la foto del ecosistema completo.
• M-Trends: profundidad. Te da el detalle de qué pasa en investigaciones reales.

Un buen ejercicio mental: cuando leas un titular de noticia sobre un breach grande, busca después en M-Trends del año siguiente y verás el patrón sistematizado. Y cuando un CISO te dice “necesitamos justificar la inversión en MFA”, abrir el DBIR y mostrar el dato de “el 68% de las brechas tienen elemento humano” suele ser más persuasivo que cualquier slide.

Un caso real: Lapsus$ y por qué los frameworks importan

Para aterrizar todo lo anterior, veamos cómo se conectan los tres lentes (CSF + ATT&CK + reportes) en un caso real.

En enero de 2022, el grupo de ransomware Lapsus$ comprometió a un proveedor tercerizado de soporte técnico de Okta. Desde la cuenta de un ingeniero de soporte, los atacantes accedieron a la consola de administración interna, lo que potencialmente les daba visibilidad sobre tenants de clientes. El alcance final fue limitado por respuesta rápida, pero el incidente sacudió a la industria — porque mostró que la infraestructura de identidad misma puede ser el blanco.

Lente 1: Mapeo a MITRE ATT&CK

Los atacantes recorrieron cinco pasos que reconocerás del viaje de arriba: phishing al ingeniero (T1566), robo de su credencial (T1078), llegar a la consola interna con esa credencial (T1078.004 — Valid Accounts en cloud), modificar el flujo de auth para resetear el MFA de una víctima (T1556), y finalmente manipular cuentas para extender el acceso a tenants de clientes (T1098). Si tu organización tuviera alertas explícitas para T1078.004 y T1556, habrías tenido oportunidad de detectar más rápido.

Lente 2: Mapeo a NIST CSF

Función	Falla específica observada	Mitigación que habría ayudado
Identificar	Riesgo de tercerizar acceso administrativo no estaba mapeado	Modelo de amenazas que incluya proveedores
Proteger	Acceso administrativo sin MFA resistente a phishing	Passkeys o llaves hardware obligatorias para admins
Detectar	Demora en detectar abuso de cuenta de soporte	ITDR sobre la consola de Okta
Responder	Comunicación al cliente fue percibida como tardía	Playbook de comunicación pre-ensayado
Recuperar	Revisión de tenants potencialmente afectados	Post-mortem público y mejoras estructurales

Lente 3: Lo que vimos en DBIR/M-Trends

El patrón “atacante entra por proveedor + abusa cuenta válida + extiende acceso” aparece en M-Trends de 2022 y 2023 como uno de los más frecuentes en incidentes de alto impacto. El DBIR de 2023 dedicó una sección al “supply chain interconnection” justamente por casos como este.

La lección estructural: tu seguridad de identidad no termina en tus empleados. Termina donde termina la cadena de organizaciones con acceso administrativo a tu infraestructura.

Recapitulación

Hemos cubierto los tres lentes que conviene tener al hablar de ciberseguridad centrada en identidad:

• NIST CSF te da el lenguaje organizacional. IAM cubre principalmente Identificar, Proteger y Detectar; ITDR cierra Responder y Recuperar cuando la amenaza es de identidad.
• MITRE ATT&CK te da el lenguaje del adversario. Las técnicas T1078, T1110, T1098 y T1556 son las que más conviene conocer porque aparecen en casi todo incidente moderno relacionado a identidad.
• DBIR y M-Trends te dan los datos. El elemento humano está en el 68% de las brechas y las credenciales son el vector más explotado — no porque la tecnología sea débil, sino porque la economía del cibercrimen se reorientó hacia ellas.

Si llevas estos tres lentes contigo a cualquier conversación de seguridad — con tu CISO, con un auditor, con un cliente — vas a poder traducir lo técnico (un MFA roll-out, un proyecto de IGA) a impacto organizacional. Y eso, más que cualquier certificación, es lo que distingue a un buen profesional IAM.

Tres preguntas para autoevaluarte

1. Te asignan rediseñar el programa de seguridad de una fintech regional. ¿Cómo describirías el rol de IAM dentro de las seis funciones del NIST CSF, en menos de un minuto, a un comité ejecutivo no técnico?
2. Si solo pudieras desplegar defensas para tres técnicas de MITRE ATT&CK en los próximos 90 días, ¿cuáles elegirías y por qué? Justifica con datos del DBIR si puedes.
3. Tu IdP empieza a ver patrones de “MFA bombing” contra varios usuarios privilegiados. ¿Qué función del CSF está fallando, qué técnica ATT&CK están usando los atacantes y qué capacidad ITDR sería más útil para responder?