¿Qué se necesita para tener seguras las identidades digitales en la empresa?

La semana pasada un amiguete y compañero de profesión me hizo esta pregunta: "¿Que necesitaría para tener seguras las identidades digitales en mi empresa?" ¿Necesitaríamos invertir más en Soluciones de Gobierno de la Identidad, de Gestión de Cuentas Privilegias, Control de Acceso, CIAM, Multifactor Authentication? ¿O sería conveniente que empezáramos a mirar soluciones de ISPM (Identity Security Posture Management) o ITDR (Identity Threat Detection and Response)?

Figura 1: ¿Qué se necesita para tener seguras

las identidades digitales en la empresa? 

Una pregunta de muñeca rusa, donde una pregunta lleva a otra y a otro. Para responderle fácilmente, y comenzar la conversación con un poco más de contexto, la respondí cariñosamente que eso dependerá de los resultados de la Evaluación de Riesgos. Así que si ya tenía una duda, yo le acababa de meter un nivel más de complejidad, que hizo que se le quedara cara de sorprendida.

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

Hay que tener en cuenta que no en todas las organizaciones, los departamentos que gestionan la Seguridad de las Identidades Digitales, están integrados en el área de seguridad, y en muy pocos se realiza una evaluación de riesgos más o menos formal para concluir los controles a implementar en base a los riesgos identificados.

Riesgos de Seguridad de la Gestión de Identidades

Seguidamente la invite a reflexionar de manera una poco más profunda, y estuvimos comentando los escenarios riesgos principales que afectan a la Gestión de Identidades Digitales y que controles mitigantes en formato de soluciones de seguridad de la identidad sería conveniente implementar en base a los mismos:

• Leavers: Casos frecuentes de personas que abandonan la compañía y cuyas cuentas de acceso a la organización no se desactivan a tiempo - o nunca- o usuarios que cambian de departamento y arrastran sus permisos de acceso a sistemas. En este caso deberíamos priorizar una herramienta de Gobierno de Identidades Digitales.

• Cuentas Privilegiadas Sin Control: Administradores de sistemas o aplicaciones que mantienen el acceso privilegiado asignado de manera permanente y no se monitoriza / controla cómo usan sus privilegios. En este caso deberíamos priorizar la implementación de una solución que nos permita movernos a un escenario de Zero Standing Privileges (ZSP) y que asigne los permisos de administrador durante el tiempo que se necesiten para realizar la tarea administrativa y siguiendo el flujo de aprobación necesario.

Figura 3: Demostración de Robot de Tokens OAuth de identidades

También dependiendo del escenario podría ser conveniente implementar una solución que haga grabación e indexación de sesiones como las que aportar los Privileged Access Manager (PAM) tradicionales, aunque de manera generalista no es algo que, a mí personalmente, me guste del todo, ya que la telemetría que ofrecen hoy en día los End-Point Detection & Response (EDR) es suficiente en la mayoría de los casos para tener un tracking que nos permita identificar cómo los administradores utilizan sus permisos administrativos.

• Acceso con una autenticación débil: Tanto a aplicativos como a servicios expuestos en Internet - e incluso que no están expuestos en Internet hoy en día 😊 -. En este caso los  Identity Providers (IDP) que la mayoría de las empresas tienen, como pueden ser Azure AD o Google IDP, ya tiene capacidades más que suficiente para proveer una autenticación robusta, pero claro hay que configurarlos bien. Sin embargo, hoy en día una autenticación con usuario y contraseña + un Multi-Factor Authentication (MFA) compartido por SMS es algo que se nos queda un poquito cortito en cuanto a seguridad.

Figura 4: Las Yubikeys para gestión de Passkeys

Por lo tanto deberías abogar por implementar Passkeys en la medida de los posible, y ya de paso, quitamos a los usuarios el dolor de las passwords añadiendo unas políticas de acceso condicional que tengan una inteligencia mínima que haga que el sistema sea capaz de reaccionar frente amenazas del sistema de autenticación como puede ser cambios de ubicación imposibles o un usuario que se autentica con una parámetros que difieren bastante de sus comportamientos, tales como horarios y localizaciones de login.

• Riesgos asociados con las identidades de Business Partners: Ya sean clientes, proveedores, o fabricantes, que consumen servicios digitales que provee la empresa. En este caso sería conveniente contar con un Customer Identity & Access Management (CIAM) que nos permita unificar la experiencia de usuario en su proceso de autenticación, aportando seguridad y reducción fricción, así como asegurar el cumplimiento a normativas que puedan ser aplicables como el Reglamento General de Protección de Datos (RGPD) y tunear la experiencia del usuario

• Riesgo de Fraude debido a Conflictos de Segregación de Funciones: o dicho de otra de manera  más sencilla con un par de ejemplos, que el mismo usuario tenga permisos para hacer las nóminas y liberar los pagos, o que el mismo usuario tenga permisos para crear solicitudes de pedidos de compras y aprobar la mismas. 

En este caso necesitaremos una solución de estilo  Government Risk & Compliance (GRC) que nos permita controlar conflictos de segregación de funciones, idealmente de manera proactiva, y que sea multi aplicación, es decir, que no se limite a los permisos de una sola aplicación, como el ERP. Esto es algo que algunas herramientas de Gobierno de Identidades proveen, y también, obviamente, existen soluciones dedicadas a mitigar este tipo de riesgos

 

No creo que sea necesario seguir con más ejemplos, entiendo que con estos cinco casos se ve bastante bien que los riesgos que se busquen proteger en la gestión de identidades deben priorizar la decisión sobre que tecnologías debes implantar. Como habéis visto, además, no he querido tirarme al barro del riesgo relacionado las Non-Human Identities - y las tecnologías de seguridad para las Non-Human Identities -o las Identidades de Agentes IA, ya que estos actúan en nombre del usuario, o con su propia identidad, por lo que se debe tener en cuenta que los mismos van a trabajar en base objetivos y no de manera determinista, por lo tanto sus permisos es fácil que necesiten cambiar mientras estás realizando una tarea.

Figura 5: Identidades NO Humanas (NHI "Non-Human Identities").

La Gestión de un Riesgo de Seguridad Emergente

Esto seguro que nos da para otro artículo dedicado, aunque si me gustaría mencionar que esto a día de hoy es un riesgo relevante real, principalmente para organizaciones mas avanzadas tecnológicamente hablando (por supuesto que llegará al resto). Esta es una categoría que aún está siendo construida - no olvidéis que el primer Agentic AI lo vimos en diciembre de 2024, con lo que llevamos menos de un año y medio con los agentes, y empresas como Cloudflare están construyendo arquitecturas de referencia para la gestión de la seguridad de estas identidades.

