Investigar y gestionar hallazgos de Sophos ITDR

En My Products > Identity > Findings, Sophos ITDR muestra los resultados de las comprobaciones de la infraestructura de identidad conectada. De forma predeterminada, la tabla se ordena por riesgo. Un hallazgo no demuestra por sí solo que exista un compromiso activo, ni es una XDR Detection o un XDR Case. Es un elemento de trabajo de ITDR que debe evaluarse, corregirse en el sistema de identidad correspondiente y comprobarse de nuevo.

El flujo de trabajo seguro es el siguiente:

1. Priorice los hallazgos abiertos según Risk y utilice filtros para crear una cola de trabajo manejable.
2. Lea Finding Details, Description, Definition y Recommendation; si es necesario, revise los datos sin procesar de Result y los cambios de History.
3. Evalúe el impacto y las dependencias en su entorno antes de cambiar una configuración.
4. Corrija la causa en el sistema o servicio de identidad afectado, en lugar de limitarse a cambiar el estado en ITDR.
5. Valide el estado primero en el proveedor y después en ITDR.
6. Establezca un hallazgo en Resolved o Dismissed únicamente como decisión consciente. Cambiarlo manualmente a Resolved no constituye una corrección.

Interpretar correctamente los estados, niveles de riesgo y categorías

Estado

ITDR deja de contabilizar los hallazgos Resolved y Dismissed como riesgos para el entorno. Sin embargo, ambos estados son distintos desde el punto de vista operativo: Resolved representa una causa corregida o un riesgo reducido, mientras que Dismissed representa una decisión consciente sobre el riesgo.

Riesgo

El nivel de riesgo procede de la comprobación subyacente y ayuda a establecer prioridades. Dentro de un mismo nivel, investigue primero las identidades con privilegios expuestas, los indicios de credenciales comprometidas y los hallazgos de gran alcance. La Recommendation específica sigue siendo más importante que cualquier medida genérica.

Categoría

ITDR utiliza las categorías siguientes. Sus nombres no cambian en la interfaz de Sophos en inglés:

• User Behavior
• Configuration
• Entra Conditional Access Gaps
• Dormant Resources
• Lateral Movement
• Credential Compromise
• Persistence
• Privilege Escalation
• Defense Evasion
• Exfiltration
• VIP Exposure

La categoría describe el tipo de comprobación y, cuando corresponde, puede ajustarse al modelo MITRE ATT&CK. No sustituye al análisis detallado ni a la verificación de si una configuración observada es intencionada en su entorno.

Filtrar los hallazgos y crear una cola de trabajo

El menú de filtros plegable situado a la izquierda de la tabla Identity Findings combina los filtros siguientes:

• Risk: nivel de riesgo del hallazgo.
• Status: Open, Resolved o Dismissed.
• Reference Type: tipo de objeto afectado.
• Category: categoría del hallazgo.
• Is New: hallazgos observados por primera vez durante los últimos siete días.
• Finding: título del hallazgo.
• First Seen: momento de la primera observación.
• Last Seen: momento de la última observación.
• Last Modified: momento del último cambio.

Para Reference Type están disponibles exactamente estos valores:

• User Object
• Application
• Group Object
• Device Object
• Tenant Configuration

Los filtros seleccionados aparecen encima de la tabla. Utilice X para quitar un filtro y Clear All para quitarlos todos. La tabla y la URL se actualizan dinámicamente según la selección. Por tanto, puede guardar una URL filtrada como vista de trabajo o compartirla con sus compañeros. Antes de compartirla, compruebe que los destinatarios tienen acceso al mismo tenant de Central y que está permitido incluir la URL en el ticket previsto.

Una cola de trabajo inicial útil es Status = Open, seguida de Risk = Critical o High. Después, acote los resultados mediante Category, Reference Type o Is New. De este modo, los nuevos riesgos críticos para las identidades permanecen visibles sin perder los elementos abiertos más antiguos.

Investigar un hallazgo en profundidad

