Transición del entorno de Microsoft Sentinel al portal de Defender

Microsoft Sentinel está disponible en el portal de Microsoft Defender con Microsoft Defender XDR o por sí mismo. Ofrece una experiencia unificada en SIEM y XDR para una detección y respuesta de amenazas más rápida y precisa, flujos de trabajo más sencillos y una mejor eficiencia operativa.

En este artículo se explica cómo realizar la transición de la experiencia de Microsoft Sentinel desde el Azure Portal al portal de Defender. Si usa Microsoft Sentinel en el Azure Portal, realice la transición a Microsoft Defender para operaciones de seguridad unificadas y las características más recientes. Para obtener más información, consulte Microsoft Sentinel en el portal de Microsoft Defender o vea nuestra lista de reproducción de YouTube.

Nota:

La transición al portal de Defender, incluso para clientes que no son de E5, no tiene ningún costo adicional para el cliente. El cliente sigue facturando como de costumbre por su consumo solo en Sentinel.

Requisitos previos

Antes de empezar, tenga en cuenta lo siguiente:

  • Este artículo está destinado a los clientes con un área de trabajo existente habilitada para Microsoft Sentinel que desean realizar la transición de su experiencia de Microsoft Sentinel al portal de Defender. Si es un nuevo cliente que se incorporó con permisos de propietario de una suscripción o administrador de acceso de usuario, las áreas de trabajo se incorporarán automáticamente al portal de Defender.

  • Algunas características Microsoft Sentinel tienen nuevas ubicaciones en el portal de Defender. Para obtener más información, consulte Referencia rápida.

  • Cuando sea pertinente, los requisitos previos detallados se encuentran en los artículos vinculados de cada paso.

Planeamiento y configuración del entorno de transición

Audiencia: Arquitectos de seguridad

Vídeos:

Revisión de la guía de planeamiento, requisitos previos completos e incorporación

Revise todas las instrucciones de planeamiento y complete todos los requisitos previos antes de incorporar el área de trabajo al portal de Defender. Para más información, consulte los siguientes artículos:

Revisión de las diferencias de almacenamiento y privacidad de datos

Cuando se usa el Azure Portal, se aplican las directivas de Microsoft Sentinel para el almacenamiento de datos, el proceso, la retención y el uso compartido. Cuando se usa el portal de Defender, las directivas de Microsoft Defender XDR se aplican en su lugar, incluso cuando se trabaja con Microsoft Sentinel datos.

En la tabla siguiente se proporcionan detalles y vínculos adicionales para que pueda comparar experiencias en los portales de Azure y Defender.

Área de soporte técnico Portal de Azure Portal de Defender
BCDR Los clientes son responsables de replicar sus datos Microsoft Defender usa la automatización para BCDR en los paneles de control.
Procesamiento y almacenamiento de datos - Ubicación de almacenamiento de datos
- Regiones admitidas		 Ubicación de almacenamiento de datos
Retención de datos Retención de datos Retención de datos
Uso compartido de datos Uso compartido de datos Uso compartido de datos

Para más información, vea:

Incorporación al portal de Defender con claves administradas por el cliente (CMK)

Si ha habilitado CMK antes de la incorporación, al incorporar el área de trabajo habilitada para Microsoft Sentinel en el portal de Defender, todos los datos de registro del área de trabajo se seguirán cifrando con CMK, incluidos los datos recién ingeridos y anteriormente.

Las reglas analíticas y otros Sentinel contenido, como las reglas de automatización, también siguen estando cifradas con CMK. Sin embargo, las alertas e incidentes ya no se cifrarán con CMK después de la incorporación.

Para obtener más información sobre CMK, consulte Configuración de Microsoft Sentinel clave administrada por el cliente.

Importante

El cifrado de CMK no es totalmente compatible con los datos almacenados en el lago de datos de Microsoft Sentinel. Todos los datos ingeridos en el lago de datos,como tablas personalizadas o datos transformados, se cifran mediante claves administradas por Microsoft.

Configuración de la administración de varias áreas de trabajo y multiinquilino