Figura 6: Arquitectura de MCP Security en Cloudflare

Como conclusión, me gustaría resaltar la importancia de definir un roadmap de trabajo dentro del Plan Director de Seguridad con todas las iniciativas relacionadas con la Seguridad de Identidades en base a los riesgos que necesitemos mitigar. Y por supuesto, que seamos conscientes de que la seguridad de la identidad digital en muchas ocasiones (cada más) es la única capa de defensa, por lo tanto debemos tomarnos muy en serio esta labor, e implementar las medidas de protección pertinentes hasta llevar el nivel de riesgo a ratios aceptables para nuestra organización. O atente a las consecuencias.

Saludos,

Autor: Samuel López Trenado, especialista en Gestión de Identidades Digitales

Contactar con Samuel López Trenado

Cómo lograr el Check de Verified en LinkedIn con una Identidad Pública que no coincide con la Identidad Legal

Durante los últimos años, las redes sociales han ido incorporando sistemas de verificación con el objetivo de reforzar la confianza entre los usuarios. Estos sistemas consisten en un mecanismo mediante el cual la plataforma confirma que la persona o entidad que gestiona una cuenta es realmente quien dice ser. La recompensa visible para el usuario es una insignia, un pequeño icono —el conocido check— que, para muchos, simboliza autenticidad y fiabilidad.

Figura 1: Cómo lograr el Check de Verified en LinkedIn con una

Identidad Pública que no coincide con la Identidad Legal

En el caso de LinkedIn, esta insignia de verificación pretende indicar que un perfil pertenece a una persona real y que la información presentada coincide con su identidad profesional, pero hay que entender que no tiene por qué ser la información legal. A través de estos distintivos, la plataforma busca generar un entorno más seguro, donde los usuarios puedan interactuar con confianza, evitando suplantaciones y facilitando la creación de redes profesionales legítimas. Además, el sistema permite verificar no solo la identidad, sino también documentación, garantizando que determinada información que aparece en el currículo de la persona es correcto.

Sin embargo, esta lógica presenta un matiz a conocer. La verificación no siempre vincula de manera técnica y directa la identidad visible del perfil con la identidad que se ha validado internamente. Algo que hay que entender si te dedicas a la investigación de identidades en Internet. Es decir, un usuario podría mostrarse como verificado gracias al check, pero no existir una correspondencia completa entre los datos de la persona que aparece en el perfil y aquella que ha pasado el proceso de validación. 

Figura 2: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

La insignia ofrece cierta seguridad y confianza, pero no asegura la correspondencia absoluta entre la identidad verificada y la visible, por lo que debes conocer su funcionamiento correctamente para entender sus límites. En LinkedIn, un perfil verificado transmite una idea muy concreta, detrás de ese nombre hay una identidad confirmada, pero podría darse el caso que no fuera exactamente la visible, que es lo que la mayoría de usuarios interpreta sin pensarlo demasiado. 

 o que vas a ver a continuación no muestra una intrusión, ni una toma de cuenta, ni una vulnerabilidad técnica clásica. Muestra algo distinto, un flujo de verificación para reforzar la autenticidad del perfil, pero que deja que la identidad visible de una cuenta sea distinta de la identidad legal acreditada. Esto, si lo conoces, no tiene por qué ser malo. Muchas personas tienen nombres públicos que no son los que están en sus identidades legales, como Moxie Marlinkspike o Chema Alonso, pero aún así se puede verificar que son ellos. Moxie Marlinsspike protagonizo en un evento una anécdota que se hizo famosa cuando le pedían un ID con su nombre en un evento, y el dijo simplemente: "Google me", para que la persona que le registraba supiera que él era Moxie Marlinspike, - una identidad creada por él mismo - incluso si su identidad legal era otra.

Dicho de otra forma, el sistema comprueba que hay una persona real detrás - que ha hecho el proceso de Know Your Custormer -, pero el usuario final puede seguir sin saber quién es realmente esa persona . Cuando una insignia de verificación deja de responder a la pregunta “quién está detrás” y pasa a responder sólo a “hay alguien detrás”, el modelo de confianza debe ser otro. Es cierto que, si hay algún problema, la plataforma que ha verificado a esa cuenta, sabe quién está detrás de ella. Es decir, la identidad legal del que controla esa cuenta.

Lo curioso es que, de acuerdo con el flujo operativo descrito, ante una discrepancia, LinkedIn propone una salvaguarda consistente en mostrar el nombre oficial como complemento público en el perfil. Incluso llega a mostrar una vista previa en la que el alias, la insignia de verificación y el nombre legal aparecen conjuntamente, reforzando la transparencia y autenticidad del perfil. 

Sin embargo, esto no parece la mejor idea para perfiles que tienen una identidad pública bien reconocida que prefieren conservar la privacidad de su identidad legal. Como vamos a ver en esta demostración, aunque la intención declarada por LinkedIn en la ayuda es mostrar la identidad legal, el resultado operativo final, y el resultado finalmente visible demuestra que se puede ocultar la identidad legal, divergente con la identidad pública.

Figura 3: Según la ayuda de Linkedin, el nombre legal entre paréntisis,

y el nombre público destacado.

La prueba de concepto que sigue documenta precisamente eso. Cómo un perfil con un nombre divergente puede atravesar el proceso de verificación documental y biométrica, llegar hasta la fase en la que LinkedIn reconoce la discrepancia - y aunque promete transparencia -, terminar finalmente con la insignia añadida sin que se muestre tu identidad legal. Aunque hay discrepancia, la identidad legal no queda visible como complemento en el perfil. No se trata de una hipótesis. Se trata de una secuencia reproducida, documentada y observable. Vamos al grano.

1. Preparación de la cuenta y estado inicial

Qué se quiere demostrar con esta prueba de concepto:

• Se parte de una cuenta con un nombre de perfil divergente respecto del nombre del documento.
• El proceso de verificación documental y biométrica se completa correctamente.
• LinkedIn detecta la discrepancia y ofrece una salvaguarda de transparencia.
• La vista previa muestra que el nombre oficial aparecería entre paréntesis.
• El resultado final observado es un perfil verificado con alias y sin nombre complementario visible.

La cuenta utilizada en la prueba muestra un nombre de perfil divergente, "El lado del mal", y en ese momento todavía no dispone de ninguna verificación añadida. 

