Partager via

Transition de votre environnement Microsoft Sentinel vers le portail Defender

Microsoft Sentinel est disponible dans le portail Microsoft Defender avec Microsoft Defender XDR ou lui-même. Il offre une expérience unifiée dans SIEM et XDR pour une détection et une réponse plus rapides et plus précises des menaces, des workflows plus simples et une meilleure efficacité opérationnelle.

Cet article explique comment migrer votre expérience Microsoft Sentinel du portail Azure vers le portail Defender. Si vous utilisez Microsoft Sentinel dans le portail Azure, passez à Microsoft Defender pour les opérations de sécurité unifiées et les dernières fonctionnalités. Pour plus d’informations, consultez Microsoft Sentinel dans le portail Microsoft Defender ou regardez notre playlist YouTube.

Note

La transition vers le portail Defender, même pour les clients non-E5, n’a aucun coût supplémentaire pour le client. Le client continue d’être facturé comme d’habitude pour sa consommation sur Sentinel uniquement.

Conditions préalables

Avant de commencer, notez :

  • Cet article concerne les clients disposant d’un espace de travail existant activé pour Microsoft Sentinel qui souhaitent migrer leur expérience Microsoft Sentinel vers le portail Defender. Si vous êtes un nouveau client qui est intégré avec les autorisations d’un propriétaire d’abonnement ou d’un administrateur d’accès utilisateur, vos espaces de travail sont automatiquement intégrés au portail Defender.

  • Certaines fonctionnalités de Microsoft Sentinel ont de nouveaux emplacements dans le portail Defender. Pour plus d’informations, consultez Informations de référence rapides.

  • En cas de pertinence, les conditions préalables détaillées se trouvent dans les articles liés pour chaque étape.

Planifier et configurer votre environnement de transition

Audience : Architectes de sécurité

Vidéos :

Passer en revue les conseils de planification, remplir les conditions préalables et intégrer

Passez en revue tous les conseils de planification et terminez toutes les conditions préalables avant d’intégrer votre espace de travail au portail Defender. Pour plus d’informations, consultez les articles suivants :

Examiner les différences de stockage et de confidentialité des données

Lorsque vous utilisez le portail Azure, les stratégies Microsoft Sentinel pour le stockage des données, le processus, la rétention et le partage s’appliquent. Lorsque vous utilisez le portail Defender, les stratégies Microsoft Defender XDR s’appliquent à la place, même lorsque vous utilisez des données Microsoft Sentinel.

Le tableau suivant fournit des détails et des liens supplémentaires pour vous permettre de comparer des expériences sur les portails Azure et Defender.

Zone de soutien Portail Azure Portail Defender
BCDR Les clients sont responsables de la réplication de leurs données Microsoft Defender utilise l’automatisation pour BCDR dans les volets de contrôle.
Stockage et traitement des données - Emplacement de stockage des données
- Régions prises en charge		 Emplacement de stockage des données
Conservation des données Conservation des données Conservation des données
Partage de données Partage de données Partage de données

Pour plus d’informations, consultez :

Intégration au portail Defender avec des clés gérées par le client (CMK)

Si vous avez activé CMK avant l’intégration, lorsque vous intégrez votre espace de travail avec Microsoft Sentinel au portail Defender, toutes les données de journal de votre espace de travail continuent d’être chiffrées avec CMK, y compris les données précédemment et nouvellement ingérées.

Les règles analytiques et d’autres contenus Sentinel, tels que les règles d’automatisation, continuent également d’être chiffrées par CMK. Toutefois, les alertes et les incidents ne seront plus chiffrés par CMK après l’intégration.

Pour plus d’informations sur CMK, consultez Configurer la clé gérée par le client Microsoft Sentinel.

Important

Le chiffrement CMK n’est pas entièrement pris en charge pour les données stockées dans le lac de données Microsoft Sentinel. Toutes les données ingérées dans le lac de données, telles que les tables personnalisées ou les données transformées, sont chiffrées à l’aide de clés gérées par Microsoft.

Configurer la gestion des espaces de travail et des locataires multiples

Defender prend en charge un ou plusieurs espaces de travail sur plusieurs locataires via le portail multilocataire, qui sert d’emplacement central pour gérer les incidents et les alertes, rechercher les menaces entre les locataires et permettre aux partenaires du service de sécurité managé (MSSP) de voir les clients.

