Examinar Directory e Identity Details de Sophos ITDR

El Directory de Sophos ITDR es el inventario de trabajo de las identidades, los grupos, los dispositivos y las aplicaciones que ITDR recopila de los proveedores de identidades conectados. Las tarjetas de métricas muestran el número de objetos supervisados; al hacer clic se abre la vista correspondiente. Para realizar una investigación, se pasa de este inventario general a los datos detallados del objeto mediante su nombre para mostrar.

Acceso rápido: En My Products > Identity > Directory, seleccionar primero la pestaña correcta, aplicar la búsqueda y los filtros y comprobar el origen de los datos. En el caso de un usuario, abrir Display Name y, a continuación, comprobar una hipótesis concreta en cada una de las secciones Summary, Activity Log, Findings, Insights, Group Membership y Dark Web Intelligence. Una sola etiqueta, un Risk Score alto o un inicio de sesión inusual son señales de priorización, pero no constituyen por sí solos una prueba de que la cuenta esté comprometida.

Aclarar los límites del producto antes de la investigación

El Directory de ITDR no es el servicio de directorio de Sophos Fusion (antes Sophos Central). Muestra el contexto de seguridad recopilado por la integración de ITDR o por el sensor de ITDR. En cambio, Global Settings > Platform > Directory service proporciona usuarios y grupos para las funciones y los productos compartidos de Central. De ello se derivan tres límites importantes:

• Una identidad que falta en el Directory de ITDR no se recupera repitiendo Central Directory Sync. Primero se comprueban la integración de ITDR, el inventario del proveedor y el estado de su recopilación.
• Un objeto del Directory de ITDR no es automáticamente un usuario administrado de Central y no implica que tenga asignado un producto ni instalado Sophos Endpoint.
• Los filtros, las etiquetas y la mera apertura de páginas de detalles en ITDR no modifican objetos de Microsoft Entra ID, Active Directory, Intune ni del directorio de Central. Las correcciones técnicas se realizan en el sistema que actúa como fuente de autoridad y después se validan en ITDR; de forma independiente, puede haber acciones de respuesta expresamente autorizadas a través de las opciones Actions previstas para ello.

Sophos XDR también tiene una finalidad diferente. El Directory de ITDR proporciona contexto de inventario, postura de seguridad e identidad. En cambio, una consulta o investigación de XDR correlaciona telemetría y eventos de las fuentes de datos compatibles. Por ello, Activity Log en Identity Details no es una cronología completa de XDR y un finding de ITDR no es automáticamente una detección de XDR. En una investigación de amenazas que abarque varios casos, los indicios confirmados de ITDR se correlacionan con los datos disponibles de XDR, Endpoint, Entra y la red, sin interpretar la ausencia de telemetría como un resultado sin anomalías.

Interpretar correctamente el inventario de Directory

El acceso desde My Products > Identity > Directory ofrece cuatro pestañas con funciones distintas:

Los campos de búsqueda restringen cada vista por nombre. La búsqueda y los filtros solo se aplican a los datos mostrados que ITDR ha recopilado. Por tanto, no encontrar resultados no demuestra ni que el objeto no exista en el proveedor ni que se haya eliminado. Antes de escalar el caso, se comprueban la ortografía, la pestaña, los filtros activos, el tenant del proveedor y el momento de la recopilación.

Buscar, ordenar y filtrar identidades

Identities puede mostrarse como una vista de tarjetas o de lista. De forma predeterminada, los usuarios se ordenan alfabéticamente. En el menú de ordenación se puede elegir, por ejemplo, Risk Score en orden descendente para encontrar las identidades que deben investigarse primero. Search Identities filtra por nombre.

Los filtros adecuados dependen de la investigación. Para una primera priorización, Status restringe los resultados según el estado de la cuenta comunicado por el proveedor de identidades, y Risk Severity, según el intervalo del Risk Score calculado. Is Admin indica el contexto de administrador establecido por el proveedor o a partir de los roles privilegiados detectados; Is VIP, la selección para VIP Monitoring; e Is Compromised, la existencia de filtraciones activas de credenciales. Is Dormant encuentra cuentas en las que no se ha registrado ningún inicio de sesión durante más de 90 días.