Figura 4: Estado inicial de la cuenta: nombre de perfil divergente

y ausencia de verificación previa. 

Este punto es importante porque fija el estado previo. El alias visible, cuenta operativa y cero insignias activas.

2. Verificación documental y biométrica

El flujo de Persona valida la identidad de la persona real detrás de la cuenta. El material gráfico permite ver que el proceso pasa por el escaneo físico del documento, la comprobación biométrica y la validación final de identidad. 

Figura 5: Secuencia resumida del proceso de "Know Your Customer".

Escaneo del documento, verificación biométrica y validación positiva de identidad.

Para evitar exponer datos innecesarios, en esta versión se han omitido capturas donde aparecen campos documentales completos.

3. LinkedIn detecta la discrepancia y propone una salvaguarda

Una vez verificada la identidad real, LinkedIn no añade todavía la insignia. En ese punto aparece un mensaje explícito: el nombre del ID no coincide con el nombre del perfil y, como alternativa para poder verificar la identidad, se ofrece mostrar el nombre del documento oficial como complementario en el perfil.

Figura 6: Aviso de discrepancia de nombre y activación

de la salvaguarda propuesta por LinkedIn.

4. La propia plataforma enseña el resultado esperado

La siguiente pantalla es decisiva porque ya no es una interpretación del investigador. Es la propia plataforma la que muestra una vista previa de cómo debería quedar el perfil si se acepta la opción propuesta: alias visible, insignia de verificación y nombre oficial entre paréntesis como complemento público.

Figura 7: Vista previa del comportamiento esperado. El nombre oficial

aparece como complemento visible junto al alias.

5. Resultado final observado

Tras completar el flujo, la verificación queda añadida al perfil. No obstante, el resultado visible no coincide con la vista previa anterior, el perfil termina mostrando la insignia de verificación sobre el alias, pero sin el nombre oficial complementario que LinkedIn había presentado como mecanismo de transparencia.

Figura 8: Comparativa directa entre el resultado que LinkedIn

promete y el resultado finalmente observado en el perfil.

6. Interpretación técnica de la evidencia mostrada

La imagen documenta el estado final de la prueba de concepto y concentra, en una sola vista, el núcleo del fallo de lógica observado en el flujo de verificación de LinkedIn. Desde el punto de vista técnico, lo que se aprecia es la coexistencia de tres elementos que no deberían convivir de esta forma si la salvaguarda de transparencia se aplicara correctamente, según la ayuda de la plataforma.

• Un nombre de perfil arbitrario o alias visible
• Una insignia de verificación de identidad activa
• La ausencia del nombre legal complementario que el propio flujo promete mostrar cuando detecta discrepancia entre identidad acreditada e identidad mostrada.

Figura 9: Resultado obtenido BYPASS Business Logic Error

 / Broken Identity Binding

Esto permite inferir que el proceso de validación documental y biométrica ha finalizado con éxito - se ha hecho el KYC,  el backend ha marcado la cuenta como verificada y tiene la documentación almacenada, pero que la capa de representación pública del perfil no está materializando de forma efectiva el mecanismo de unión entre identidad legal e identidad pública, que es algo que debes tener en cuenta.

Dicho de manera más precisa, la plataforma resuelve correctamente la pregunta “existe una persona real detrás de esta cuenta y sabemos quién es”, pero “la identidad pública que se muestra al resto de usuarios no tiene por qué ser la identidad legal que ha sido acreditada”.

Lo que se muestra no es una simple anomalía visual o un problema cosmético. Lo que refleja es una posible desincronización entre el estado de verificación concedido y la política de exposición del atributo de identidad complementaria descrito en la ayuda de Linkedin. En otras palabras, el sistema concede el distintivo sin hacer cumplir de manera consistente la condición de transparencia que él mismo presenta como alternativa cuando existe un desajuste de nombres, pero que por otro lado permite a las identidades públicas mantener la privacidad de sus identidades legales.

A nivel de lógica de negocio, esto encaja con un escenario de Broken Identity Binding, la identidad  legal validada existe, pero no queda correctamente enlazada con la identidad pública consumida por terceros. El resultado práctico es que el usuario que observa el perfil recibe una señal de autenticidad fuerte, pero que si carece del contexto mínimo necesario para interpretar correctamente qué ha sido verificado y bajo qué identidad, podría llevarle a confusión o error. 

7. Implicación de seguridad y abuso potencial de esta evidencia

En un sistema de verificación bien ligado, la insignia debería actuar como un atributo de confianza contextualizado. Es decir, no solo debería indicar que el proceso de validación ha sido superado, también debería permitir interpretar correctamente qué identidad ha quedado acreditada frente al resto de usuarios. Cuando esa unión falla, el distintivo conserva su fuerza visual, pero pierde precisión semántica. Es decir, podría parecer que la identidad legal es la que se ve públicamente es la misma - porque no aparece entre paréntesis otro nombre), sin ser así.

Eso abre la puerta a varios escenarios a tener en cuenta. Lógicamente, hay que pensar en la suplantación creíble con validación, ya que un actor podría construir un perfil con un alias, una identidad visual cuidada o incluso una identidad coincidente con la de un tercero, completar la verificación con su propia documentación legítima y terminar mostrando públicamente una cuenta que transmite autenticidad sin revelar el contexto real de la verificación. Para el observador externo, la insignia refuerza la apariencia, para el atacante, reduce el riesgo de ser detectado y aumenta credibilidad. Para limitar la suplantación de personas conocidas, por supuesto, Linkedin tiene los mecanismos de denuncia de suplantaciones, y por eso las empresas monitorizan las identidades de sus ejecutivos en la red para detectar estos posibles casos.

Hay que añadir que, además, en caso de que esta identidad fuera parte de un delito que se investigara, la plataforma podría entregar la documentación que usó la persona en el proceso de KYC, pero para engaños individuales a personas a través de redes sociales, podría dar a la identidad un halo de ser lo que se ve, cuando realmente es otra persona.

En este caso, el objetivo ya no es parecer una persona concreta, sino parecer una entidad fiable. Nombres como “Security Team”, “Compliance Department” o cualquier otra formulación institucional adquieren más potencia cuando van acompañados de una verificación activa. El problema no es solo el alias, también que el distintivo puede ser interpretado por la víctima como una validación indirecta del rol, del contexto o de la autoridad del emisor. Para ello hay que entender que las verificaciones pueden verificar también la documentación, pero puede ser que alguien verifique su identidad con este proceso, pero no verifique sus aptitudes, por lo que podría ser mintiendo en sus títulos y acreditaciones.

