Bitdefender XDR Sensor for MDR (Add-On) Cloud

Que comprend le capteur Bitdefender XDR pour MDR (module complémentaire) Cloud ?

Capteur AWS – Collecte les événements CloudTrail et AWS Config dans GravityZone.
Capteur Azure Cloud – Collecte les activités de l’abonnement via une application Entra ID enregistrée.
Capteur Google Cloud – Collecte les événements d’activité des projets Google Cloud Platform.
Couverture par les analystes MDR – Les analystes du SOC de Bitdefender effectuent le triage des détections cloud ainsi obtenues.
Corrélation avec les terminaux – Les événements cloud sont corrélés avec les données télémétriques des terminaux et des identités.
Important – Aucune protection par agent pour les charges de travail cloud n’est incluse ici.

Quels sont les principaux avantages de Bitdefender XDR Sensor for MDR (module complémentaire) Cloud ?

Ce module complémentaire est un capteur sous licence distincte qui intègre les données d’activité d’Amazon Web Services, de Microsoft Azure et de Google Cloud Platform dans le moteur de corrélation GravityZone XDR, où la documentation du fournisseur Bitdefender le désigne sous le nom de « GravityZone XDR Sensor for MDR Cloud ». Il est configuré et géré de manière centralisée dans le GravityZone Control Center, sous « Configuration » et « Gestion des capteurs », et les événements qu’il transmet sont intégrés aux mêmes incidents que ceux traités par le centre d’opérations de sécurité (SOC) Bitdefender MDR.

Élimination des angles morts dans le cloud – Les actions du plan de contrôle deviennent visibles à côté des événements des terminaux.
Moins de consoles parallèles – Les détections dans le cloud apparaissent dans la même vue d’incident.
Gain de temps pour les analystes – C’est le SOC qui trie les alertes du cloud à la place de votre équipe.
Reconstitution plus rapide des attaques – Les incidents montrent comment une connexion a entraîné des modifications dans le cloud.
Couverture multicloud – AWS, Microsoft Azure et Google Cloud sont tous pris en charge.
Preuves pour les rapports – Les chronologies des incidents documentent ce qui s’est passé et à quel moment.

Le meilleur antivirus ? Pourquoi Windows Defender ne suffit pas à lui seul.
Explication des limites de la protection intégrée et de la nécessité des couches de détection et de réponse qui s’y ajoutent.

À quelle taille d’entreprise le Bitdefender XDR Sensor for MDR (module complémentaire) Cloud est-il adapté ?

Le facteur déterminant n’est pas l’effectif, mais le fait que vous exécutiez réellement des charges de travail dans un cloud public et que vous payiez déjà pour un service de détection géré. Une entreprise disposant de trois machines virtuelles sur Azure et sans abonnement MDR ne tire aucun avantage de ce module complémentaire ; une entreprise dont la présence sur AWS est en pleine croissance et qui dispose d’un contrat MDR existant comble quant à elle une véritable lacune grâce à ce module.

Le capteur Bitdefender XDR pour MDR (module complémentaire) Cloud répond-il aux exigences de la législation suisse en matière de cybersécurité ?

La loi révisée sur la sécurité de l’information oblige les opérateurs d’infrastructures critiques en Suisse à signaler les cyberattaques à l’Office fédéral de la cybersécurité (BACS) dans les 24 heures suivant leur découverte, tandis que la plupart des autres entreprises ne sont pas du tout soumises à cette obligation. Lorsque votre infrastructure comprend des composants cloud, ce capteur réduit le temps nécessaire à l’établissement des faits, car l’incident intègre d’emblée l’activité cloud associée, ce qui évite de devoir extraire manuellement, sous la pression du temps, les journaux d’activité CloudTrail ou Azure. Le service MDR apporte la deuxième partie de cette solution : des analystes qui examinent la détection à trois heures du matin plutôt que le jour ouvrable suivant. Ce que ce module complémentaire ne fait pas, c’est déterminer si vous êtes concerné par cette obligation, effectuer une déclaration auprès du BACS ou protéger les charges de travail elles-mêmes, ce qui nécessite toujours la présence d’un agent de sécurité sur les instances. Il ne génère pas non plus de registre de vos obligations de déclaration ; la gestion organisationnelle reste donc à votre charge. Ce texte ne constitue pas un avis juridique, et il convient de vérifier auprès d’un conseiller juridique qualifié si votre organisation est soumise à l’obligation de déclaration.

Le module complémentaire « Bitdefender XDR Sensor for MDR (Add-On) Cloud » répond-il aux exigences de la législation européenne en matière de cybersécurité ?

Aucun produit ne permet à une entreprise d’être conforme à la directive NIS 2, car celle-ci porte sur les mesures de gestion des risques et la gouvernance, et non sur les fonctionnalités logicielles. La directive NIS 2 exige des entités concernées qu’elles couvrent l’analyse des risques et les politiques de sécurité, la gestion des incidents, la continuité des activités et la sauvegarde, la sécurité de la chaîne d’approvisionnement, la gestion des vulnérabilités, l’hygiène informatique et la formation, la cryptographie, ainsi que le contrôle d’accès, y compris l’authentification multifactorielle. Ce module complémentaire contribue à une seule de ces catégories : la gestion des incidents, grâce à la collecte continue des activités dans le cloud, à la corrélation avec les événements liés aux terminaux et aux identités, ainsi qu’à la documentation chronologique des incidents pouvant être présentée à un auditeur. Il n’apporte aucune contribution en matière de sauvegarde et de continuité d’activité, de formation du personnel, de cryptographie, de contrôle d’accès ou d’évaluation de vos propres fournisseurs. Ces mesures nécessitent des produits distincts et, surtout, des processus écrits dont la responsabilité incombe à une personne au sein de votre organisation.