Al hacer clic en el enlace de la columna Findings, se abre el panel de detalles. Este muestra el objeto asociado, el riesgo, First Seen, Last Seen, Last Modified y la recomendación. Utilice el icono New Tab para abrir la página completa en una pestaña nueva.

El panel y la vista completa incluyen:

• Finding Details: resumen con el nivel de riesgo, el estado, los comentarios, las marcas de tiempo y las etiquetas.
• Description: descripción del hallazgo.
• Definition: información sobre la comprobación de identidad asociada y sus referencias.
• Recommendation: recomendación de Sophos para reducir el riesgo específico.

Para realizar un triaje fiable, responda al menos a estas preguntas:

1. ¿Qué objeto está afectado y coincide Reference Type con el objeto esperado?
2. ¿Sigue presente en el proveedor de identidad la condición descrita en Description y Definition?
3. ¿Cuál es el alcance de los permisos y cuáles son las dependencias y los posibles efectos de un cambio?
4. ¿Es adecuada la Recommendation para su entorno y está autorizado internamente el cambio?
5. ¿Indican First Seen, Last Seen y Last Modified un problema nuevo, recurrente o ya tratado?

Finding Details muestra comentarios y etiquetas. Sin embargo, la documentación de Sophos sobre la página Findings no describe ninguna función de asignación ni controles para crear o modificar comentarios y etiquetas. Por tanto, la responsabilidad y las pruebas de los cambios deben registrarse en el sistema aprobado de gestión de cambios o tickets; los comentarios no sustituyen ni a un ticket de cambio ni a la prueba del cambio en el sistema de origen.

Revisar Result como datos sin procesar

La pestaña Result muestra en formato JSON la salida sin procesar de la comprobación ejecutada. Resulta especialmente útil cuando el resumen no permite determinar qué atributo, objeto o resultado dio lugar a la evaluación.

Interprete las claves y los valores JSON como la salida de esa comprobación concreta; no deduzca de ellos un esquema general. Compare los identificadores de objetos, estados y marcas de tiempo relevantes con la información actual del proveedor de identidad. Los datos sin procesar confidenciales solo deben incluirse en tickets o notas de investigación aprobados.

Seguir los cambios mediante History

La pestaña History muestra las acciones anteriores sobre el hallazgo. Seleccione View Diff para abrir los cambios exactos. Allí puede seguir los cambios de estado y otros pasos del tratamiento, lo que permite distinguir una reapertura inesperada de un hallazgo nuevo.

Corregir la causa y validar el resultado

⚠️ Revisar antes de realizar cambios: una recomendación de Sophos debe ser adecuada para su entorno, su tolerancia al riesgo y su proceso de aprobación de cambios. Los cambios en roles, autenticación, acceso condicional, aplicaciones u otros objetos de identidad pueden afectar a usuarios, aplicaciones y accesos. Por ello, aclare las dependencias y el plan de reversión antes de la implementación.

La corrección se realiza en el sistema donde ITDR detectó el problema, por ejemplo, el proveedor de identidad conectado o el servicio de aplicaciones correspondiente. El estado de ITDR solo controla el flujo de trabajo de los hallazgos. No cambia la configuración del proveedor.

Un cierre controlado consta de cuatro pasos:

1. Comprobar el estado del proveedor: confirme que el cambio autorizado se ha guardado y es efectivo para el objeto afectado.
2. Volver a comprobar el hallazgo: revise el objeto asociado, Last Seen, Result y History. Un resultado obsoleto o sin cambios no demuestra que la intervención haya funcionado.
3. Esperar al comportamiento automático: si el hallazgo deja de aparecer en una nueva comprobación, ITDR lo resuelve automáticamente y añade un comentario. Las comprobaciones de postura de Entra ID y de recursos inactivos suelen ejecutarse cada dos horas; el Risk Posture Score de toda la organización se actualiza a diario.
4. Documentar el resultado: registre las pruebas del proveedor, el estado del hallazgo, la marca de tiempo y, cuando corresponda, View Diff en el registro de trabajo aprobado. Si el hallazgo continúa abierto después del intervalo de comprobación previsto, vuelva a comparar el estado del proveedor, el objeto afectado y el resultado JSON, en lugar de cambiar repetidamente el estado de forma manual.