Cuando una plataforma proyecta una señal fuerte de autenticidad, terceros pueden usarla como referencia adicional en procesos de evaluación, contacto profesional, validación de antecedentes o interpretación pericial informal. Hay que entender bien los límites de la verificación, y si la identidad visible no queda unida con transparencia a la identidad legal acreditada - lo que podría ser una opción de privacidad - ,  y los que consumen estos límites no lo conocen, la plataforma introduce sin quererlo ruido precisamente en el punto donde debería reducirlo.

En otras palabras, el problema no está en que LinkedIn permita usar identidades públicas o alias. El problema aparece cuando el distintivo de verificación sigue actuando como una señal fuerte de identidad legal - tal y como dice en su ayuda - sin que el usuario pueda interpretarlo correctamente. Es decir, si la Verificación permite el uso de Identidades Públicas con privacidad de Identidades Legales, no debería decir que si hay discrepancia entre ellas mostrará las dos en la Verificación y luego que se pueda evitar eso.

Saludos,

Autor: Catalin Barsan Apostolescu

Contactar con Catalin Barsan Apostolescu

Fear of the Dark: Detección de Suplantación de Identidad y DeepFakes usando Verificación de Identidad en MyPubicInbox

Continuando la serie de Fear of the Dark, como parte de la presentación de RootedCON, sincronizamos la publicación de un servicio para Perfiles Públicos que llevaba tiempo con ganas de tener. Como os he contado muchas veces, me he topado con la experiencia de la suplantación de mi identidad muchas veces, y por eso quería tener una forma de solucionar esto, mediante una Verificación de Identidad explícita, en este caso, usando MyPublicInbox.

Figura 1: Fear of the Dark: Detección de Suplantación de Identidad

y DeepFakes usando Verificación de Identidad en MyPubicInbox

La idea es muy sencilla. Supongamos que tú estás por ahí en las redes, y supuestamente te has topado conmigo, con Chema Alonso en un foro, en un canal de chat, o alguien que has encontrado te ha dicho que yo es mi amigo y que yo hago trabajos de hacking, que invierto en nosequé, o que yo estoy detrás de algo, y entonces un día tienes un chat o una vídeo conferencia "conmigo"... 

Figura 2: Verificación de Identidad en MyPublicInbox

Ya te digo yo que seguramente sea un Suplantación de Identidad y puede que estén usando una DeepFake, así que, sencillo. te vas a mi perfil en MyPublicInbox, y solicitas una Verificación de Identidad, que de momento es un servicio gratuito para todos los usuarios de MyPublicInbox.

Figura 3: Verificación de Identidad en MyPublicInbox

Desde ahí puedes enviar una evidencia, mediante una captura de pantalla, junto con una descripción de dónde supuestamente estás teniendo una reunión virtual conmigo, un chat, o una conversación. Si estás teniendo esa supuesta reunión conmigo, puedes "decirme" que quieres Verificar Mi Identidad sin ningún problema, que yo pasaré este proceso contigo.

Figura 4: Te llevará a tu cuenta de MyPublicInbox

para solicitar la Verificación de un Perfil Público

Esto generará una Petición de Verificación de Identidad que me entrará en Mi buzón de MyPublicInbox para que pueda revisarla, con toda la información que me has enviado. Solo tengo que ir a la sección de Verificación de Identidad y tendré en la zona de Verificar Identidad la petición.

Figura 5: Petición de Verificación de Identidad

Y ahora, pues con pulsar en Revisar tendré acceso a los detalles que me hayas proporcionado, con la captura de la imagen por delante, así que puedo ver si es una conversación mía de verdad o no. En este caso, para la demostración he subido una fotografía mía, pero lo suyo es subir la captura de una vídeo conferencia o del chat, o de lo que sea que se supone que soy yo.

Figura 6: Revisión de los datos de la petición de Verificación de Identidad

Y como yo soy yo, y sé si yo estoy haciendo ese chat, esa vídeo conferencia, esa reunión virtual o tengo esa cuenta en ese supuesto foro, pues daré a Rechazar o Verificar, con lo que generará un PDF con los datos del proceso de la Verificación o la No Verificación.

Figura 7: Informe de Verificación

El documento son unas páginas donde se detallan los datos de la petición, los datos de las fechas, y que ha pasado por los servidores de MyPublicInbox, que el usuario concreto que recibió la petición la revisó y dijo que sí, que era él, o que no, que no era él.

Figura 8: Informe completo firmado digitalmente

La única Verificación de Identidad que utilizamos ahora mismo es la del dueño de la cuenta, que sabe si él está o no está teniendo esa reunión o no. Es como si me llamara un amigo y me dijera: 

"Oye Chema, ¿eres tú el que está ahora en el foto de XXXX diciendo esas cosas?" 

Y yo le confirmará que sí o que no. Lo que me ayudará a mí a saber dónde me están suplantando la identidad y a él a protegerse contra una estafa.

Figura 9: Configuración de Verificación de Identidad en MyPublicInbox

Para configurar esto este servicio en MyPublicInbox, si eres un Perfil Público, puedes activarlo en el menú de tu cuenta de MyPublicInbox en la sección de Verificación de Identidad - Configurar Verificación. En el siguiente vídeo tienes una demostración de proceso completo.

Figura 10: Verificación de Identidad en MyPublicInbox

Al final, a pesar de que sea un servicio dependiente de una identidad en Internet - la de MyPublicInbox - ya obliga a los ciberestafadores a primero tener que robar la cuenta de MyPublicInbox, y luego a hacer la DeepFake o la suplantación, por lo que es una protección más antes de enviar dinero, o hacer cualquier tontería. 

Figura 11: "Ciberestafas: La historia de nunca acabar" (2ª Edición).por Juan Carlos Galindo en 0xWord.

Y por supuesto, desde MyPublicInbox monitorizamos el uso de este servicio para detectar situaciones de fraude, que además de mucha víctima, también hay mucha ciberestafa, por lo que la monitorización constante es clave siempre.

• Fear of the Dark: Fear, Data & Fake News
• Fear of the Dark: DeepFakes, Sappo & Sentiment Analysis
• Fear of the Dark: Detección de Suplantación de Identidad y DeepFakes usando Verificación de Identidad en MyPubicInbox
• Fear of the Dark: Primal Fears & Retórica IA
• Fear of the Dark: Deep Fakes, Fake News & Primal Fears
• Fear of the Dark: Un pequeño estudio de medios y miedos

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