Defender admite una o varias áreas de trabajo entre varios inquilinos a través del portal multiinquilino, que actúa como un lugar central para administrar incidentes y alertas, buscar amenazas entre inquilinos y permite que los asociados de servicios de seguridad administrados (MSSP) vean entre los clientes.

En escenarios de varias áreas de trabajo, el portal multiinquilino le permite conectar un área de trabajo principal y varias áreas de trabajo secundarias por inquilino. Incorpore cada área de trabajo al portal de Defender por separado para cada inquilino, al igual que la incorporación para un único inquilino.

Para más información, vea:

Configuración y revisión de la configuración y el contenido

Audiencia: Ingenieros de seguridad

Vídeo: Administración de conectores en Microsoft Defender

Confirmación y configuración de la recopilación de datos

Cuando Microsoft Sentinel se integra con Microsoft Defender, la arquitectura fundamental de la recopilación de datos y el flujo de telemetría permanece intacta. Los conectores existentes que se configuraron en Microsoft Sentinel, ya sea para Microsoft Defender productos u otros orígenes de datos, continúan funcionando sin interrupción.

Desde una perspectiva de Log Analytics, la integración de Microsoft Sentinel en Microsoft Defender no introduce ningún cambio en la canalización de ingesta o el esquema de datos subyacentes. A pesar de la unificación de front-end, el back-end de Microsoft Sentinel permanece totalmente integrado con Log Analytics para el almacenamiento de datos, la búsqueda y la correlación.

Las alertas relacionadas con los productos de Defender se transmiten directamente desde el conector de Microsoft Defender XDR para garantizar la coherencia. Asegúrese de que tiene incidentes y alertas de este conector activados en el área de trabajo. Una vez configurado este conector de datos en el área de trabajo, al desconectar el área de trabajo de Microsoft Defender también se desconecta el conector de Microsoft Defender XDR.

Nota:

Este cambio en los conectores da lugar a diferencias de esquema para algunas alertas. Para obtener una comparación detallada, consulte Diferencias de esquema de alertas: conector independiente frente a XDR.

Para obtener más información, consulte Conexión de datos de Microsoft Defender XDR a Microsoft Sentinel.

Integración con Microsoft Defender for Cloud

  • Si usa el conector de datos basado en inquilinos para Defender for Cloud, asegúrese de realizar acciones para evitar eventos y alertas duplicados.
  • Si usa en su lugar el conector heredado basado en suscripciones, asegúrese de no sincronizar incidentes y alertas con Microsoft Defender.

Para obtener más información, consulte Alertas e incidentes en Microsoft Defender.

Visibilidad del conector de datos en el portal de Defender

Después de incorporar el área de trabajo a Defender, los siguientes conectores de datos se usan para operaciones de seguridad unificadas y no se muestran en la página Conectores de datos del portal de Defender:

  • Microsoft Defender for Cloud Apps
  • Microsoft Defender para punto de conexión
  • Microsoft Defender for Identity
  • Microsoft Defender para Office 365 (versión preliminar)
  • Microsoft Defender XDR
  • Microsoft Defender basada en suscripciones para la nube (heredada)
  • Microsoft Defender basada en inquilinos para la nube (versión preliminar)

Estos conectores de datos siguen aparecen en Microsoft Sentinel en el Azure Portal.

Configuración del ecosistema

Aunque el Administrador de áreas de trabajo de Microsoft Sentinel no está disponible en el portal de Defender, use una de las siguientes funcionalidades alternativas para distribuir contenido como código entre áreas de trabajo:

De lo contrario, siga implementando paquetes de solución que incluyan varios tipos de contenido de seguridad desde el centro de contenido en el portal de Defender. Para obtener más información, consulte Detección y administración de Microsoft Sentinel contenido integrado.

Configuración de reglas de análisis