Para contextualizar la cuenta, están disponibles Department y Employee Type como atributos de la organización, siempre que el proveedor los suministre. Is Guest identifica una cuenta de invitado en el proveedor de identidades; Is Cloud Only, una cuenta que solo existe en el proveedor de identidades en la nube y no tiene identificadores locales. Has MFA, Has Passwordless MFA, Primary MFA Method y MFA Method proporcionan el contexto de MFA. Country y Region permiten filtrar por los atributos de ubicación mantenidos en el proveedor.

Un valor de filtro vacío no equivale a un resultado negativo. Si el proveedor no suministra un atributo, la licencia limita el acceso a la API o Microsoft aún no ha facilitado los datos actualizados, ITDR no puede rellenar el campo de forma fiable. Esto afecta especialmente a los datos de MFA, administración, dispositivos y actividad.

En la vista de tarjetas, la flecha situada al final de una tarjeta muestra información adicional; solo puede haber una tarjeta ampliada a la vez. En la vista de lista, la flecha de la izquierda amplía una fila. El menú de columnas permite fijar columnas, ajustar su tamaño automáticamente, restablecerlas, añadirlas o eliminarlas. Estos ajustes de visualización no modifican el objeto ni su evaluación.

Si se han autorizado previamente acciones de respuesta, están disponibles para un usuario a través de Actions en la tarjeta ampliada o de la columna Actions en la vista de lista. La disponibilidad de una opción o acción depende del estado de la identidad y de la configuración; además, su ejecución requiere los permisos de operador necesarios y el proceso interno de autorización. Los filtros, las etiquetas y la apertura de detalles siguen siendo funciones independientes que no realizan cambios. Después de ejecutar una acción, se comprueba el resultado en el proveedor que actúa como fuente de autoridad y, a continuación, el estado actualizado en ITDR.

Utilizar los iconos y las etiquetas como contexto, no como veredicto

Los iconos identifican User, MFA User, Deleted User, Locked User, Admin, Guest o Service. Las etiquetas adicionales describen propiedades diferentes y no deben interpretarse como una evaluación de riesgo conjunta: Admin significa que la cuenta se ha identificado como administradora; Guest indica un invitado en el tenant; Deleted User, un usuario eliminado en el proveedor; y Locked User, una cuenta desactivada.

MFA User indica que MFA está activado, Compromised señala una filtración activa de credenciales y Dormant Account identifica una cuenta sin inicios de sesión registrados en los últimos 90 días. Cloud Only significa que no existen identificadores locales; en el caso de Hybrid, hay identificadores locales que se sincronizan entre la nube y el entorno local. Human clasifica la identidad como un usuario humano y VIP identifica la configuración para VIP Monitoring.

No deben confundirse Human y Non-Human Identity (NHI). Una cuenta humana representa a una persona. Las NHI incluyen, en particular, Service Principals, aplicaciones y otras identidades de máquina. El icono Service aporta ese contexto en la vista de identidades; las Enterprise Applications locales del tenant se examinan en la pestaña Apps. Que un nombre para mostrar parezca corresponder a una persona o a un servicio no constituye una clasificación fiable.

Distinguir entre Application Object y Service Principal

Un Application Object de Microsoft Entra es la definición global de una aplicación registrada en su tenant de origen. Describe, entre otras cosas, la configuración de identidad de la aplicación y tiene un App ID, también denominado Client ID. En el caso de un Service Principal del tipo Application, este es la instancia local concreta de esa aplicación en un tenant determinado. Este tipo hace referencia al Application Object y determina en el tenant correspondiente qué puede hacer la aplicación, quién puede acceder a ella y a qué recursos puede acceder. Esta correspondencia no se aplica a todos los tipos de Service Principal: un Service Principal del tipo Managed identity no tiene ningún Application Object asociado; un Service Principal de tipo Legacy no tiene ningún registro de aplicación asociado.