La "shittización" en contra de hacer las cosas simples

Hace años, más de una docena, usaba a mis queridos héroes de "The Big Bang Theory" para explicar cómo de difícil lo habíamos hecho los que trabajamos en ciberseguridad para que las personas normales se pudieran conectar de forma segura a una red WiFi y a Internet. En el artículo de "Mea Culpa, Penny" explicaba todas las cosas que un usuario debía saber para configurar una VPN que se tunelizara a través de proxys, firewalls de redes,... ¿La quiere L2TP, SSTP o PPTP? 

Figura 1: La "shittización" en contra de hacer las cosas simples

Si eso se lo tengo que decir a mi madre, mejor la tengo que decir que no se conecte. Pero esta complejidad constante de la tecnología se ha ido extendiendo a la guerra comercial por el usuario, lo que hace que cada vez el número de opciones, los diseños de los interfaces, y el salto conceptual intelectual que el diseñador de un UX espera de un usuario, es cada vez mayor. 

En los foros tecnológicos se dice que un UX se ha "shitted" o "enmierdado" cuando la cantidad de opciones para el usuario, la anarquía de la distribución, la diversidad de los controles que debe tocar, y la cantidad de cosas que el usuario "debe suponer" para poder manejarlo, es enorme, y genera frustración en los usuarios. Esto, que parece evidente, es muy complicado de hacer. Hacer las cosas simples require de mucho trabajo, y para ello hay que primar al usuario o consumidor, por encima de las necesidades de negocio.

Cambiar de terminal iPhone

Os cuento esto por dos casos que he sufrido esta semana, que han sido bastante significativos. El primero de ellos con la migración de mi iPhone. Este es un proceso que he realizado ene veces ya, porque todos los años voy migrando mi iPhone. Esto implica migrar las apps, las fotos, los datos, etcétera... Todo esto bien, pero pero cuando llegamos a las partes de seguridad, la cosa se complica un poco. En mi caso, el iPhone era americano, además, como tengo en el mismo la conexión personal y la profesional, tenía una SIM y una eSIM, de dos países diferentes, además de que tenía que pasar de SIM a eSIM obligatoriamente.

El proceso, por supuesto, no funcionó correctamente, y acabé teniendo que ir a tienda, borrando las eSIM creadas virtualmente a partir de la SIM, y teniendo que comprar nuevas eSIM para el terminal americano. Eso hizo que perdiera los contactos de la SIM, y los contactos de la SIM perdidos generaron que se borraran también de la agenda, y por ende de WhatsApp y por ende usuarios dejaron de ver mi foto y me escribieron "¿Me has bloqueado?" No, estoy migrando un iPhone, no worries. Algunos se habrán enfadado y me habrán borrado a mí, así que me ha hecho perder amigos.

Como tengo Multi-SIM para dos países distintos, voy cambiando qué SIM activo o desactivo, pero claro, en la nueva versión de iPhone asocia a cada contacto una SIM por defecto, y cuando no está conectada esa SIM te sale una alerta que dice: "¿Quieres cambiar la asociación por defecto de la SIM a este contacto para poder llamar?" Y un sinfín de lindezas más, como por ejemplo que los contactos de iOS ahora tienen el botón de contactos, donde sale la lista y solo se puede hacer scroll y pulsar a la derecha en unas letras muy, muy, muy chiquititas... que no sé quién ha diseñado.

Figura 2: Esta me ha encantado. El número que el banco ha pasado a Apple es erróneo y después de llamar al Contact Center de ese número y esperar 20 minutos me dicen: "El número que te da iPhone no es de tu banco, somos otro banco". Genial.

Con la SIM ha sido una fiesta, pero luego hubo que migrar las Wallets, las apps bancarias, los 2FA, las autenticaciones de las herramientas de mensajería, etcétera, etcétera, y para cada una el proceso con la entidad es distinto. Instala app, inicia sesión con las credenciales, por el 2FA, te falta la passkey, recupera password, envía SMS, es de otro país y no llega, desactiva SIM, activa la otra, etcétera. Muy divertido y entretenida la gincana de migrar un terminal iPhone.

La autenticación doble con la identidad simple

La más divertida ha sido una app de un servicio - permitidme que no diga la empresa porque tengo amigos en ella y quiero arreglarlo antes -, donde al ir a hacer Login me ha dado la opción de usuario y contraseña, y en paralelo la opción de "Login con Google". Como no recordaba la contraseña - llevaba la app instalada mucho tiempo con autenticación automática con FaceID - le he dicho que autentique con Google. Y... surprise, me he encontrado con que usé la cuenta de Google sí, pero no con autenticación delegada, sino que lo hice con una contraseña, así que estamos en el caso de misma dirección de e-mail con doble autenticación, con usuario y contraseña o con IdP delegado usando OAuth.

Esto es un problema de arquitectura que los responsables de identidad y seguridad deben resolver, y si no lo hacen bien, genera escenarios de ataque como os comenté en el artículo del año 2022 : "Pre-Hijacked Accounts: o cómo robar una cuenta a un usuario antes de que se la cree". Dependiendo de cómo lo resuelvan, se pueden dar unos casos u otros. En mi caso, ha sido un DoS en toda regla que aún no he podido resolver y que voy a resolver llamando a mis colegas en esa empresa. 

El proceso ha sido muy divertido. Me enfrento al login y doy a "Login with Google". Comienza el proceso de autenticación delegada, y el sistema descubre que mi cuenta ya está creada pero con autenticación con contraseña. Salta el sistema de protección y unión de los dos procesos de autenticación para la misma identidad y me pide la contraseña que tiene la cuenta. Correcto. No la recuerdo, así que voy al proceso de recuperación de contraseña. Me manda el enlace de recuperación al correo de la cuenta de Google. Ojo que me lo envía a la dirección de correo con la que acabo de hacer login con Google, luego... ¿para qué? Si acabo de hacer login con Google, tengo acceso al Gmail del login de la cuenta, así que es un paso innecesario que no añade ninguna seguridad, pero para el sistema serán dos procesos independientes, y es el usuario el que se tiene que adaptar a la arquitectura y no al revés.

Da igual, sonrío, hago clic para cambiar la contraseña de la cuenta, pongo una y me dice... "No se puede cambiar la contraseña a esta cuenta". ¿Por qué? Pues porque en vez de mantener los dos autenticadores - con Google y por Usuario/Password, ha fusionado a un sólo autenticador, pero hasta que no introduzca la contraseña anterior - que no me deja cambiar - no puedo iniciar sesión. Conclusión "Deadlock" de libro por un mal diseño de seguridad. 