Microsoft Sentinel reglas de análisis están disponibles en el portal de Defender para la detección, configuración y administración. Las funcionalidades de las reglas de análisis siguen siendo las mismas, incluida la creación, actualización y administración a través del asistente, los repositorios y la API de Microsoft Sentinel. La correlación de incidentes y la detección de ataques de varias fases también siguen funcionando en el portal de Defender. La funcionalidad de correlación de alertas administrada por la regla de análisis de Fusion en la Azure Portal se controla mediante el motor de Defender XDR en el portal de Defender, que consolida todas las señales en un solo lugar.

Al pasar al portal de Defender, es importante tener en cuenta los siguientes cambios:

Característica Descripción
Reglas de detección personalizada Si tiene casos de uso de detección que implican datos Defender XDR y Microsoft Sentinel, donde no es necesario conservar Defender XDR datos durante más de 30 días, se recomienda crear reglas de detección personalizadas que consulten datos de Microsoft Sentinel y Defender XDR tablas.

Esto se admite sin necesidad de ingerir Defender XDR datos en Microsoft Sentinel. Para obtener más información, consulte Uso de Microsoft Sentinel funciones personalizadas en la búsqueda avanzada en Microsoft Defender.
Correlación de alertas En el portal de Defender, las correlaciones se aplican automáticamente a las alertas de datos Microsoft Defender y datos de terceros ingeridos de Microsoft Sentinel, independientemente de los escenarios de alerta.

Los criterios utilizados para correlacionar las alertas en un solo incidente forman parte de la lógica de correlación interna propietaria del portal de Defender. Para obtener más información, consulte Correlación de alertas y combinación de incidentes en el portal de Defender.
Agrupación de alertas y combinación de incidentes Aunque seguirá viendo la configuración de agrupación de alertas en las reglas de Análisis, el motor de correlación de Defender XDR controla completamente la agrupación de alertas y la combinación de incidentes cuando sea necesario en el portal de Defender. Esto garantiza una visión completa de la historia de ataque completa mediante la combinación de alertas pertinentes para ataques de varias fases.

Por ejemplo, varias reglas de análisis individuales configuradas para generar un incidente para cada alerta pueden dar lugar a incidentes combinados si coinciden con Defender XDR lógica de correlación.
Visibilidad de alertas Si tiene Microsoft Sentinel reglas de análisis configuradas para desencadenar solo alertas, con la creación de incidentes desactivada, estas alertas no estarán visibles en el portal de Defender.
Optimización de alertas Una vez que el área de trabajo de Microsoft Sentinel se incorpora a Defender, el motor de Defender XDR genera todos los incidentes, incluidos los de las reglas de análisis de Microsoft Sentinel. Como resultado, las funcionalidades de optimización de alertas del portal de Defender, que anteriormente solo estaban disponibles para Defender XDR alertas, ahora se pueden aplicar a las alertas de Microsoft Sentinel.

Esta característica le permite simplificar la respuesta a incidentes mediante la automatización de la resolución de alertas comunes, la reducción de falsos positivos y la minimización del ruido, para que los analistas puedan priorizar incidentes de seguridad significativos.
Fusion: detección avanzada de ataques multiestado La regla de análisis de Fusion, que en el Azure Portal, crea incidentes basados en correlaciones de alertas realizadas por el motor de correlación de Fusion, se deshabilita al incorporar Microsoft Sentinel al portal de Defender.

No pierde la funcionalidad de correlación de alertas porque el portal de Defender usa las funcionalidades de creación y correlación de incidentes de Microsoft Defender XDR para reemplazar las del motor de Fusion.

Para obtener más información, consulte Detección avanzada de ataques de varias fases en Microsoft Sentinel

Configuración de reglas y cuadernos de estrategias de automatización

En Microsoft Sentinel, los cuadernos de estrategias se basan en flujos de trabajo integrados en Azure Logic Apps, un servicio en la nube que le ayuda a programar, automatizar y organizar tareas y flujos de trabajo en todos los sistemas de toda la empresa.

Las siguientes limitaciones se aplican a Microsoft Sentinel reglas de automatización y cuadernos de estrategias al trabajar en el portal de Defender. Es posible que tenga que realizar algunos cambios en el entorno al realizar la transición.

