Le modèle actuel pour les services de cybersécurité est cassé. Il consiste à acquérir et déployer de nombreux outils autonomes, chacun avec sa propre console, pour analyser les logs ou le trafic et détecter les anomalies qui pourraient être des menaces. Dans ce modèle, il appartient à chaque analyste de sécurité de communiquer avec d'autres analystes pour déterminer si la détection individuelle de chaque outil (dont chacun, par lui-même, peut sembler bénigne), peut être corrélée avec d'autres détections d'autres outils pour révéler une attaque complexe.
Ce modèle oblige les entreprises à créer des piles de sécurité complexes constituées de SIEM, SOAR, EDR, NDR et plus encore, dans le but d'instrumenter l'entreprise, d'identifier les menaces, de répondre aux menaces et de gérer les risques. L'acquisition de tous ces outils et la gestion de leurs licences sont complexes et coûteux, et la corrélation manuelle nécessaire pour comparer les détections de chaque outil laisse de nombreuses lacunes dans l'infrastructure de sécurité globale.
Les analystes sont également souvent bombardés de faux positifs par ces systèmes, ce qui provoque une «fatigue d'alerte» et une insatisfaction au travail. Même les entreprises qui se déclarent satisfaites de leur SIEM et d'autres outils admettront que le temps et l'énergie qu'ils ont consacrés à la mise en place d'une infrastructure de sécurité multi-outils ne donnent pas les résultats escomptés.
Le cas pour XDR
XDR, Détection et réponse étenduesL'acronyme « X » est devenu une définition fourre-tout pour toute technologie de détection et de réponse, car X y représente en réalité une variable. Bien que X puisse signifier « Endpoint+ » ou « Network+ », cela ne tient pas compte des difficultés actuelles rencontrées par les entreprises : outils cloisonnés, données non corrélées et saturation d'alertes. L'objectif principal de XDR Il s'agit de remédier à cette situation problématique, et par conséquent X doit signifier « Tout ». « Tout » implique donc une approche de plateforme visant à couvrir l'ensemble de la surface d'attaque grâce à la détection et à la réponse.
Cette approche de plateforme peut remédier aux défaillances du modèle actuel en transformant les outils cloisonnés en un ensemble d'outils unifié, les données non corrélées en une représentation dynamique et corrélée de la surface d'attaque, et la surcharge d'alertes en sérénité. La manière dont une technologie atteint cet objectif constitue la question architecturale clé. Il existe deux types de XDR Aujourd'hui : Ouvert et natif.
Ouvert vs. Natif XDR
- Open XDR est fourni via une architecture ouverte capable de tirer parti des capacités de télémétrie et de réponse des outils de sécurité existants sur toute la surface d'attaque
- Originaire XDR est fourni à partir de la suite d'outils de sécurité d'un seul fournisseur qui fournit la télémétrie et la réponse sur toute la surface d'attaque
Quelle que soit l'approche architecturale d'un XDR Pour être prise en compte, la plateforme doit satisfaire aux exigences techniques suivantes XDR:
- Déployabilité - Architecture de microservices cloud native pour l'évolutivité, la disponibilité et la flexibilité de déploiement
- La fusion des données - Données normalisées et enrichies sur toute la surface d'attaque, y compris le réseau, le cloud, les terminaux, les applications et l'identité
- Corrélation - Détections corrélées haute fidélité sur plusieurs outils de sécurité
- Réponse intelligente - Réponse en un clic ou automatisée depuis la même plateforme
Une idée fausse courante sur Ouvert vs. Natif XDR c'est qu'il s'agit de types de types mutuellement exclusifs XDRIls ne le sont pas. XDR Une plateforme peut être entièrement ouverte et partiellement native. Par exemple, une XDR peut avoir quelques outils intégrés de son fournisseur tout en s'intégrant ouvertement aux outils existants des autres fournisseurs. Cela permet une stratégie de sécurité composable, la capacité d'exploiter les outils existants tout en permettant au client de suspendre certains d'entre eux quand et où bon lui semble.
La composition d'Open vs. Native XDR L'approche adoptée par une plateforme est un moyen d'atteindre un but : plus précisément, la manière dont la plateforme effectue la détection et la réponse sur l'ensemble de la surface d'attaque. Les acheteurs de XDR Ils doivent considérer l'approche architecturale comme un moyen d'atteindre un objectif et prendre la meilleure décision pour leur entreprise.
L'idéal XDR est ouvert
Certaines entreprises n'auront aucun problème à déplacer l'ensemble de leur pile de sécurité vers un seul fournisseur et à adopter un système fermé, Originaire XDR . Il y aura également des entreprises qui se soucieront moins de couvrir toute la surface d'attaque et ne voudront que la détection et la réponse pour leurs terminaux, par exemple. Dans ce cas, ils devraient poursuivre un natif basé sur EDR XDR .
Cependant, pour la plupart des entreprises, un Open XDR Cela doit être considéré comme la priorité absolue. Pourquoi ? Parce qu'aucun fournisseur ne pourra jamais créer ou acquérir à lui seul les meilleurs outils cloud, de gestion des terminaux, de réseau, d'identité, etc. Par conséquent, une solution native uniquement XDR La plateforme ne sera pas la meilleure du marché. De plus, il est fort probable que l'entreprise ait déjà investi des capitaux et des efforts importants dans le déploiement des outils de sécurité existants - il ne voudra pas abandonner ces investissements, donc un Originaire XDR La solution n'interagirait pas avec ces outils et ne capturerait pas toute la surface d'attaque de cette entreprise. Si un Open XDR a des attributs natifs pour couvrir certaines zones de la surface d'attaque pour les entreprises en croissance, très bien. Mais il doit d'abord être ouvert.
Au final, si une entreprise souhaite définir et mettre en œuvre une stratégie de sécurité composable et obtenir tous les résultats escomptés XDRles exigences techniques de l'entreprise fournies via une plateforme, une solution entièrement Open XDR est la seule façon réaliste de le faire.