Después de dos días migrando cosas, aún me quedan un par de tarjetas bancarias que por motivos "corner case" aún no he conseguido migrar, y una cuenta de servicios de la empresa que por geo-location tampoco me permite procesar, pero más o menos lo tengo todo. Pero mientras pasaba por este proceso, me imaginaba a mi madre, y a muchas, muchas, muchas personas que tienen que pasar por aquí recordando que yo entiendo qué me están pidiendo, qué me está pasando, cuál es la situación en la que estoy en todo momento, pero que para ellas puede ser un dolor increíble.

La nueva "Simple" Televisión

Esta parte, que ha sido una de ellas, no ha sido la única experiencia que he tenido estas últimas 72 horas con esto, ya que además he querido cambiarle una televisión a mi madre para quitarle el descodificador y que solo tuviera un mando - de la SmartTV - y que no se confundiera. Al final, su problema consiste en que enciende la Televisión y el Descodificador y que si todo va bien, no hay problema, coge el mando del desco y cambia los canales y ve la tele - que es lo único que ella quiere -. Pero... si usa el mando de la SmartTV para subir o bajar canal, la SmartTV cambia el Source y se va a modo TV quitando el HDMI 1 de su fuente, y adios televisión. Y mi mamá, de 74 años, piensa que "ya se me ha ido la televisión".

Pues bien, le dije, ¨te voy a cambiar la televisión que está vieja, y te voy a poner la tele en una app y quitamos un mando del medio". Precioso decir, imposible para ella. Al final, encender la televisión y me pide una cuenta de la empresa de SmartTV que tengo que crear con un QRCode - imaginaos a una persona de 74 años ante eso -, después me pide que instale una app en el terminal, así que hay que usar las cuentas de Apple para ponerla en el iPhone, la instalas, te autenticas en la app con un correo y una password, te manda un SMS como 2FA, luego sigues un Wizzard de permisos para la app, y si quieres las noticias de la compañía de la televisión, las ofertas, los datos que le quieres dar de la app, y luego te pide el código que ves en la pantalla de la televisión de 14 dígitos, para darla de alta en tu app.

Y todo eso, en la primera pantalla de configuración de la SmartTV. 

Después de más de 20 pasos y una hora de configuración, con las ofertas de Amazon Prime gratis un mes, la de Apple TV, de quitar las apps de SmartThings para IoT, las autenticaciones en las diferentes apps, el inferfaz usa controles de usuario de tabs arriba, con líneas de vídeos y apps en un scroll infinito para abajo, y paneles que se expanden en los laterales. Así que me pongo con mi madre a enseñarle, y después de decirle 

"no, esa película no la puedes ver porque es de una promoción de un mes gratis de Apple TV y te lleva a esa app. Dale para atrás. Vaya, no sale. Pues dale al inicio. Ahora vete a la sección apps. Sí, tienes que bajar. Con las flechas. Ahora. Dale al ok. ¿El ok? Ah, espera, en este mando es distinto, el ok, es ese cuadrado con una flecha que sale de él. Sí, ahí. Ahora dale a la app. Sí, no te sale el canal que tenías antes, porque se personaliza con tus datos de navegación, así que hasta que no lo veas varias veces no te lo va a poner en su sitio, así que tienes que entrar en la guía. Es ese icono con unas rayas arriba a la izquierda. Sube con las flechas. Ahora entra, y sale la guía, ahora baja hasta que encuentres el canal. Sí, sigue bajando que hay cientos de canales. Ahora dale al ok. Sí esa es la ficha del canal. Dale al ok. No, que le has dado a la flecha y te has movido. Vuelve atrás. No, te has ido a la guía otra vez, era que movieras la flecha a la izquierda. No pasa nada vuelve a bajar. Sí, sé que son muchos... "

Pues bueno, le he quitado al nueva SmartTV, y le hemos puesto el sistema del desco (con una sola televisión) y al mando de la televisión anterior, para que no lo toque, Mi Survivor ha decidido ponerle celo a todos los botones menos al de encender y apagar, para que sepa que ese mando solo es para encender la televisión y nunca lo cambie de Source. Y no son pocos los que hacen eso.

Figura 3: Mandos "simples"

El MacBook Pro no arranca

Ya la última de las aventuras con la "shittización" de la tecnología, ha sido con mi MacBook Pro, que ha decidido no arrancar esta mañana - por eso estoy escribiendo el post tan tarde -. No tiene botón de hard-reset, la batería está cargando, pero no arranca. La última vez que me pasó eso, tuve que esperar dos días a que descargara toda la batería, y empezar de nuevo a cargarlo, y entonces funcionó, pero no tengo ni idea de qué le ha pasado. Tengo copia de seguridad de todo, así que no hay problema, pero tengo la seguridad de que si lo llevo a la tienda Apple me van a decir:

"Está roto, no se puede recuperar nada, compre otro". 

UPDATED: 20 horas después, se ha descargado y ha arrancado el MacBook Pro... otra vez como nuevo. Sin comprar ningún otro.

En resumen, menos mal que estoy al día de la tecnología y entiendo cómo funciona, entiendo qué está mal hecho en los sistemas, y al menos sé qué debo hacer para avanzar desde una situación a otra para conseguir arreglar el segundo paso, pero hablando de esto hace unos meses con un viejo colega de armas, sentados cómodamente, enumerábamos la cantidad de productos que eran fáciles, guays, sencillos y que se han "Shitted".

Unos meses después, os estoy escribiendo este artículo, porque cada vez vamos más rápido sacando tecnología, cada vez tiene menos QA, cada vez los UX son más "shitted" por permisos, seguridad, necesidades de negocio, etc... y hacen que las funciones core (como en el ejemplo de "ver la tele") estén cada vez más lejos de los usuarios. Recordad que os conté el lío que tuve con el bug de UX en WhatsApp solo por el tamaño de letra...

¿Tienes alguna experiencia similar? Déjamela en comentarios que me encantará leerla...

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

OSINT: Cómo encontrar personas en LinkedIN usando el buscador de fotos de Google con atributos "Cognitivos"

Soy un usuario activo de Linkedin, pero hace mucho que no puedo procesar todos los mensajes y peticiones de contacto. Las comunicaciones profesionales las moví a mi buzón público en MyPublicInbox, y el límite de posibles conexiones de contacto es de 30.000. Eso sí, puedes seguir creciendo en seguidores, pero el número de contactos directos está limitado.