Dans les scénarios multi-espaces de travail, le portail multilocataire vous permet de connecter un espace de travail principal et plusieurs espaces de travail secondaires par locataire. Intégrez chaque espace de travail au portail Defender séparément pour chaque locataire, comme pour l’intégration d’un seul locataire.

Pour plus d’informations, consultez :

  • Configurer la gestion multitenant de Microsoft Defender

  • Documentation Azure Lighthouse. Azure Lighthouse vous permet d’utiliser les données de Microsoft Sentinel provenant d’autres locataires dans les espaces de travail intégrés. Par exemple, vous pouvez exécuter des requêtes inter-espaces de travail avec l’opérateur workspace() dans les règles de repérage et d’analytique avancées.

  • Microsoft Entra B2B. Microsoft Entra B2B vous permet d’accéder aux données entre les locataires. GDAP n’est pas pris en charge pour les données Microsoft Sentinel.

Configurer et passer en revue vos paramètres et contenu

Audience : Ingénieurs de sécurité

Vidéo : Gestion des connecteurs dans Microsoft Defender

Confirmer et configurer la collecte de données

Lorsque Microsoft Sentinel est intégré à Microsoft Defender, l’architecture fondamentale de la collecte de données et du flux de télémétrie reste intacte. Les connecteurs existants qui ont été configurés dans Microsoft Sentinel, que ce soit pour les produits Microsoft Defender ou d’autres sources de données, continuent de fonctionner sans interruption.

Du point de vue de Log Analytics, l’intégration de Microsoft Sentinel à Microsoft Defender n’apporte aucune modification au pipeline d’ingestion ou au schéma de données sous-jacent. Malgré l’unification frontale, le back-end Microsoft Sentinel reste entièrement intégré à Log Analytics pour le stockage, la recherche et la corrélation des données.

Les alertes liées aux produits Defender sont diffusées directement à partir du connecteur Microsoft Defender XDR pour garantir la cohérence. Vérifiez que vous avez les incidents et alertes de ce connecteur activés dans votre espace de travail. Une fois que ce connecteur de données est configuré dans votre espace de travail, la désactivation de l’espace de travail de Microsoft Defender déconnecte également le connecteur Microsoft Defender XDR.

Pour plus d’informations, consultez Connecter des données de Microsoft Defender XDR à Microsoft Sentinel.

Intégrer à Microsoft Defender pour Cloud

  • Si vous utilisez le connecteur de données basé sur le locataire pour Defender pour Cloud, veillez à prendre des mesures pour empêcher les événements et alertes dupliqués.
  • Si vous utilisez plutôt le connecteur hérité basé sur l’abonnement, veillez à refuser la synchronisation des incidents et des alertes à Microsoft Defender.

Pour plus d’informations, consultez Alertes et incidents dans Microsoft Defender.

Visibilité du connecteur de données dans le portail Defender

Après avoir intégré votre espace de travail à Defender, les connecteurs de données suivants sont utilisés pour les opérations de sécurité unifiées et ne sont pas affichés dans la page connecteurs de données du portail Defender :

  • Microsoft Defender pour les applications cloud
  • Microsoft Defender pour Endpoint
  • Microsoft Defender pour l'Identité
  • Microsoft Defender pour Office 365 (préversion)
  • Microsoft Defender XDR
  • Microsoft Defender pour Cloud à abonnement (Version classique)
  • Microsoft Defender pour le cloud basé sur le locataire (préversion)

Ces connecteurs de données continuent d’être répertoriés dans Microsoft Sentinel dans le portail Azure.

Configurer votre écosystème

Bien que microsoft Sentinel’s Workspace Manager ne soit pas disponible dans le portail Defender, utilisez l’une des autres fonctionnalités suivantes pour distribuer du contenu en tant que code entre les espaces de travail :

Sinon, continuez à déployer des packages de solution qui incluent différents types de contenu de sécurité à partir du hub de contenu dans le portail Defender. Pour plus d’informations, consultez Découvrir et gérer le contenu prêt à l’emploi de Microsoft Sentinel.

Configurer des règles d’analyse