La pestaña Apps muestra las Enterprise Applications que ITDR ha recuperado en el tenant de Entra supervisado, es decir, instancias locales del tenant relacionadas con aplicaciones, y no una mera segunda lista de registros de aplicaciones globales. De ello no se puede concluir ni que aparezcan todos los tipos de Service Principal de Entra ni que cada contexto NHI mostrado tenga un registro de aplicación. Una aplicación multi-tenant puede tener un Application Object en el tenant de origen, pero un Service Principal propio del tipo Application en cada uno de los tenants que la consumen. Por ello, deben compararse conjuntamente Display Name, el tenant, App/Client ID, Object ID, el propietario y los permisos. Que los nombres coincidan no significa que se trate del mismo objeto; diferentes Service Principals locales de este tipo pueden hacer referencia a la misma aplicación global.

Display Name abre App Details. Allí se comprueban los metadatos recuperados por ITDR, así como las tablas de propietarios de la aplicación, findings vinculados y permisos. Un permiso llamativo se valida en el proveedor frente a la finalidad empresarial prevista, el publisher, el consentimiento y el propietario responsable. La vista de Directory no revoca el consentimiento ni elimina permisos.

Examinar grupos y dispositivos

En Groups, la búsqueda puede restringirse con cuatro filtros: Deleted identifica grupos eliminados en el proveedor; Mail Enabled, grupos que pueden recibir correo electrónico; y Security Enabled, grupos que pueden controlar el acceso a recursos. Assignable to Roles identifica grupos a los que se pueden asignar roles.

Al hacer clic en Group Name, se abre Group Details con los metadatos del grupo recuperados y tablas de los usuarios, grupos y aplicaciones asociados. En una revisión de acceso, se confirman en el proveedor que actúa como fuente de autoridad el tipo de grupo, el propietario, las relaciones directas y anidadas y la necesidad empresarial. Mail Enabled no indica si un grupo se utiliza para asignar permisos; para ello es relevante Security Enabled.

En Devices, se pueden buscar dispositivos y filtrar por State, Ownership, Operating System, Architecture, Manufacturer, Model, Rooted, Managed y Compliant. La vista incluye dispositivos personales y corporativos registrados en Microsoft Entra ID. Un objeto de dispositivo es una identidad en el proveedor; Microsoft Entra registered, Microsoft Entra joined y Microsoft Entra hybrid joined son contextos diferentes de registro o unión y no equivalen a tener instalado Sophos Endpoint Agent.

Display Name abre Device Details. Según el tipo de dispositivo, la página muestra los metadatos recuperados, las identidades asociadas, los findings relevantes y otra información disponible. Managed, Compliant, Rooted u Ownership son datos del proveedor. Si faltan, el valor se documenta como no disponible o desconocido a efectos de la investigación. No deben deducirse de ello estados como «unmanaged», «non-compliant» o «not rooted», ni tampoco una propiedad personal o corporativa. Además, un valor ausente no equivale a un valor Unknown comunicado expresamente por el proveedor.

Examinar Identity Details de forma sistemática

En Identities, al hacer clic en Display Name se abre la página Identity Details. En lugar de leer cada pestaña sin una hipótesis, se recomienda el siguiente procedimiento:

1. Confirmar el objeto: comparar el nombre para mostrar, el estado, el tipo, las direcciones de correo electrónico y el contexto del proveedor con los datos del usuario esperado.
2. Comprender la prioridad: comprobar el Risk Score, los factores que contribuyen a él, los findings abiertos y el contexto de Compromised, Admin, MFA y Dormant. Una puntuación prioriza la investigación, pero no la sustituye.
3. Validar la coherencia del perfil y los activos: comparar el rol, el departamento, la región, la estructura organizativa y los dispositivos de Intune asignados con el perfil esperado.
4. Examinar la actividad: establecer el intervalo de tiempo y comprobar si hay desviaciones en los inicios de sesión correctos y fallidos, las horas, los países, las direcciones IP y los ASN.
5. Abrir las evidencias vinculadas: examinar por separado findings, detecciones, grupos y registros de la dark web, en lugar de deducir la causa a partir de un resumen.
6. Validar en el sistema que actúa como fuente de autoridad: contrastar los datos con Entra ID, AD local, Intune y, si procede, la telemetría de XDR. Después, realizar los cambios técnicos en el sistema correspondiente que actúa como fuente de autoridad. Si, en cambio, está prevista una respuesta de ITDR aprobada expresamente, utilizar para ello una opción Actions disponible.
7. Comprobar el resultado: después de la corrección o la respuesta, volver a comprobar el resultado en el proveedor y en ITDR, y documentar qué información ya se ha actualizado y cuál sigue pendiente del siguiente ciclo de recopilación.

Summary

Summary reúne el perfil, la prioridad y la actividad reciente. En Details aparecen los datos disponibles de Entra ID, como el rol, el departamento, el estado, el país y la región, la fecha y hora de creación y modificación, el último cambio de contraseña y otras direcciones de correo electrónico asociadas. Assets muestra los dispositivos de Intune asignados al usuario en Entra ID. Multi-Factor Authentication indica el proveedor de MFA, el método principal de MFA y los demás tipos de MFA configurados. Organization aporta el contexto organizativo con responsables, subordinados directos y la estructura de la organización; al hacer clic en una persona, se abre en una pestaña nueva.

Para la evaluación de seguridad, Recent Detections muestra las Open Detections de los últimos siete días y las Closed Detections de los últimos 30 días; View All lleva a Insights. Risk Score contiene la puntuación actual y los principales factores que contribuyen a ella. Top Sign-in Locations resume las ubicaciones de inicio de sesión más frecuentes con actividad de direcciones IP públicas y privadas. Cuando hay datos disponibles, Commonly Used Entities desglosa las autenticaciones correctas de los últimos 30 días por IP Addresses, Browser, Asset Name y OS Version.

En Top Sign-in Locations > View Details se muestran, para los últimos 30 días, sobre todo la ubicación geográfica, el ASN y la frecuencia de las principales direcciones IP. IP type y Login outcome se utilizan allí como filtros; no se da por supuesto que aparezcan como columnas de resultados. Las direcciones IP privadas no deben interpretarse geográficamente del mismo modo que las públicas. Una ciudad frecuente puede deberse a la salida de una VPN o de un servicio en la nube; un país desconocido puede justificar una comprobación, pero sin el contexto temporal, del dispositivo y del proveedor aún no constituye un incidente.

Activity Log

Activity Log muestra la actividad de autenticación correspondiente al intervalo seleccionado en la esquina superior derecha. Total Activities, Successful Logins y Failed Logins proporcionan en primer lugar el volumen. Para contextualizar la ubicación, Top sign-in locations muestra países, direcciones IP, el número de accesos y la distribución entre IP públicas y privadas. Authentication locations añade las autenticaciones más frecuentes de los últimos 30 días por dirección IP y ASN, así como una búsqueda por ubicación, IP o ASN. Logins per day, con los inicios de sesión correctos y fallidos por separado, y Activity map, como mapa de calor por día de la semana y hora del día, representan la evolución temporal.

Esta vista de ITDR resume agregados y patrones. No muestra una tabla de eventos en la que todos estos datos aparezcan juntos para cada inicio de sesión. En su lugar, Browser, Asset Name y OS Version deben evaluarse como agregados del perfil de autenticaciones correctas durante 30 días en Summary > Commonly Used Entities y no deben atribuirse a una entrada concreta de Activity Log. Para correlacionar eventos con la fecha y hora y la zona horaria exactas, el resultado, la IP de origen, el ASN, el país, el dispositivo, el navegador, el sistema operativo o las detecciones próximas en el tiempo, se utilizan los registros de eventos disponibles de Entra o XDR, según corresponda. Los intentos fallidos frecuentes en los agregados de ITDR pueden deberse a errores del usuario, credenciales obsoletas o un ataque; solo la correlación con evidencias de eventos permite determinarlo.