Figura 1: OSINT - Cómo encontrar personas en LinkedIN usando

el buscador de fotos de Google con atributos "Cognitivos"

Yo tengo automatizada la respuesta a todas las peticiones de conexión, que prefiero dar una explicación de por qué no acepto la conexión o no contesto los mensajes, pero sí que soy un usuario activo de Linkedin donde comparto, leo bastante, comento y reposteo. 

Figura 2:Perfil de Chema Alonso en LinkedIN

Además, de vez en cuando, tengo que localizar a una persona que he conocido, que me han dado de referencia, o que por algún motivo quiero saber exactamente quién es. 

Figura 3: Estadísticas de mi perfil de LinkedIN de ayer

Cuando la conozco físicamente, o tengo una fotografía, en lugar de usar el buscador de Linkedin uso los buscadores, que me permiten localizar a la persona sin que les deje registro de que yo he visto su perfil, ya que puede que lo haya visto por error, así que me aprovecho de los buscadores de imágenes.

Figura 4: Libro de "Hacking con Buscadores: Google, Bing & Shodan + Robtex"

de Enrique Rando, publicado en 0xWord.

El asunto es que puedes buscar por fotografías en LinkedIN usando el buscador de fotografías de Google, y localizar a un persona, y con el avance e la IA, las fotografías están descritas con Cognitive Services de Visión Artificial, así que puedes hacer cosas muy chulas.

Figura 5: Buscando a John Smith en Linkedin

Por ejemplo, supongamos que quieres buscar a John Smith en Linkedin, pues usando una sencilla búsqueda como podéis ver en la imagen anterior sale un buen número de perfiles públicos con fotografías permitidas para ser públicas más allá de Linkedin. Pero podemos modificar la búsqueda usando atributos visuales y metadatos, por ejemplo.

Figura 6: John Smith con gafas

Supongamos que la persona que buscamos tiene gafas, pues pedimos eso en el buscador de fotografías, y nos saca cuentas y fotografías públicas de personas en Linkedin con gafas. Fácil. Y lo mismo podemos hacer con algún otro atributo cognitivo, como por ejemplo la edad.

Figura 7: John Smith de más de 60 años

Tal vez aparezca gente que parece que tiene menos - puede ser - la búsqueda no tiene por qué ser perfecta, pero como véis sí que te permite afinar usando esas características. E incluso por el tipo de ropa con que aparece en la foto.

Figura 8: Jonh Smith con chaqueta negra

Al final son pequeñas "tricks" para hacer un poco de Open Source INTelligence (OSINT) para investigar personas e identidades en Internet, pero con un objetivo bueno, no con uno malo. Eso sí, también lo puedes utilizar para muchas investigadores que te interesen.

Figura 9: Open Source INTelligence (OSINT): Investigar personas e Identidades en Internet 2ª Edición de 0xWord, escrito por Vicente Aguilera y Carlos Seisdedos

Siguiendo con la búsqueda, puedes utilizar algunos elementos muy singulares, como por ejemplo buscar por un "hat" para ver qué perfiles de John Smith salen con una foto que tenga un sombrero. El resultado es curioso y funciona.

Figura 10: John Smith con "hat"

Yo lo he querido probar también buscando los atributos de la empresa, y el resultado es bastante bueno. Por ejemplo, si buscas por "José María Alonso" en el buscador de imágenes de Google para localizar los perfiles de LinkedIN, no sale el mío.

Figura 11: José María Alonso en Linkedin

Pero si añades el nombre de la empresa, Cloudflare, podéis ver cómo automáticamente sale mi perfil el primero, con lo que sabiendo unos pocos datos puedes localizar el perfil de LinkedIN correcto.

Figura 12: José María Alonso de Cloudflare

En ninguno de estos casos hemos tocado la cuenta de Linkedin, así que los perfiles que has buscado no sabrán que tú los has buscado. No aparecerá en las estadísticas de su cuenta, y te ahorrarás que se pregunten el porqué los estás buscando. Aunque sea para algo bueno.

¡Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)  

Identidades NO Humanas (NHI "Non-Human Identities"): La Gestión de un Riesgo de Seguridad Emergente

Las Identidades No Humanas o Non Human identities (NHI) están últimamente en boca de todos los profesionales de la seguridad de la información y la ciberseguridad que centran su profesión en la gestión de Identidades Digitales. Es cierto que en este mundo Post-Covid, donde se produjo una proliferación del trabajo desde cualquier lugar, utilizando cualquier dispositivo (Anywhere and Anydevice) trajo asociado, en muchos casos, la eliminación del perímetro de red como capa de protección, al igual que las medidas de seguridad a nivel de puesto de trabajo.

Figura 1: Identidades NO Humanas (NHI "Non-Human Identities").

La Gestión de un Riesgo de Seguridad Emergente

Todo esto se produjo gracias a que se comenzó a fomentar que los usuarios se pudieran conectar desde cualquier dispositivo y desde cualquier ubicación. Ee esta manera la identidad, y más concretamente la seguridad en la identidad, pasa a ser el nuevo perímetro, la capa principal y, en muchas casos, única donde puedes poner medidas de seguridad ya que no hay control del dispositivo o la red de conexión desde la que el empleado se conecta.

La mayoría de las empresas entendieron muy pronto este desafío de seguridad y se pusieron manos a la obra implementando medidas de seguridad focalizadas en la protección de la identidad de los usuarios que consumían sus aplicaciones o servicios digitales, donde implementando un factor de autenticación robusto en la autenticación, como pueden ser los basados en Push notificaciones en dispositivos móviles, los basados en Biometría o incluso optando por Passkeys o Yubikeys para obtener una seguridad adicional y eliminar las passwords ya conseguías protegerte en gran medida.

Figura 2: Las Yubikeys

Adicionalmente, si esto lo combinabas con un sistema de “Unknown login location” simplemente geolocalizando la dirección IP pública desde la que los usuarios consumen los servicios digitales, y respondiendo con una verificación de la legitimidad cuando los usuarios intentan conectar de localizaciones que varían significativamente de las habituales, entonces ya estarías gestionando y controlando bastante bien el uso de las identidades digitales, al menos en lo que al proceso de autenticación se refiere.

Identidades No Humanas