Les règles d’analytique Microsoft Sentinel sont disponibles dans le portail Defender pour la détection, la configuration et la gestion. Les fonctionnalités des règles d’analyse restent identiques, notamment la création, la mise à jour et la gestion via l’Assistant, les dépôts et l’API Microsoft Sentinel. La corrélation des incidents et la détection d’attaque à plusieurs étapes continuent également de fonctionner dans le portail Defender. La fonctionnalité de corrélation d’alerte gérée par la règle d’analytique Fusion dans le portail Azure est gérée par le moteur Defender XDR dans le portail Defender, qui consolide tous les signaux à un seul endroit.

Lorsque vous passez au portail Defender, les modifications suivantes sont importantes à noter :

Caractéristique Descriptif
Règles de détection personnalisées Si vous avez des cas d’usage de détection impliquant à la fois des données Defender XDR et Microsoft Sentinel, où vous n’avez pas besoin de conserver les données Defender XDR pendant plus de 30 jours, nous vous recommandons de créer des règles de détection personnalisées qui interrogent des données à partir de tables Microsoft Sentinel et Defender XDR.

Cela est pris en charge sans avoir à ingérer des données Defender XDR dans Microsoft Sentinel. Pour plus d’informations, consultez Utiliser des fonctions personnalisées Microsoft Sentinel dans la chasse avancée dans Microsoft Defender.
Corrélation des alertes Dans le portail Defender, les corrélations sont automatiquement appliquées aux alertes contre les données Microsoft Defender et les données tierces ingérées à partir de Microsoft Sentinel, quels que soient les scénarios d’alerte.

Les critères utilisés pour mettre en corrélation les alertes dans un seul incident font partie de la logique de corrélation interne propriétaire du portail Defender. Pour plus d’informations, consultez corrélation des alertes et fusion des incidents dans le portail Defender.
Regroupement d’alertes et fusion d’incidents Bien que vous voyiez toujours la configuration du regroupement d’alertes dans les règles Analytics, le moteur de corrélation Defender XDR contrôle entièrement le regroupement d’alertes et la fusion des incidents si nécessaire dans le portail Defender. Cela garantit une vue complète de l’ensemble de l’histoire des attaques en regroupant les alertes pertinentes pour les attaques multi-étapes.

Par exemple, plusieurs règles d’analyse individuelles configurées pour générer un incident pour chaque alerte peuvent entraîner des incidents fusionnés s’ils correspondent à la logique de corrélation Defender XDR.
Visibilité des alertes Si vous disposez de règles d’analytique Microsoft Sentinel configurées pour déclencher des alertes uniquement, avec la création d’incident désactivée, ces alertes ne sont pas visibles dans le portail Defender.

Toutefois, même si l’éditeur de requête de repérage avancé ne reconnaît pas le SecurityAlerts schéma de table, vous pouvez toujours utiliser la table dans les requêtes et les règles d’analyse.
Réglage des alertes Une fois que votre espace de travail Microsoft Sentinel est intégré à Defender, tous les incidents, y compris ceux de vos règles d’analytique Microsoft Sentinel, sont générés par le moteur Defender XDR. Par conséquent, les fonctionnalités de réglage des alertes dans le portail Defender, précédemment disponibles uniquement pour les alertes Defender XDR, peuvent désormais être appliquées aux alertes de Microsoft Sentinel.

Cette fonctionnalité vous permet de simplifier la réponse aux incidents en automatisant la résolution des alertes courantes, en réduisant les faux positifs et en réduisant le bruit, afin que les analystes puissent hiérarchiser les incidents de sécurité importants.
Fusion : Détection avancée des attaques multi-étapes La règle d’analytique Fusion, qui, dans le portail Azure, crée des incidents basés sur les corrélations d’alerte effectuées par le moteur de corrélation Fusion, est désactivée lorsque vous intégrez Microsoft Sentinel au portail Defender.

Vous ne perdez pas la fonctionnalité de corrélation des alertes, car le portail Defender utilise les fonctionnalités de création et de corrélation des incidents de Microsoft Defender XDR pour remplacer celles du moteur Fusion.

Pour plus d’informations, consultez Détection avancée des attaques multiphases dans Microsoft Sentinel.

Configurer des règles d'automatisation et des manuels d'actions

Dans Microsoft Sentinel, les playbooks sont basés sur des workflows intégrés à Azure Logic Apps, un service cloud qui vous permet de planifier, d’automatiser et d’orchestrer des tâches et des flux de travail à travers l’entreprise.