Findings, Insights, Group Membership y Dark Web Intelligence

Findings enumera los findings de esta identidad en función del riesgo. El texto completo de Recommendation aparece al pasar el cursor por encima; al hacer clic en el nombre del finding se abren los detalles. En ellos se comprueban el estado, el riesgo, la categoría, las evidencias afectadas y la remediación recomendada. Cambiar manualmente un estado no equivale a aplicar la remediación técnica en el proveedor.

Insights muestra de forma predeterminada las Open Detections de los últimos siete días; el intervalo puede modificarse con el Date Picker. Closed Detections abarca los últimos 30 días. Por tanto, un intervalo predeterminado vacío no descarta que exista actividad anterior.

Group Membership enumera los grupos del usuario. El campo de búsqueda restringe la lista; al hacer clic en Group Name, se abre el grupo y sus demás miembros. Son especialmente relevantes las pertenencias privilegiadas, asignables a roles, anidadas, inesperadas o que ya no son necesarias para la actividad empresarial. Los cambios se realizan en el proveedor que actúa como fuente de autoridad.

Dark Web Intelligence muestra los registros de filtraciones vinculados a la identidad. Breach Source abre el registro correspondiente. Un registro documenta la exposición de credenciales. Para contextualizarlo, deben examinarse conjuntamente el momento de la filtración, el contexto de la publicación o la brecha, el estado de la cuenta y el último cambio de contraseña. El registro no demuestra automáticamente que las credenciales utilizadas actualmente sean válidas ni que se haya producido un inicio de sesión.

Tener en cuenta los límites del proveedor y los tiempos de actualización

Sophos ITDR es compatible con Microsoft Entra ID y Active Directory local, pero no todos los proveedores suministran los mismos objetos y campos. Los datos específicos de la nube, como los activos de Intune, los Service Principals de Entra, los métodos MFA o la actividad de inicio de sesión de Entra, pueden faltar en una integración exclusivamente con AD local. A la inversa, el sensor local de ITDR recopila tipos de objetos de AD adicionales para las comprobaciones de postura de seguridad; esto no hace que las pestañas de la nube estén completas automáticamente.

Tras la recopilación completa inicial de Entra, ITDR comprueba las actualizaciones en intervalos distintos según el tipo de datos: los detalles de usuarios, Service Principals, aplicaciones, grupos y dispositivos aproximadamente cada diez minutos; la configuración de MFA, aproximadamente cada 15 minutos; el último inicio de sesión del usuario, aproximadamente cada seis horas; y los datos del dominio, aproximadamente cada 24 horas. Son intervalos de recopilación, no una garantía de que Microsoft ya proporcione a través de su API un dato de origen que se haya modificado.

Se requiere Entra ID P1 o P2 para obtener el conjunto de datos previsto de ITDR. Con Entra ID Free, las API y las comprobaciones de postura de seguridad están limitadas, por lo que una integración puede mostrar Provisioning Failed. Tras actualizar la licencia, los datos de administrador o de MFA de Microsoft pueden permanecer obsoletos hasta una semana. En este caso, se comprueba primero el informe de actividad correspondiente de Microsoft Entra. Si la propia vista del proveedor aún no está actualizada, ITDR todavía no puede mostrar un estado más reciente.

La MFA de terceros en una configuración anterior de Okta o Duo también puede aparecer como no protegida porque Entra no almacena la información de MFA a nivel de usuario. En ese caso, no debe interpretarse de forma aislada que Has MFA = false demuestra la ausencia de un control de MFA. Deben concordar la configuración del proveedor, Conditional Access, los External Authentication Methods actuales y una prueba de inicio de sesión controlada.

Validación y resolución de problemas

