Examinar Directory e Identity Details de Sophos ITDR

El Directory de Sophos ITDR es el inventario de trabajo de las identidades, las identidades no humanas (NHI), los grupos y los dispositivos 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 o Guest. 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, una cuenta eliminada 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.

Human y Non Human son etiquetas de clasificación, no niveles de riesgo. Una cuenta humana representa a una persona. Las NHI incluyen, en particular, Service Principals, aplicaciones, Agent Identities, Agent Identity Blueprints y otras identidades de máquina. Los objetos NHI se investigan en Non-Human Identities. En cambio, una cuenta de usuario opcional emparejada con un agente aparece en Identities con la etiqueta Agent Identity. 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 vista Non-Human Identities incluye las Enterprise Applications, otros Service Principals y los objetos de Microsoft Entra Agent ID que ITDR ha recuperado del tenant de Entra supervisado. No se limita a los Service Principals del tipo Application ni es una segunda lista de registros de aplicaciones globales. Sin embargo, esto no garantiza que ya se hayan recopilado todos los objetos existentes en el proveedor. No todos los contextos NHI mostrados tienen 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 varios 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.

Filtrar NHI y consultar Non-Human Identity Details

Search Non-Human Identities restringe la vista por nombre. Para una investigación específica se dispone de los siguientes filtros:

• Status: estado en el proveedor, por ejemplo Active, Disabled o Deleted.
• Resource Type: tipo de objeto subyacente, por ejemplo Application, ServiceIdentity, ManagedIdentity, SocialIdp o Legacy. Estos valores de la interfaz no garantizan que exista un registro de aplicación asociado.
• Has Password Credentials: si hay una credencial de contraseña configurada.
• Has Key Credentials: si hay una credencial de certificado configurada.
• Is Agent: si el objeto se clasifica como Agent Identity o Agent Identity Blueprint Principal.
• Agent Type: selección de Agent Identity o Blueprint Principal.

Para examinar el inventario de agentes, se puede empezar por Is Agent, seleccionar el Agent Type necesario y abrir Display Name. Los filtros de credenciales describen la configuración del objeto concreto, no la validez de sus credenciales ni una prueba de autenticación satisfactoria. En el caso de los agentes, también debe examinarse el blueprint del que dependen; un agente sin contraseña propia no es automáticamente un objeto sin posibilidades de acceso.

Display Name abre Non-Human Identity Details. En Details, el nombre para mostrar enlaza con el objeto en Microsoft Entra admin center. Status indica activo, desactivado o eliminado; Type, el tipo de recurso subyacente, como Application o ServiceIdentity. Created At, Updated At y Deleted At sitúan en el tiempo el ciclo de vida del objeto. Estos metadatos no son eventos de inicio de sesión.

App Owners enumera usuarios o Service Principals con control administrativo técnico sobre las credenciales, la configuración y los permisos. Cada entrada muestra el nombre para mostrar, el tipo de usuario, el rol, el departamento y el estado. Findings contiene los findings asociados a la NHI, ordenados por riesgo; al hacer clic se abren sus detalles. Para las decisiones de estado y la validación posterior, se sigue el flujo de trabajo de findings.

En Permissions se distinguen Application Permissions —permisos app-only concedidos directamente— y Delegated Permissions, que se aplican en nombre de un usuario que ha iniciado sesión. Ambas tablas muestran el nombre de la API, el valor del claim, el permiso, el tipo de permiso y la fecha de concesión. 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.

Agent Identity Blueprint, Blueprint Principal e identidad de ejecución

Un agente basado en Microsoft Entra Agent ID consta de objetos relacionados, no de un único registro de aplicación:

• El Agent Identity Blueprint es el contenedor de credenciales y políticas a partir del cual se aprovisionan uno o varios agentes. Contiene las credenciales.
• El Blueprint Principal es el registro que se crea en el tenant al añadir el blueprint. Permite administrar y auditar el blueprint en ese tenant.
• La Agent Identity es la identidad de ejecución real del agente de IA. No conserva una contraseña ni un secreto propios, sino que se autentica mediante un token a través del blueprint del que depende.

Para Agent Identities y Blueprint Principals, Details muestra además Agent: Yes y Semantic role con Agent Identity o Blueprint Principal. En los detalles de NHI, Blueprint lineage solo está presente para Agent Identities y enlaza con el Blueprint Principal correspondiente. A la inversa, la pestaña Child Identities de un Blueprint Principal muestra todas las Agent Identities aprovisionadas a partir de él. Así se pueden identificar los agentes dependientes antes de modificar el blueprint compartido. Un finding en una sola identidad de ejecución no permite concluir, sin comprobarlo, que el mismo problema afecta a todas las Child Identities.

Examinar App Owners y Sponsors por separado

La pestaña Sponsors aparece para Agent Identities y Blueprint Principals. Enumera usuarios o grupos responsables de la finalidad y del ciclo de vida del agente, sin que esta relación les conceda acceso administrativo técnico. En cambio, App Owners administra técnicamente las credenciales, la configuración y los permisos. Por tanto, una asignación como sponsor no autoriza a modificar el objeto.

En un traspaso, se aclara la decisión empresarial con los Sponsors y la implementación técnica con los App Owners. Por ejemplo, un cambio de credenciales previsto en un blueprint compartido no afecta solo al agente investigado: primero se sigue Blueprint lineage, se comprueba Child Identities en el Blueprint Principal y se contrastan las finalidades afectadas y las dependencias de acceso con los responsables. Los cambios se realizan únicamente en el sistema de referencia y tras su aprobación; un cambio de estado en ITDR no sustituye esta comprobación.

La cuenta de usuario del agente emparejada en Identities

Microsoft ofrece de forma opcional un agent’s user account, por ejemplo para tareas de buzón o similares a las de Teams en las que el agente debe actuar como usuario. Esta cuenta está emparejada con una Agent Identity, pero se comporta como un usuario y no como un Service Principal. Por eso ITDR la muestra en Identities con la etiqueta Agent Identity y abre Identity Details, no la página de detalles de NHI.

En Summary > Details, esta cuenta muestra Agent: Yes para indicar el emparejamiento y Blueprint lineage como referencia al blueprint a partir del cual se aprovisionó la Agent Identity emparejada. La sección Sponsors indica los usuarios y grupos responsables del ciclo de vida y del acceso del agente emparejado. Actualmente, ITDR no muestra el rol de manager de Microsoft para estas cuentas; que no aparezca un manager no demuestra que no exista un responsable. Durante una investigación, la cuenta de usuario, la identidad de ejecución y la relación con el blueprint se documentan por separado y se contrastan en el proveedor.

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.

La identidad seleccionada aparece resaltada en el organigrama. Cada tarjeta de persona muestra el nombre, el rol y el departamento o equipo, los iconos y etiquetas pertinentes como Admin, el Risk Score actual en la esquina superior derecha y el número de findings abiertos por nivel de riesgo, o una indicación de que no hay ninguno. En una cuenta de usuario de agente también se comprueban los campos del agente y Sponsors descritos arriba; la estructura jerárquica humana no equivale a estas relaciones de responsabilidad.

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 Non-Human Identities es la vista correcta. La cuenta de usuario emparejada del agente pertenece a Identities; Agent Identity y Blueprint Principal, a la vista de NHI.
3. Confirmar el tenant y el proveedor de identidades de referencia; para las aplicaciones, distinguir Application Object, Service Principal, App/Client ID y Object ID; para los agentes, comprobar además Semantic role y Blueprint lineage.
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.