Les limitations suivantes s’appliquent aux règles d’automatisation Microsoft Sentinel et aux playbooks lors de leur utilisation dans le portail Defender. Vous devrez peut-être apporter des modifications dans votre environnement lors de la transition.

Fonctionnalité Descriptif
Règles d’automatisation avec déclencheurs d’alerte Dans le portail Defender, les règles d’automatisation basées sur des déclencheurs d’alerte agissent uniquement sur les alertes Microsoft Sentinel.

Pour plus d’informations, consultez la rubrique Création de déclencheurs d’alerte.
Règles d’automatisation déclenchées par un incident Dans le portail Azure et le portail Defender, la propriété de condition du fournisseur d’incidents est supprimée, car tous les incidents ont Microsoft XDR comme fournisseur d’incidents (valeur dans le champ ProviderName ).

À ce stade, toutes les règles d’automatisation existantes s’exécutent à la fois sur les incidents Microsoft Sentinel et Microsoft Defender XDR, y compris celles où la condition du fournisseur d’incident est définie uniquement sur Microsoft Sentinel ou Microsoft 365 Defender.

Toutefois, les règles d’automatisation qui spécifient un nom de règle d’analyse spécifique s’exécutent uniquement sur les incidents contenant des alertes créées par la règle d’analyse spécifiée. Cela signifie que vous pouvez définir la propriété de condition du nom de la règle analytique sur une règle analytique qui existe uniquement dans Microsoft Sentinel pour que votre règle ne s’exécute que sur des incidents dans Microsoft Sentinel.

En outre, après l’intégration au portail Defender, la table SecurityIncident n’inclut plus de champ Description. Par conséquent :