El objeto no aparece o figura en la pestaña incorrecta

1. Restablecer la búsqueda y los filtros activos, y comprobar la ortografía y los nombres para mostrar alternativos.
2. Comprobar si Identities, Groups, Devices o Apps corresponde al tipo de objeto correcto.
3. Confirmar el tenant y el proveedor de identidades que actúa como fuente de autoridad; en el caso de las aplicaciones, distinguir entre Application Object, Service Principal, App/Client ID y Object ID.
4. Buscar el objeto directamente en el proveedor y comprobar el estado, la eliminación y el contexto Guest, Cloud, Hybrid o Service.
5. Comprobar el estado y la última recopilación correcta en la configuración de la integración de ITDR. No reiniciar Central Directory Sync como sustituto.
6. Volver a comprobarlo únicamente después del intervalo de recopilación específico del tipo de datos y documentar las marcas de tiempo.

Un filtro o un campo relativo a MFA, al estado de administrador o a un dispositivo está vacío o muestra un valor inesperado

• Eliminar los filtros y comprobar el atributo sin procesar en el proveedor.
• Comprobar la licencia de Entra, la disponibilidad de la API y el estado de la integración.
• En el caso de MFA, comprobar además el proveedor, el método principal, los métodos adicionales y la configuración de terceros.
• En los dispositivos, distinguir entre el registro o la unión, la administración mediante Intune, el cumplimiento y la protección de Sophos Endpoint.
• Tras modificar una licencia o un atributo, validar primero la vista actualizada del proveedor y no solo ITDR.
• Documentar «vacío», No data o la ausencia de una etiqueta como un dato desconocido, no como un «no».

La ubicación de inicio de sesión o el patrón de actividad parecen sospechosos

En Activity Log, comparar primero el intervalo de tiempo, el volumen de inicios de sesión, los agregados de accesos correctos y fallidos, los países, las direcciones IP, el ASN y los patrones por día y hora. En Top Sign-in Locations, se pueden utilizar IP type y Login outcome como filtros.

Evaluar por separado Browser, Asset Name y OS Version en Commonly Used Entities como agregados de 30 días. A continuación, correlacionar la fecha y hora exactas y la zona horaria, así como el resultado, el dispositivo, el navegador y el sistema operativo de un inicio de sesión concreto, en los registros de eventos disponibles de Entra o XDR. Comprobar también los Findings y Insights asociados.

NAT, las VPN, las redes móviles, la salida a través de servicios en la nube y los viajes pueden cambiar la ubicación mostrada. Si se confirma el riesgo, ejecutar los pasos de respuesta únicamente de acuerdo con el proceso interno de gestión de incidentes y con los permisos necesarios.

Verificar la información mostrada tras una corrección

Confirmar primero el cambio técnico en el sistema que actúa como fuente de autoridad. Después, esperar a que transcurra el intervalo previsto de recopilación de ITDR, restablecer los filtros y volver a abrir la misma identidad o el mismo objeto. Se comprueban el campo corregido, las etiquetas dependientes, los findings asociados y el intervalo relevante de la investigación. El Risk Score, los findings y los atributos del proveedor pueden tener ciclos de actualización diferentes; que una puntuación aún no haya cambiado no refuta que el cambio en el origen se haya realizado correctamente. Si la información sigue siendo incorrecta una vez transcurrido el intervalo previsto, se guardan para el escalado la evidencia del proveedor, el tenant, el Object ID, la hora del cambio, el estado de la integración y las capturas de pantalla.

Cerrar la investigación de forma trazable

Para finalizar, documentar el objeto, el tenant, el proveedor y el tipo de identidad. Registrar también la búsqueda y los filtros utilizados, el intervalo de investigación, las áreas de detalle examinadas, los datos del proveedor que faltan y los resultados de la validación tanto en el sistema que actúa como fuente de autoridad como en ITDR. El contexto Human y NHI, así como Application Object y Service Principal, deben mantenerse separados.