Le module complémentaire « Bitdefender XDR Sensor for MDR (Add-On) Cloud » facilite-t-il le remplissage des questionnaires de sécurité des grands clients ?

En partie, et uniquement pour une section d’un questionnaire type. Il vous apporte une réponse défendable aux questions relatives à la surveillance 24 h/24 et 7 j/7, à l’enregistrement et à l’analyse de l’activité de l’infrastructure cloud, à l’identité de la personne chargée du tri des alertes, ainsi qu’à la possibilité de reconstituer les incidents a posteriori, car le capteur associé au service MDR garantit qu’un prestataire désigné assure la surveillance, et non une boîte de messagerie sans personnel. Il n’apporte aucune réponse concernant le chiffrement au repos, les tests de sauvegarde et de restauration, les délais d’application des correctifs, la gestion des identités et des accès, l’authentification multifactorielle, la formation de sensibilisation du personnel, les tests d’intrusion ou les audits de mauvaise configuration du cloud. Le point relatif aux erreurs de configuration est celui qui pose le plus souvent problème aux acheteurs, car il semble relever d’un capteur cloud alors que ce n’est pas le cas : la gestion de la posture de sécurité relève de Bitdefender Cloud Security (CSPM+), un produit distinct. Lorsque plusieurs lacunes subsistent, l’ajout des modules correspondants de la même gamme GravityZone s’avère généralement moins coûteux et plus simple à justifier que de rassembler les réponses de trois fournisseurs différents avec trois formats de rapports distincts.

Quelle est la différence entre XDR Sensor Cloud et XDR Sensor for MDR Cloud ?

La différence décisive réside dans l’identité de la personne qui examine les alertes. Les deux variantes collectent les mêmes données d’activité cloud et alimentent le même moteur de corrélation GravityZone XDR ; ce n’est donc pas la couverture technique qui les distingue. Le XDR Sensor Cloud standard part du principe que votre propre équipe ouvre la console et traite les incidents. La variante MDR est destinée aux clients chez qui le service Bitdefender MDR est actif ; ainsi, la télémétrie cloud s’inscrit dans le périmètre de surveillance du centre d’opérations de sécurité, et la configuration implique de vérifier que l’entreprise est correctement inscrite au service MDR et dispose des autorisations requises. Si vous ne disposez pas d’un abonnement MDR, la variante MDR ne vous concerne pas.

Quelles sont les limites à connaître avant l’achat ?

Ce capteur analyse les journaux d'activité et de configuration propres à la plateforme cloud ; il ne protège pas les machines virtuelles et les conteneurs exécutés au sein de ces comptes, qui nécessitent toujours l'agent de sécurité Bitdefender et, pour les environnements de conteneurs, le module complémentaire de protection des conteneurs. La gestion de la posture cloud et l’analyse des erreurs de configuration relèvent d’un autre produit, Bitdefender Cloud Security (CSPM+), et font l’objet d’une licence distincte. Les événements d’identité provenant de Microsoft Entra ID sont collectés par les capteurs d’identité plutôt que par le capteur cloud, et cette distinction est la raison la plus courante d’un deuxième achat imprévu. La configuration ne se résume pas non plus à une intégration en un clic : AWS nécessite CloudTrail, AWS Config, un compartiment S3, une file d’attente SQS et une politique IAM avec des autorisations définies, tandis qu’Azure nécessite une application Entra ID enregistrée disposant du rôle « Reader » sur l’abonnement ; prévoyez donc un créneau de maintenance avec une personne disposant des droits d’administrateur cloud. Enfin, GravityZone Cloud s’exécute sur plusieurs instances cloud distinctes ; par conséquent, si l’emplacement des données traitées constitue une exigence au sein de votre organisation, vérifiez sur quelle instance se trouve votre tenant avant de passer commande.

La perte de données coûte cher : comment les sauvegardes vous aident à éviter les interruptions de service.
Ce document aborde l’aspect « récupération » que les services de détection et de réponse omettent délibérément.

Foire aux questions sur Bitdefender XDR Sensor for MDR (module complémentaire) Cloud

Que se passe-t-il si le capteur perd ses autorisations ?

La page de gestion des capteurs affiche un statut pour chaque intégration : Actif, Désactivé, Action requise ou Hors ligne. Les statuts « Action requise » et « Hors ligne » indiquent généralement qu’une ou plusieurs autorisations font défaut, et le capteur cesse de traiter les données jusqu’à ce qu’elles soient rétablies. Il est donc préférable d’ajouter ce point à une liste de contrôle de surveillance plutôt que de le découvrir lors d’un incident.

Un compte AWS compromis peut-il être désactivé depuis la console ?

Dans les environnements AWS Control Tower, les clés d’accès appartenant à un compte IAM compromis peuvent être désactivées et supprimées du compte de gestion, soit depuis le panneau de détails de l’alerte, soit depuis l’onglet « Réponse » de l’incident. Les actions de réponse supplémentaires disponibles dépendent des autorisations que vous avez accordées lors de l’intégration.

Ce capteur remplace-t-il un SIEM ?

Non. Il transmet les événements cloud vers les incidents GravityZone à des fins de détection et de corrélation, et non pour le stockage à long terme des journaux ni pour la recherche libre dans des sources arbitraires. Pour cela, Bitdefender propose le produit distinct Security Data Lake, ainsi que des intégrations à des plateformes SIEM telles que Splunk, Microsoft Sentinel et IBM QRadar.