- Si vous utilisez ce champ Description comme condition pour une règle d’automatisation avec un déclencheur de création d’incident, cette règle d’automatisation ne fonctionnera pas après l’intégration au portail Defender. Dans ce cas, veillez à mettre à jour la configuration de manière appropriée. Pour plus d’informations, consultez la rubrique Conditions de déclenchement d’incidents.
- Si vous avez une intégration configurée avec un système de ticket externe, comme ServiceNow, la description de l’incident est manquante.
Latence dans les déclencheurs de playbooks L’affichage des incidents Microsoft Defender dans Microsoft Sentinel peut prendre jusqu’à 5 minute. Ce délai est également applicable au déclenchement d’un playbook.
Changements apportés aux noms d’incidents existants Le portail Defender utilise un moteur unique pour corréler les incidents et les alertes. Lors de l’intégration de votre espace de travail au portail Defender, les noms d’incidents existants peuvent être modifiés si la corrélation est appliquée. Pour vous assurer que vos règles d’automatisation s’exécutent toujours correctement, nous vous recommandons d’éviter d’utiliser les titres des incidents comme critères de condition dans vos règles d’automatisation. Nous vous suggérons plutôt d’utiliser le nom de la règle d’analyse ayant créé les alertes incluses dans l’incident, ainsi que des balises si vous devez être plus spécifique.
Mise à jour par champ
  • Après l’intégration de votre espace de travail, le champ Mis à jour par possède un nouvel ensemble de valeurs prises en charge, qui n’incluent plus Microsoft 365 Defender. Dans les règles d’automatisation existantes, Microsoft 365 Defender est remplacé par une valeur Autre après l’intégration de votre espace de travail.

  • Si plusieurs modifications sont apportées au même incident au cours d’une période de 5 à 10 minutes, une seule mise à jour sera envoyée à Microsoft Sentinel, avec uniquement la modification la plus récente.

    Pour plus d’informations, consultez la rubrique Déclenchement de mise à jour de l’incident.
    		•
    Création de règles d’automatisation directement à partir d’un incident La Création de règles d’automatisation directement à partir d’un incident est uniquement prise en charge dans le Portail Azure. Si vous travaillez dans le portail Defender, créez vos règles d’automatisation à partir de zéro dans la page Automatisation.
    Règle de création d’incident Microsoft Les règles de création d’incidents Microsoft ne sont pas prises en charge dans le portail Defender.

    Pour plus d’informations, consultez Incidents Microsoft Defender XDR et règles de création d’incidents Microsoft.
    Exécution de règles d’automatisation à partir du portail Defender Il peut s’écouler jusqu’à 10 minutes entre le moment où une alerte est déclenchée et où un incident est créé ou mis à jour dans le portail Defender et le moment où une règle d’automatisation est exécutée. Ce décalage est dû au fait que l’incident est créé dans le portail Defender, puis transmis à Microsoft Sentinel pour la règle d’automatisation.
    Onglet Playbooks actifs Après l’intégration au portail Defender, l’onglet Playbooks actifs affiche par défaut un filtre prédéfini avec l’abonnement de l’espace de travail intégré. Sur le Portail Azure, ajoutez des données pour d’autres abonnements à l’aide du filtre d’abonnement.

    Pour plus d’informations, consultez Créer et personnaliser des playbooks Microsoft Sentinel à partir de modèles.
    Exécution manuelle de playbooks à la demande Les procédures suivantes ne sont actuellement pas prises en charge dans le portail Defender :
  • Exécuter manuellement un playbook sur une alerte
  • Exécuter manuellement un playbook sur une entité
    		•
    Exécution de playbooks sur les incidents nécessite la synchronisation de Microsoft Sentinel Si vous essayez d’exécuter un playbook sur un incident à partir du portail Defender et voyez le message « Impossible d’accéder aux données liées à cette action. Actualisez l’écran dans quelques minutes.», cela signifie que l’incident n’est pas encore synchronisé avec Microsoft Sentinel.

    Actualisez la page d’incident après la synchronisation de l’incident pour exécuter le guide opérationnel avec succès.
    Incidents : ajout d’alertes à des incidents/
    Suppression des alertes des incidents    		 Étant donné que l’ajout ou la suppression d’alertes dans des incidents n’est pas pris en charge après l’intégration de votre espace de travail au portail Defender, ces actions ne sont pas non plus prises en charge dans les playbooks. Pour plus d’informations, consultez Comprendre comment les alertes sont corrélées et les incidents sont fusionnés dans le portail Defender.
    Intégration de Microsoft Defender XDR dans plusieurs espaces de travail Si vous avez procédé à l'intégration de données XDR dans plusieurs espaces de travail au sein d'un même locataire, les données ne sont désormais ingérées que dans l'espace de travail principal du portail Defender. Transférer des règles d’automatisation vers l’espace de travail approprié pour les maintenir en cours d’exécution.
    Automatisation et moteur de corrélation Le moteur de corrélation peut combiner des alertes de plusieurs signaux en un seul incident, ce qui peut entraîner la réception automatique des données que vous n’avez pas anticipées. Nous vous recommandons d’examiner vos règles d’automatisation pour vous assurer que vous voyez les résultats attendus.

    Configurer des API

    L’expérience unifiée dans le portail Defender introduit des modifications notables apportées aux incidents et aux alertes provenant d’API. Il prend en charge les appels d’API basés sur l’API REST Microsoft Graph v1.0, qui peuvent être utilisés pour l’automatisation liée aux alertes, aux incidents, à la chasse avancée, etc.

    L’API Microsoft Sentinel continue de prendre en charge des actions sur les ressources Microsoft Sentinel, telles que les règles d’analytique, les règles d’automatisation et bien plus encore. Pour interagir avec des incidents et des alertes unifiés, nous vous recommandons d’utiliser l’API REST Microsoft Graph. Si vous utilisez l’API Microsoft Sentinel pour interagir avec les incidents Microsoft Sentinel SecurityInsights , vous devrez peut-être mettre à jour vos conditions d’automatisation et déclencher des critères en raison des modifications apportées au corps de la réponse.

    Le tableau suivant répertorie les champs importants dans les extraits de réponse et les compare sur les portails Azure et Defender :

    Fonctionnalité Portail Azure Portail Defender
    Lien vers l’incident incidentUrl: URL directe de l’incident dans le portail Microsoft Sentinel providerIncidentUrl : Ce champ supplémentaire fournit un lien direct vers l’incident, qui peut être utilisé pour synchroniser ces informations avec un système de tickets tiers comme ServiceNow.

    incidentUrl est toujours disponible, mais il pointe vers le portail Microsoft Sentinel.
    Sources qui ont déclenché la détection et publié l’alerte alertProductNames alertProductNames: nécessite l’ajout de ?$expand=alerts à le GET.

    Par exemple, https://graph.microsoft.com/v1.0/security/incidents/368?$expand=alerts
    Nom du fournisseur d’alertes providerName = « Azure Sentinel » providerName = « Microsoft XDR »
    Service ou produit qui a créé l’alerte N’existe pas dans le portail Azure serviceSource

    Par exemple, « microsoftDefenderForCloudApps »
    Technologie ou capteur de détection qui a identifié le composant ou l’activité notables N’existe pas dans le portail Azure detectionSource Par exemple, « cloudAppSecurity »
    Nom du produit qui a publié cette alerte N’existe pas dans le portail Azure productName Par exemple, « Microsoft Defender pour Cloud Apps »

    Exécuter des opérations dans le portail Defender

    Audience : analystes de sécurité

    Vidéos :

    Mettre à jour les processus de triage des incidents pour le portail Defender

    Si vous avez utilisé Microsoft Sentinel dans le portail Azure, vous remarquerez des améliorations significatives de l’expérience utilisateur dans le portail Defender. Même si vous devrez peut-être mettre à jour les processus SOC et réentraîner vos analystes, la conception consolide toutes les informations pertinentes dans un seul endroit pour fournir des flux de travail plus rationalisés et efficaces.

    La file d’attente unifiée des incidents dans le portail Defender consolide tous les incidents entre les produits en une seule vue, ce qui a un impact sur la façon dont les analystes trient les incidents qui contiennent désormais plusieurs alertes de domaine inter-sécurité. Par exemple:

    • Traditionnellement, les analystes trient les incidents en fonction de domaines de sécurité ou d’expertise spécifiques, qui gèrent souvent des tickets par entité, tels qu’un utilisateur ou un hôte. Cette approche peut créer des taches aveugles, que l’expérience unifiée vise à traiter.
    • Lorsqu’un attaquant se déplace ultérieurement, les alertes associées peuvent se retrouver dans des incidents distincts en raison de différents domaines de sécurité. L’expérience unifiée élimine ce problème en fournissant une vue complète, en veillant à ce que toutes les alertes associées soient corrélées et gérées de manière cohérente.

    Les analystes peuvent également afficher les sources de détection et les noms de produits dans le portail Defender, et appliquer et partager des filtres pour un tri d’incident et d’alerte plus efficace.

    Le processus de triage unifié peut aider à réduire les charges de travail d’analyste et même à combiner potentiellement les rôles des analystes de niveau 1 et de niveau 2. Toutefois, le processus de triage unifié peut également nécessiter une connaissance plus large et plus approfondie des analystes. Nous vous recommandons de suivre une formation sur la nouvelle interface du portail pour garantir une transition fluide.

    Pour plus d’informations, consultez Réponses et incidents dans le portail Microsoft Defender.

    Comprendre comment les alertes sont corrélées et les incidents sont fusionnés dans le portail Defender

    Le moteur de corrélation de Defender fusionne les incidents lorsqu’il reconnaît les éléments courants entre les alertes dans des incidents distincts. Lorsqu’une nouvelle alerte répond aux critères de corrélation, Microsoft Defender agrège et la met en corrélation avec d’autres alertes associées de toutes les sources de détection dans un nouvel incident. Après l’intégration de Microsoft Sentinel au portail Defender, la file d’attente unifiée des incidents révèle une attaque plus complète, ce qui rend les analystes plus efficaces et fournit une histoire d’attaque complète.

    Dans les scénarios multi-espaces de travail, seules les alertes d’un espace de travail principal sont corrélées avec les données Microsoft Defender XDR. Il existe également des scénarios spécifiques dans lesquels les incidents ne sont pas fusionnés.

    Après avoir intégré Microsoft Sentinel au portail Defender, les modifications suivantes s’appliquent aux incidents et aux alertes :

    Caractéristique Descriptif
    Retarder juste après l’intégration de votre espace de travail Il peut falloir jusqu'à 5 minutes pour que les incidents Microsoft Defender s'intègrent complètement à Microsoft Sentinel. Cela n’affecte pas les fonctions fournies directement par Microsoft Defender, telles que l’interruption automatique des attaques.
    Règles de création d’incidents de sécurité Toutes les règles de création d’incidents de sécurité Microsoft actives sont désactivées pour éviter la création d’incidents en double. Les paramètres de création d’incidents dans d’autres types de règles d’analyse restent tels qu’ils le sont et sont configurables dans le portail Defender.
    Nom du fournisseur d’incidents Dans le portail Defender, le nom du fournisseur d’incidents est toujours Microsoft XDR.
    Ajout/suppression d’alertes à partir d’incidents L’ajout ou la suppression d’alertes Microsoft Sentinel vers ou depuis des incidents est pris en charge uniquement dans le portail Defender. Pour supprimer une alerte d’un incident dans le portail Defender, vous devez ajouter l’alerte à un autre incident.
    Modification des commentaires Ajoutez des commentaires aux incidents dans le portail Defender ou Azure, mais la modification des commentaires existants n’est pas prise en charge dans le portail Defender. Les modifications apportées aux commentaires dans le portail Azure ne sont pas synchronisées avec le portail Defender.
    Création programmatique et manuelle d’incidents Les incidents créés dans Microsoft Sentinel avec l’API, par un playbook Logic Apps ou manuellement dans le portail Azure ne sont pas synchronisés dans le portail Defender. Ces incidents sont toujours pris en charge dans le portail Azure et l’API. Consultez Créer manuellement vos propres incidents dans Microsoft Sentinel.
    Réouverture des incidents fermés Dans le portail Defender, vous ne pouvez pas définir de regroupement d’alertes dans les règles analytiques Microsoft Sentinel pour rouvrir les incidents fermés si de nouvelles alertes sont ajoutées.
    Dans ce cas, les incidents fermés ne sont pas rouverts et de nouvelles alertes déclenchent de nouveaux incidents.
    Tâches Les tâches d’incident ne sont pas disponibles dans le portail Defender.

    Pour plus d’informations, consultez Utiliser des tâches pour gérer les incidents dans Microsoft Sentinel.

    Pour plus d’informations, consultez Incidents et alertes dans le portail Microsoft Defenderet corrélation des alertes et fusion des incidents dans le portail Microsoft Defender.

    Remarquez les modifications apportées aux enquêtes avec la chasse avancée

    Après l’intégration de Microsoft Sentinel au portail Defender, accédez et utilisez toutes vos tables de journaux existantes, requêtes KQL (Kusto Query Language) et fonctions dans la page Repérage avancé . Toutes les alertes Microsoft Sentinel liées aux incidents sont ingérées dans la table AlertInfo, accessible à partir de la page Repérage avancé.

    Certaines différences existent, telles que :

    • Les signets ne sont pas pris en charge dans le repérage avancée. Au lieu de cela, les signets sont pris en charge dans le portail Defender sous Microsoft Sentinel > Threat Management > Chasse.
    • Même si la table SecurityAlert n’apparaît pas dans la liste des tables du Schéma de >, elle est toujours prise en charge dans vos requêtes.

    Pour plus d’informations, consultez Repérage avancé avec les données Microsoft Sentinel dans Microsoft Defender, en particulier la liste des problèmes connus et suivre les données pendant la chasse avec Microsoft Sentinel.

    Examiner avec des entités dans le portail Defender

    Dans le portail Microsoft Defender, les entités sont généralement des ressources, telles que des comptes, des hôtes ou des boîtes aux lettres, ou des preuves, telles que des adresses IP, des fichiers ou des URL.

    Après l’intégration de Microsoft Sentinel au portail Defender, les pages d’entités pour les utilisateurs, les appareils et les adresses IP sont consolidées dans une vue unique avec une vue complète de l’activité et du contexte et des données de l’entité à partir de Microsoft Sentinel et de Microsoft Defender XDR.

    Le portail Defender fournit également une barre de recherche globale qui centralise les résultats de toutes les entités afin de pouvoir effectuer des recherches dans SIEM et XDR.

    Pour plus d’informations, consultez les pages d’entité dans Microsoft Sentinel.

    Examiner avec UEBA dans le portail Defender

    La plupart des fonctionnalités d’Analyse du comportement des utilisateurs et des entités (UEBA) restent les mêmes dans le portail Defender que dans le portail Azure, avec les exceptions suivantes :

    • L’ajout d’entités au renseignement sur les menaces à partir d’incidents n’est pris en charge que dans le portail Azure. Pour plus d’informations, consultez Ajouter une entité aux indicateurs de menace.

    • Après avoir intégré Microsoft Sentinel au portail Defender, la IdentityInfo table utilisée dans le portail Defender inclut des champs unifiés à partir de Defender XDR et de Microsoft Sentinel. Certains champs qui existaient lors de l’utilisation dans le portail Azure sont renommés dans le portail Defender ou ne sont pas pris en charge du tout. Nous vous recommandons de vérifier vos requêtes pour toutes les références à ces champs et de les mettre à jour si nécessaire. Pour plus d’informations, consultez la table IdentityInfo.

    Important

    Lorsque vous passez au portail Defender, la IdentityInfo table devient une table Defender native qui ne prend pas en charge le contrôle d’accès en fonction du rôle (RBAC) au niveau de la table. Si votre organisation utilise RBAC au niveau table pour restreindre l’accès à la table dans le IdentityInfo portail Azure, ce contrôle d’accès ne sera plus disponible après la transition vers le portail Defender.

    Mettre à jour les processus d’investigation pour utiliser Microsoft Defender Threat Intelligence

    Pour les clients Microsoft Sentinel qui passent du portail Azure au portail Defender, les fonctionnalités familières de renseignement sur les menaces sont conservées dans le portail Defender sous gestion Intel et améliorées avec d’autres fonctionnalités de renseignement sur les menaces disponibles dans le portail Defender. Les fonctionnalités prises en charge dépendent des licences que vous avez, telles que :

    Caractéristique Descriptif
    Analyse des menaces Pris en charge pour les clients Microsoft Defender XDR . Solution en produit fournie par les chercheurs en sécurité Microsoft, conçue pour aider les équipes de sécurité en offrant des insights sur les menaces émergentes, les menaces actives et leurs impacts. Les données sont présentées dans un tableau de bord intuitif avec des cartes, des lignes de données, des filtres, etc.
    Profils Intel Pris en charge pour les clients Microsoft Defender Threat Intelligence . Classez les menaces et les comportements par un profil d’acteur de menace, ce qui facilite le suivi et la corrélation. Ces profils incluent tous les indicateurs de compromission (IoC) liés aux tactiques, techniques et outils utilisés dans les attaques.
    Intel Explorer Pris en charge pour les clients Microsoft Defender Threat Intelligence . Consolide les IoCs disponibles et fournit des articles sur les menaces à mesure qu’ils sont publiés, ce qui permet aux équipes de sécurité de rester à jour sur les menaces émergentes.
    Projets Intel Pris en charge pour les clients Microsoft Defender Threat Intelligence . Permet aux équipes de consolider le renseignement sur les menaces dans un « projet » pour examiner tous les artefacts liés à un scénario spécifique d’intérêt.

    Dans le portail Defender, utilisez conjointement ThreatIntelOjbects et ThreatIntelIndicators avec les indicateurs de compromission pour la chasse aux menaces, la réponse aux incidents, Copilot, les rapports et pour créer des graphiques relationnels montrant les connexions entre les indicateurs et les entités.

    Pour les clients utilisant le flux Microsoft Defender Threat Intelligence (MDTI), une version gratuite est disponible via le connecteur de données de Microsoft Sentinel pour MDTI. Les utilisateurs disposant de licences MDTI peuvent également ingérer des données MDTI et utiliser Security Copilot pour l’analyse des menaces, l’examen actif des menaces et la recherche sur les acteurs des menaces.

    Pour plus d’informations, consultez :

    Utiliser des classeurs pour visualiser et signaler des données Microsoft Defender

    Les classeurs Azure continuent d’être l’outil principal pour la visualisation et l’interaction des données dans le portail Defender, fonctionnant comme ils l’ont fait dans le portail Azure.

    Pour utiliser des classeurs avec des données de repérage avancé, veillez à ingérer des journaux dans Microsoft Sentinel.

    Pour plus d’informations, consultez Visualiser et surveiller vos données à l’aide de classeurs dans Microsoft Sentinel.

    Les incidents similaires (préversion) ne sont pas pris en charge dans le portail Defender

    La fonctionnalité d’incidents similaires de Microsoft Sentinel est en préversion, n’est pas prise en charge dans le portail Defender. Cela signifie que lors de l’affichage d’une page de détails d’incident dans le portail Defender, l’onglet Incidents similaires n’est pas disponible.

    Contenu connexe

    • Last updated on