Fenomenal, con lo que hemos explicado brevemente en la parte superior entendemos a grandes rasgos el paradigma de gestión las identidades digitales de los empleados (Humanos) que consumen los servicios digitales de nuestra organización. ¿Pero qué pasa con las Identidades No Humanas? O, mejor dicho, ¿Qué son las identidades no Humanas? ¿Por qué son importantes? ¿Hay algún motivo que nos haga pensar que el riesgo relacionado con las mismas está en aumento? 

Pues bien, a estas preguntas intentaremos darlas respuesta en este artículo y así clarificar igualmente si la gestión de las Identidades no Humanas (NHI) es simplemente una moda potenciada por los equipos marketing de los diferentes fabricantes de software de identidad que quieren subirse a este barco, o por el contrario es un riesgo emergente sobre el cual deberíamos empezar a actuar si aún no lo hemos hecho.

¿Qué son las Identidades No Humanas?

Empecemos explicando qué se entiende como una Identidad No Humana, donde de una manera muy simplista podemos definirla como toda aquella identidad que ejecuta una carga de trabajo y/o existe en un directorio de identidades pero que no está relacionado con una persona física (Humana). De esta manera, y desglosando un poco más, entendemos como Identidades No Humanas todas aquellas relacionadas con máquinas y dispositivos, como servidores, contenedores, estaciones de trabajo, dispositivos móviles, dispositivos de OT, dispositivos IOT, etcetera.

A estas hay que sumar todas las identidades relacionadas con cargas de trabajo de software, como cuentas de servicio, APIS, cuentas de conexión a Bases de Datos o Aplicaciones utilizadas por software, cuentas de ejecución de scripts, Robotic Process Automation (RPA), Chatbots, Agentes AI basados en LLMs., y un largo etcétera de cuentas que antes simplemente llamábamos "Cuentas de Servicios" y que ahora se están multiplicando por doquier, y empiezan a ser manejadas por modelos de Inteligencia Artificial o directamente Robots o Humanos Digitales, haciendo muchas más funciones y actividades que lo que haría un simple "servicio".

Por lo tanto, tenemos una gran variedad en cuanto a su tipología y que además se ha incrementado significativamente en los últimos años, donde hemos pasado de tener la sorprendente proporción de 1 Identidad Humana por cada 10 Identidades No Humanas, que era la figura que reportaban los analistas en 2020, a una proporción de 1 Identidad Humana por cada 50 Identidades No Humanas en 2025. Donde a día de hoy, incluso ciertos analistas consideran que la figura puede ser mayor y en algunos casos la proporciona se reporta como 1 Identidad Humana por cada 80 Identidades No Humanas.

Figura 3: Datos del "2025 Identity Security Landscape de CyberARK"

Tras observar la tendencia creciente en la proporción de Identidades Humanas versus Identidades No Humanas, y por lo tanto la necesidad de gestionar y proteger cada vez más identidades no humanas, procedamos dar respuesta a la segunda de nuestras preguntas.  

¿Por qué son importantes las Identidades No Humanas?

Son importantes porque en la mayoría de los casos tienen un nivel de privilegios alto y porque la gestión de las mismas no siempre es la ideal, pensemos simplemente si en algún caso tenemos una cuenta de servicio en nuestro directorio activo donde las credenciales llevan tiempo sin rotarse o si tenemos alguna API configurada para su acceso con un Clientid + Secret y si los mismos están o han podido estar "hardcodeados" en algún código, seguro que todos tenemos casos y estoo sin querer meternos en la gestión de los agente de IA que hacen uso de las tools mediante MCP Servers o escenarios más novedosos y de los que somos menos conscientes y por lo tanto tenemos menos sistemas protección, detección respuesta.

¿Está aumentando el riesgo asociado a las Identidades No Humanas?

Una vez hemos llegado a este punto estaremos en posición de determinar si el riesgo con la Identidades No Humanas está en aumento, donde teniendo en cuenta su incremento exponencial en las empresas y organizaciones, combinado con que en muchos casos la identidad es la única capa de seguridad que se dispone, que además estas NHI suelen privilegiadas, y que no se cuenta en la mayoría de los casos con herramientas o sistemas que permitan tener un monitorización y/o trazabilidad del uso y comportamientos de ellas, podemos fácilmente afirmar que las Identidades No Humanas y especialmente aquellas que tengan unos privilegios más altos, representan un botín más grande sin son comprometidas y son un objetivo claro y en aumento para cibercriminales.

Figura 4: Ciberataque contra Dropbox Sign en Incibe

Hoy en día ya se conocen públicamente graves incidentes de seguridad que de una manera u otra están relacionadas con la gestión - o errores en esta mejor dicho - de las Identidades No Humanas, como por ejemplo el incidente  de seguridad que sufrió Beyondtrust con la API Key que usaba para varios clientes en software de soporte remoto o el incidente de seguridad con el servicio Dropbox sign tras ser comprometida una cuenta de servicio y sobre el cual el propio Incibe hacía eco.

Conclusiones sobre Identidades No Humanas

Concluimos pues que la gestión de las Identidades No Humanas no es simplemente una moda. Es realmente es un riesgo de seguridad de emergente que muy probablemente ira apareciendo como un riesgo residual, con un riesgo residual cada más alto en los análisis de riesgos de todo tipo de compañías si no se empiezan a implementar controles mitigantes, donde la acciones que deberíamos empezar a plantearnos desde ya para las Identidades No Humanas deberían ser:

• Descubrir: Para poder gestionar o realizar cualquier otra acción primero debemos conocer nuestras identidades no humanas y esto no es una tarea sencilla

• Inventariar y clasificar: Debemos al menos ser capaces de asignar un propietario de cada identidad no humana, así como distinguir las privilegiadas de las no privilegiadas

• Gestionar el ciclo de vida: Por supuesto asegurando la terminación de las identidades no humanas que ya no son necesarias, la creación de nuevas identidades siguiendo las fases pertinentes de aprobación y con un propietario asignado, e idealmente realizando una revisión de privilegios o permisos de manera periódica, idealmente cada 6 meses

• Gestión de credenciales: Aquí deberíamos tener en cuenta el rotado de credenciales, el cifrado, el almacenamiento de la mismas en vaults de secretos cuando proceda, así como evitar que los secretos estén en repositorios de código o similar donde puedan ser accedidos sin mayores controles.

Una vez que tengamos estos cuatro puntos conseguidos o medio conseguidos, ya podríamos pensar en escenarios más avanzados como la detección de anomalías de uso de Identidades No Humanas o la protección en tiempo real de las mismas.

Saludos,

Autor: Samuel López Trenado, especialista en Gestión de Identidades Digitales

Contactar con Samuel López Trenado