Funcionalidad Description
Reglas de automatización con desencadenadores de alerta En el portal de Defender, las reglas de automatización con desencadenadores de alerta solo actúan en Microsoft Sentinel alertas.

Para obtener más información, consulte Desencadenador de creación de alertas.
Reglas de automatización con desencadenadores de incidentes Tanto en la Azure Portal como en el portal de Defender, se quita la propiedad de condición del proveedor de incidentes, ya que todos los incidentes tienen Microsoft XDR como proveedor de incidentes (el valor del campo ProviderName).

En ese momento, las reglas de automatización existentes se ejecutan en incidentes de Microsoft Sentinel y Microsoft Defender XDR, incluidos aquellos en los que la condición del proveedor de incidentes se establece en solo Microsoft Sentinel o Microsoft 365 Defender.

Sin embargo, las reglas de automatización que especifican un nombre de regla de análisis específico solo se ejecutan en incidentes que contienen alertas creadas por la regla de análisis especificada. Esto significa que puede definir la propiedad de condición de nombre de regla analítica en una regla de análisis que exista solo en Microsoft Sentinel para limitar la ejecución de la regla en incidentes solo en Microsoft Sentinel.

Además, después de incorporarse al portal de Defender, la tabla SecurityIncident ya no incluye un campo Descripción . Por lo tanto:

- Si usa este campo Descripción como condición para una regla de automatización con un desencadenador de creación de incidentes, esa regla de automatización no funcionará después de incorporarla al portal de Defender. En tales casos, asegúrese de actualizar la configuración correctamente. Para obtener más información, consulte Condiciones del desencadenador de incidentes.
- Si tiene una integración configurada con un sistema de vales externo, como ServiceNow, faltará la descripción del incidente.
Latencia en los desencadenadores del cuaderno de estrategias Los incidentes de Microsoft Defender pueden tardar hasta 5 minutos en aparecer en Microsoft Sentinel. Si este retraso está presente, el desencadenador del cuaderno de estrategias también se retrasa.
Cambios en los nombres de incidentes existentes El portal de Defender usa un motor único para correlacionar incidentes y alertas. Al incorporar el área de trabajo al portal de Defender, es posible que se cambien los nombres de incidentes existentes si se aplica la correlación. Para asegurarse de que las reglas de automatización siempre se ejecutan correctamente, se recomienda evitar el uso de títulos de incidentes como criterios de condición en las reglas de automatización y, en su lugar, sugerir que use el nombre de cualquier regla de análisis que haya creado alertas incluidas en el incidente y etiquetas si se requiere más especificidad.
Actualizado por campo
  • Después de incorporar el área de trabajo, el campo Actualizado por tiene un nuevo conjunto de valores admitidos, que ya no incluyen Microsoft 365 Defender. En las reglas de automatización existentes, Microsoft 365 Defender se reemplaza por un valor de Other después de incorporar el área de trabajo.

  • Si se realizan varios cambios en el mismo incidente en un período de 5 a 10 minutos, se envía una sola actualización a Microsoft Sentinel, con solo el cambio más reciente.

    Para obtener más información, consulte Desencadenador de actualización de incidentes.
    		•
    Creación de reglas de automatización directamente desde un incidente La creación de reglas de automatización directamente desde un incidente solo se admite en el Azure Portal. Si trabaja en el portal de Defender, cree las reglas de automatización desde cero desde la página Automatización .
    Reglas de creación de incidentes de Microsoft Las reglas de creación de incidentes de Microsoft no se admiten en el portal de Defender.

    Para obtener más información, consulte Microsoft Defender XDR incidentes y reglas de creación de incidentes de Microsoft.
    Ejecución de reglas de automatización desde el portal de Defender Puede tardar hasta 10 minutos desde el momento en que se desencadena una alerta y se crea o actualiza un incidente en el portal de Defender hasta que se ejecuta una regla de automatización. Este retraso se debe a que el incidente se crea en el portal de Defender y, a continuación, se reenvía a Microsoft Sentinel para la regla de automatización.
    Pestaña Cuadernos de estrategias activos Después de la incorporación al portal de Defender, de forma predeterminada, la pestaña Cuadernos de estrategias activos muestra un filtro predefinido con la suscripción del área de trabajo incorporada. En el Azure Portal, agregue datos para otras suscripciones mediante el filtro de suscripción.

    Para obtener más información, vea Crear y personalizar Microsoft Sentinel cuadernos de estrategias a partir de plantillas.
    Ejecución manual de cuadernos de estrategias a petición Los procedimientos siguientes no se admiten actualmente en el portal de Defender:
  • Ejecución manual de un cuaderno de estrategias en una alerta
  • Ejecución manual de un cuaderno de estrategias en una entidad
    		•
    La ejecución de cuadernos de estrategias en incidentes requiere Microsoft Sentinel sincronización Si intenta ejecutar un cuaderno de estrategias en un incidente desde el portal de Defender y ve el mensaje "No se puede acceder a los datos relacionados con esta acción. Actualice la pantalla en unos minutos", esto significa que el incidente aún no está sincronizado con Microsoft Sentinel.

    Actualice la página del incidente después de sincronizar el incidente para ejecutar el cuaderno de estrategias correctamente.
    Incidentes: adición de alertas a incidentes /
    Eliminación de alertas de incidentes    		 Dado que no se admite la adición de alertas a ni la eliminación de alertas de incidentes después de incorporar el área de trabajo al portal de Defender, estas acciones tampoco se admiten desde los cuadernos de estrategias. Para obtener más información, consulte Descripción de cómo se correlacionan las alertas y los incidentes se combinan en el portal de Defender.
    integración Microsoft Defender XDR en varias áreas de trabajo Si ha integrado datos XDR con más de un área de trabajo en un único inquilino, los datos ahora solo se ingieren en el área de trabajo principal en el portal de Defender. Transfiera las reglas de automatización al área de trabajo pertinente para mantenerlas en ejecución.
    Automatización y el motor de correlación El motor de correlación puede combinar alertas de varias señales en un único incidente, lo que podría dar lugar a la automatización de la recepción de datos que no anticipó. Se recomienda revisar las reglas de automatización para asegurarse de que ve los resultados esperados.

    Configuración de las API

    La experiencia unificada del portal de Defender presenta cambios notables en los incidentes y alertas de las API. Admite llamadas API basadas en la API REST de Microsoft Graph v1.0, que se pueden usar para la automatización relacionada con alertas, incidentes, búsqueda avanzada y mucho más.

    La API de Microsoft Sentinel sigue admitiendo acciones en Microsoft Sentinel recursos, como reglas de análisis, reglas de automatización y mucho más. Para interactuar con incidentes y alertas unificados, se recomienda usar la API REST de Microsoft Graph. Si usa la API de Microsoft Sentinel SecurityInsights para interactuar con incidentes Microsoft Sentinel, es posible que tenga que actualizar las condiciones de automatización y desencadenar criterios debido a cambios en el cuerpo de la respuesta.

    En la tabla siguiente se enumeran los campos que son importantes en los fragmentos de código de respuesta y se comparan en los portales de Azure y Defender:

    Funcionalidad Portal de Azure Portal de Defender
    Vínculo al incidente incidentUrl: dirección URL directa al incidente en el portal de Microsoft Sentinel providerIncidentUrl: este campo adicional proporciona un vínculo directo al incidente, que se puede usar para sincronizar esta información con un sistema de vales de terceros, como ServiceNow.

    incidentUrlsigue estando disponible, pero apunta al portal de Microsoft Sentinel.
    Los orígenes que desencadenaron la detección y publicaron la alerta alertProductNames alertProductNames: requiere agregar ?$expand=alerts a get.

    Por ejemplo: https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts
    Nombre del proveedor de alertas providerName= "Azure Sentinel" providerName = "Microsoft XDR"
    Servicio o producto que creó la alerta No existe en el Azure Portal serviceSource

    Por ejemplo, "microsoftDefenderForCloudApps"
    La tecnología de detección o sensor que identificó el componente o la actividad notables No existe en el Azure Portal detectionSource Por ejemplo, "cloudAppSecurity"
    Nombre del producto que publicó esta alerta No existe en el Azure Portal productNamePor ejemplo, "Microsoft Defender for Cloud Apps"

    Ejecución de operaciones en el portal de Defender

    Audiencia: Analistas de seguridad

    Vídeos:

    Actualización de los procesos de evaluación de prioridades de incidentes para el portal de Defender

    Si ha usado Microsoft Sentinel en el Azure Portal, observará mejoras significativas de la experiencia del usuario en el portal de Defender. Aunque es posible que tenga que actualizar los procesos de SOC y volver a entrenar a los analistas, el diseño consolida toda la información pertinente en un solo lugar para proporcionar flujos de trabajo más optimizados y eficientes.

    La cola de incidentes unificada del portal de Defender consolida todos los incidentes entre los productos en una sola vista, lo que afecta a la forma en que los analistas evalúan los incidentes que ahora contienen varias alertas de dominio entre seguridad. Por ejemplo:

    • Tradicionalmente, los analistas evalúan los incidentes en función de dominios de seguridad o conocimientos específicos, a menudo administran vales por entidad, como un usuario o un host. Este enfoque puede crear puntos ciegos, que la experiencia unificada pretende abordar.
    • Cuando un atacante se mueve lateralmente, las alertas relacionadas pueden terminar en incidentes independientes debido a distintos dominios de seguridad. La experiencia unificada elimina este problema al proporcionar una vista completa, lo que garantiza que todas las alertas relacionadas se correlacionan y administran de forma coherente.

    Los analistas también pueden ver los orígenes de detección y los nombres de producto en el portal de Defender, y aplicar y compartir filtros para una evaluación de incidentes y alertas más eficaz.

    El proceso de evaluación de prioridades unificada puede ayudar a reducir las cargas de trabajo de los analistas e incluso combinar potencialmente los roles de analistas de nivel 1 y nivel 2. Sin embargo, el proceso de evaluación de prioridades unificada también puede requerir un conocimiento más amplio y más profundo de los analistas. Se recomienda entrenar en la nueva interfaz del portal para garantizar una transición fluida.

    Para obtener más información, consulte Incidentes y alertas en el portal de Microsoft Defender.

    Descripción de cómo se correlacionan las alertas y los incidentes se combinan en el portal de Defender

    El motor de correlación de Defender combina incidentes cuando reconoce elementos comunes entre alertas en incidentes independientes. Cuando una nueva alerta cumple los criterios de correlación, Microsoft Defender agrega y la correlaciona con otras alertas relacionadas de todos los orígenes de detección en un nuevo incidente. Después de incorporar Microsoft Sentinel al portal de Defender, la cola de incidentes unificada revela un ataque más completo, lo que hace que los analistas sean más eficientes y proporcionen una historia de ataque completa.

    En escenarios de varias áreas de trabajo, solo las alertas de un área de trabajo principal se correlacionan con Microsoft Defender XDR datos. También hay escenarios específicos en los que no se combinan incidentes.

    Después de incorporar Microsoft Sentinel al portal de Defender, los siguientes cambios se aplican a incidentes y alertas:

    Característica Descripción
    Retraso justo después de incorporar el área de trabajo Los incidentes de Microsoft Defender pueden tardar hasta 5 minutos en integrarse completamente con Microsoft Sentinel. Esto no afecta a las características proporcionadas directamente por Microsoft Defender, como la interrupción automática de ataques.
    Reglas de creación de incidentes de seguridad Las reglas activas de creación de incidentes de seguridad de Microsoft se desactivan para evitar la creación de incidentes duplicados. La configuración de creación de incidentes en otros tipos de reglas de análisis permanece tal cual y se puede configurar en el portal de Defender.
    Nombre del proveedor de incidentes En el portal de Defender, el nombre del proveedor de incidentes siempre es Microsoft XDR.
    Adición o eliminación de alertas de incidentes La adición o eliminación de Microsoft Sentinel alertas hacia o desde incidentes solo se admite en el portal de Defender. Para quitar una alerta de un incidente en el portal de Defender, debe agregarla a otro incidente.
    Edición de comentarios Agregue comentarios a incidentes en Defender o Azure Portal, pero la edición de los comentarios existentes no se admite en el portal de Defender. Las modificaciones realizadas en los comentarios de la Azure Portal no se sincronizan con el portal de Defender.
    Creación manual y mediante programación de incidentes Los incidentes creados en Microsoft Sentinel a través de la API, mediante un cuaderno de estrategias de aplicación lógica o manualmente desde el Azure Portal, no se sincronizan con el portal de Defender. Estos incidentes se siguen admitiendo en la Azure Portal y la API. Consulte Creación manual de sus propios incidentes en Microsoft Sentinel.
    Reapertura de incidentes cerrados En el portal de Defender, no puede establecer la agrupación de alertas en Microsoft Sentinel reglas de análisis para volver a abrir incidentes cerrados si se agregan nuevas alertas.
    En este caso, los incidentes cerrados no se vuelven a abrir y las nuevas alertas desencadenan nuevos incidentes.

    Para obtener más información, consulte Incidentes y alertas en el portal de Microsoft Defender y Correlación de alertas y combinación de incidentes en el portal de Microsoft Defender.

    Tenga en cuenta los cambios en las investigaciones con la búsqueda avanzada

    Después de incorporar Microsoft Sentinel al portal de Defender, acceda y use todas las tablas de registro, consultas de Lenguaje de consulta Kusto (KQL) y funciones existentes en la página Búsqueda avanzada. Todas las alertas Microsoft Sentinel asociadas a incidentes se ingieren en la tabla, a las AlertInfo que se puede acceder desde la página Búsqueda avanzada.

    Existen algunas diferencias, como que los marcadores no se admiten en la búsqueda avanzada. En su lugar, los marcadores se admiten en el portal de Defender en Microsoft Sentinel > Búsqueda de administración de > amenazas.

    Para obtener más información, vea Búsqueda avanzada con datos de Microsoft Sentinel en Microsoft Defender, especialmente la lista de problemas conocidos, y Seguimiento de datos durante la búsqueda con Microsoft Sentinel.

    Investigación con entidades en el portal de Defender

    En el portal de Microsoft Defender, las entidades suelen ser recursos, como cuentas, hosts o buzones de correo, o pruebas, como direcciones IP, archivos o direcciones URL.

    Después de incorporar Microsoft Sentinel al portal de Defender, las páginas de entidad para usuarios, dispositivos y direcciones IP se consolidan en una sola vista con una vista completa de la actividad y el contexto de la entidad y los datos de Microsoft Sentinel y Microsoft Defender XDR.

    El portal de Defender también proporciona una barra de búsqueda global que centraliza los resultados de todas las entidades para que pueda buscar en SIEM y XDR.

    Para obtener más información, vea Páginas de entidad en Microsoft Sentinel.

    Investigación con UEBA en el portal de Defender

    La mayoría de las funcionalidades de Análisis de comportamiento de usuarios y entidades (UEBA) siguen siendo las mismas en el portal de Defender que en el Azure Portal, con las siguientes excepciones:

    • La adición de entidades a la inteligencia sobre amenazas a partir de incidentes solo se admite en el Azure Portal. Para obtener más información, vea Agregar entidad a indicadores de amenazas.

    • Al incorporar Microsoft Sentinel al portal de Microsoft Defender, la IdentityInfo tabla está disponible tanto en la experiencia de búsqueda avanzada de Microsoft Defender como en el área de trabajo de Log Analytics de Sentinel. La IdentityInfo tabla usada en Búsqueda avanzada incluye campos unificados de Defender XDR y Microsoft Sentinel. Algunos campos que existen en la tabla del área de trabajo de Sentinel Log Analytics se cambian de nombre o no se admiten en la tabla Búsqueda avanzada. Asegúrese de revisar y actualizar las consultas que se ejecutan en Microsoft Defender, como consultas de búsqueda avanzada o detecciones personalizadas. Microsoft Sentinel reglas analíticas, libros y otras consultas de Sentinel siguen usando la IdentityInfo tabla en el área de trabajo de Log Analytics y no se ven afectadas. Para obtener más información y una comparación de los esquemas de tabla en La experiencia de búsqueda avanzada y Log Analytics, vea Tabla IdentityInfo.

    Importante

    Al realizar la transición al portal de Defender, la IdentityInfo tabla se convierte en una tabla nativa de Defender que no admite el control de acceso basado en rol (RBAC) de nivel de tabla. Si su organización usa RBAC de nivel de tabla para restringir el acceso a la IdentityInfo tabla en el Azure Portal, este control de acceso dejará de estar disponible después de realizar la transición al portal de Defender.

    Actualizar los procesos de investigación para usar Microsoft Defender inteligencia sobre amenazas

    Para Microsoft Sentinel clientes que pasan de la Azure Portal al portal de Defender, las conocidas características de inteligencia sobre amenazas se conservan en el portal de Defender en Administración de Intel y se mejoran con otras características de inteligencia sobre amenazas disponibles en el portal de Defender. Las características admitidas dependen de las licencias que tenga, como:

    Característica Descripción
    Análisis de amenazas Compatible con Microsoft Defender XDR clientes. Una solución en el producto proporcionada por investigadores de seguridad de Microsoft, diseñada para ayudar a los equipos de seguridad ofreciendo información sobre las amenazas emergentes, las amenazas activas y sus impactos. Los datos se presentan en un panel intuitivo con tarjetas, filas de datos, filtros y mucho más.
    Perfiles de Intel Compatible con clientes Inteligencia contra amenazas de Microsoft Defender. Clasifique las amenazas y los comportamientos por un perfil de actor de amenazas, lo que facilita el seguimiento y la correlación. Estos perfiles incluyen todos los indicadores de riesgo (IoC) relacionados con tácticas, técnicas y herramientas utilizadas en los ataques.
    Explorador intel Compatible con clientes Inteligencia contra amenazas de Microsoft Defender. Consolida los ioC disponibles y proporciona artículos relacionados con amenazas a medida que se publican, lo que permite a los equipos de seguridad mantenerse actualizados sobre las amenazas emergentes.
    Proyectos de Intel Compatible con clientes Inteligencia contra amenazas de Microsoft Defender. Permite a los equipos consolidar la inteligencia sobre amenazas en un "proyecto" para revisar todos los artefactos relacionados con un escenario específico de interés.

    En el portal de Defender, use y ThreatIntelIndicators junto con Indicadores de compromiso para la ThreatIntelOjbects búsqueda de amenazas, la respuesta a incidentes, Copilot, la generación de informes y para crear gráficos relacionales que muestren las conexiones entre indicadores y entidades.

    Para los clientes que usan la fuente de Inteligencia contra amenazas de Microsoft Defender (MDTI), hay disponible una versión gratuita a través del conector de datos de Microsoft Sentinel para MDTI. Los usuarios con licencias MDTI también pueden ingerir datos mdti y usar Security Copilot para el análisis de amenazas, la revisión activa de amenazas y la investigación del actor de amenazas.

    Para más información, vea:

    Uso de libros para visualizar e informar sobre Microsoft Defender datos

    Azure libros siguen siendo la herramienta principal para la visualización de datos y la interacción en el portal de Defender, funcionando como lo hacían en el Azure Portal.

    Para usar libros con datos de búsqueda avanzada, asegúrese de ingerir registros en Microsoft Sentinel.

    Para obtener más información, consulte Visualización y supervisión de los datos mediante libros en Microsoft Sentinel.

    No se admiten incidentes similares (versión preliminar) en el portal de Defender

    La Microsoft Sentinel característica de incidentes similares está en versión preliminar, no se admite en el portal de Defender. Esto significa que al ver una página de detalles de incidentes en el portal de Defender, la pestaña Incidentes similares no está disponible.

    Contenido relacionado

    • Last updated on