El sistema puede devolver a Open un hallazgo establecido manualmente en Resolved en cuanto ITDR vuelva a observar la misma condición. No se trata de un error del modelo de estados, sino de una indicación de que la causa continúa presente, ha reaparecido o todavía es visible en los datos que evalúa ITDR.

Utilizar Dismissed solo como decisión consciente sobre el riesgo

⚠️ Dismissed impide que se generen más hallazgos: si se descarta un hallazgo, ITDR no crea hallazgos nuevos para ese problema en el objeto afectado. El hallazgo permanece en la tabla, pero se excluye del panel y del Risk Posture Score de toda la organización. Por tanto, un descarte prematuro puede ocultar de la vista habitual un riesgo que todavía existe o que vuelva a ser relevante.

Dismissed solo es apropiado cuando la condición es esperada, se ha demostrado que la corrección es imposible o no está justificada desde el punto de vista operativo, y la parte responsable acepta el riesgo residual. Como mínimo, documente fuera de ITDR el objeto, la justificación, los controles compensatorios, la aprobación y la fecha de revisión. Como alternativa, un hallazgo que no pueda resolverse técnicamente puede permanecer Open, con lo que el riesgo seguirá visible en la puntuación y en la supervisión continua.

Priorizar Credential Compromise

Los hallazgos de cuentas comprometidas solo se generan para identidades activas. Entre otros factores, ITDR comprueba si existe una identidad activa, cuándo se filtró por primera vez una contraseña en texto sin formato o un hash y si esa fecha es posterior al último cambio de contraseña. Los valores en texto sin formato también se contrastan con los requisitos globales de complejidad de contraseñas de Microsoft Entra ID. Los datos sin procesar pueden seguir visibles en Dark Web Intelligence, independientemente de que se genere un hallazgo.

Cuando se genera un hallazgo, ITDR determina el nivel de riesgo según el tipo de cuenta, el tipo de filtración y la solidez de MFA:

Para establecer prioridades, trate primero los hallazgos Critical y después los High; dentro de un mismo nivel, investigue antes las cuentas con privilegios y las filtraciones de texto sin formato. Una clasificación inferior cuando existe MFA o MFA resistente al phishing no significa que pueda ignorarse el hallazgo. Aplique las medidas de protección y corrección aprobadas en el sistema de identidad correspondiente y conforme a su proceso de respuesta a incidentes. Después, valide el estado del proveedor, el hallazgo y el historial como se ha descrito anteriormente. El estado por sí solo no confirma que una identidad sea segura.

Separar las responsabilidades del cliente, MDR y XDR

Sophos ITDR es una solución supervisada por el cliente. Incluso si Sophos MDR se licencia por separado, el triaje y la gestión rutinarios de los hallazgos siguen siendo responsabilidad del cliente. El MDR Operations Team se centra en amenazas activas para las identidades y puede incluir en su investigación determinados hallazgos críticos o de riesgo alto si indican una amenaza activa. Esto no supone que asuma automáticamente todos los hallazgos ni que realice cambios en el proveedor de identidad.

Por tanto, para cada hallazgo escalado debe documentarse claramente:

• quién es responsable del triaje y de las decisiones sobre el riesgo;
• quién autoriza y ejecuta los cambios en el sistema de identidad;
• si se ha trasladado al proceso MDR acordado algún indicio de una amenaza activa;
• quién realiza la validación final del efecto técnico y del estado de ITDR.

Los hallazgos de ITDR permanecen separados de XDR Detections y XDR Cases. El contexto de identidad puede contribuir a una investigación más amplia. Sin embargo, el estado, los comentarios y el cierre del hallazgo de ITDR siguen perteneciendo al flujo de trabajo de ITDR y no equivalen al flujo de trabajo de XDR o MDR.