La détection de ransomware de Druva combat les attaques assistées par IA avec l’IA

Druva a lancé le 17 septembre un système de détection des ransomwares en deux étapes, alors que les attaques assistées par IA rendent les activités malveillantes plus difficiles à distinguer des changements de routine. La nouvelle capacité de détection de ransomware de Druva analyse les snapshots de sauvegarde, valide les cas de chiffrement suspect et aide les administrateurs à identifier un point de récupération plus sain.

Il ne s’agit pas simplement d’une opposition entre l’IA et l’IA. La détection d’anomalies conventionnelle repère les comportements inhabituels, mais une anomalie ne prouve pas qu’un ransomware a modifié les données. Les équipes de sécurité et de récupération peuvent perdre un temps précieux à corréler les alertes tout en déterminant quelles sauvegardes restent fiables.

Druva veut remplacer cette incertitude par des preuves. Son système associe des modèles comportementaux, des contrôles forensiques au niveau des fichiers et un contexte d’identité issu de Dru MetaGraph. Cette approche répond à une faiblesse connue de la cyberrécupération : une détection rapide ne vaut pas grand-chose si les intervenants ne peuvent pas sélectionner avec certitude les éléments à restaurer.

Druva passe des alertes d’anomalies à la confirmation de ransomware

Le principal changement apporté par Druva consiste à passer de l’identification d’activités suspectes à la confirmation qu’un ransomware a altéré un snapshot de sauvegarde.

La première étape examine les métadonnées de sauvegarde à la recherche de comportements associés aux ransomwares. Ces signaux incluent le renommage massif de fichiers, des extensions inhabituelles et des artefacts tels que des notes de rançon. Druva indique que des modèles d’IA et de machine learning conçus à cet effet évaluent ces indicateurs sur l’ensemble des snapshots.

Un résultat suspect ne devient pas immédiatement un incident de ransomware confirmé. Druva fait plutôt passer le snapshot concerné à une seconde étape d’analyse forensique. Cette séparation vise à réduire les fausses alertes pouvant découler d’activités administratives ou applicatives ordinaires.

La seconde étape examine les fichiers sous-jacents. Selon la documentation technique de Druva, ses contrôles incluent l’analyse d’entropie, la cohérence des types MIME, les en-têtes de fichiers et l’intégrité structurelle.

L’entropie mesure le degré d’aléa apparent du contenu d’un fichier. Le chiffrement augmente souvent cet aléa, même si une entropie élevée ne suffit pas à établir une intention malveillante. L’analyse MIME compare le format déclaré d’un fichier à son contenu réel, ce qui aide à repérer les fichiers déguisés par des extensions modifiées.

Druva corrèle ensuite ces conclusions avant d’émettre une alerte critique. Son système distingue un avertissement de haute gravité concernant une activité potentielle d’une alerte critique signalant un impact confirmé.

Cette distinction répond à un problème concret de réponse aux incidents. Une hausse soudaine du nombre de fichiers modifiés peut indiquer un ransomware, mais elle peut aussi résulter d’une migration, d’une mise à jour logicielle ou d’une vaste opération administrative. Considérer chaque écart comme une attaque crée une fatigue liée aux alertes et ralentit l’enquête.

Druva indique que les preuves apparaissent dans Recovery Insights et son Security Command Center. Les administrateurs peuvent examiner les snapshots affectés, identifier un point antérieur à l’infection apparente et lancer un Restore Scan avant de remettre les données en production.

Cette capacité est entrée en disponibilité limitée pour les machines virtuelles VMware, les machines virtuelles Microsoft Azure, ainsi que les charges de travail AWS EC2 et EBS. Druva précise qu’elle est disponible via son offre Premium Security et nécessite une activation par l’intermédiaire d’un gestionnaire de compte ou d’un dossier de support.

L’entreprise décrit cette fonctionnalité comme sans agent, car elle fonctionne dans l’architecture de sauvegarde cloud de Druva. Les clients n’ont pas besoin d’un agent de détection local supplémentaire ni d’une appliance d’analyse distincte.

Cette architecture est importante lors d’un incident. Les outils sur les terminaux peuvent être désactivés, manipulés ou isolés de l’équipe de récupération. La télémétrie de sauvegarde reste une source distincte pour comprendre ce qui est arrivé aux données protégées.

Cependant, la fonctionnalité n’empêche pas l’accès initial ni n’arrête le ransomware avant son exécution. Sa valeur commence après qu’un comportement suspect a atteint les données protégées et est devenu visible dans les snapshots de sauvegarde.

Ce rôle plus limité est important. La détection de ransomware de Druva est avant tout une capacité de preuve et de récupération, et non un remplacement des défenses des terminaux, des identités, des e-mails ou des réseaux.

Les ransomwares assistés par IA augmentent le coût de l’incertitude

L’IA modifie la compétition autour des ransomwares en accélérant et en diversifiant les attaques, tandis que les défenseurs ont toujours besoin de preuves fiables avant de restaurer les systèmes de production.

Le lancement rapporté présente le produit dans le contexte d’attaquants utilisant l’IA pour tester davantage de voies et modifier leurs tactiques plus rapidement. Les identifiants volés permettent également à des actions malveillantes de ressembler à des activités utilisateur légitimes.

Cela ne signifie pas que chaque charge utile de ransomware est autonome. L’IA peut soutenir plusieurs composantes d’une opération sans contrôler l’attaque dans son ensemble. Elle peut améliorer le phishing, générer des scripts, accélérer la reconnaissance ou aider un opérateur à s’adapter à l’environnement d’une cible.

La recherche de Proofpoint sur les ransomwares à l’ère de l’IA a révélé que 65 % des victimes de ransomware interrogées estimaient que l’IA avait rendu l’attaque plus efficace. La même étude a indiqué que 47 % des incidents avaient commencé par un lien malveillant.

Ces chiffres soulignent le problème d’identité auquel répond Druva. De nombreuses attaques débutent par une action qui semble initialement autorisée, comme l’ouverture d’un lien par un utilisateur ou l’utilisation d’identifiants valides par un intrus.

Lorsque l’accès semble légitime, les signaux de sécurité isolés deviennent plus difficiles à interpréter. Une politique modifiée, un nouveau privilège ou une connexion à une application inconnue peuvent relever d’une administration normale. Ils peuvent aussi signaler une préparation à un mouvement latéral ou à l’établissement d’une persistance.

La détection d’anomalies traditionnelle reste utile car elle réduit le périmètre de recherche. Pourtant, les équipes de sécurité doivent toujours déterminer si une alerte représente une attaque, quels systèmes ont été affectés et à quel moment l’environnement était encore digne de confiance.

Les équipes de récupération font face à un problème supplémentaire. La sauvegarde la plus récente n’est pas automatiquement le meilleur point de récupération. Si un attaquant a conservé son accès pendant plusieurs jours, les snapshots récents peuvent contenir des données compromises ou des modifications malveillantes.

Restaurer un snapshot infecté peut relancer l’incident. Choisir un snapshot inutilement ancien peut faire perdre des activités métier légitimes. Le bon point de récupération se situe entre ces deux issues, et son identification exige davantage qu’un statut vert de tâche de sauvegarde.

Druva soutient que des années de télémétrie de sauvegarde peuvent fournir une base plus stable pour cette décision. Les snapshots historiques révèlent les changements au fil du temps, tandis que l’analyse forensique des fichiers peut déterminer si ces changements ressemblent à du chiffrement.

C’est pourquoi les ransomwares assistés par IA exercent une pression sur les fournisseurs de sauvegarde, et pas seulement sur les entreprises de sécurité traditionnelles. Les clients attendent de plus en plus que les données protégées soutiennent l’enquête, la validation et une récupération coordonnée.

Rubrik, Cohesity, Commvault et Veeam positionnent également la protection des données comme un élément de la cyberrésilience. La comparaison de fournisseurs de Gartner identifie plusieurs de ces produits comme des alternatives dans la même catégorie d’achat.

La concurrence évolue : il ne s’agit plus seulement de savoir si une plateforme stocke des copies immuables, mais de déterminer ce qu’elle peut prouver à leur sujet. Les acheteurs veulent savoir si les données sont saines, quelles identités étaient impliquées et à quelle vitesse les opérations peuvent reprendre.

La réponse de Druva reflète cette évolution. Son IA n’est pas présentée comme un assistant de sécurité généraliste. Elle est appliquée à une décision précise dont les erreurs sont coûteuses : déterminer si des données protégées ont subi l’impact d’un ransomware.

La détection de ransomware de Druva transforme les signaux en preuves de récupération

La conception en deux étapes est importante car elle distingue le filtrage comportemental large des preuves plus strictes nécessaires pour autoriser une récupération.

Lors de la première étape, une détection large constitue un avantage. Le modèle peut rechercher des extensions modifiées, des artefacts déposés, des renommages massifs et des transformations suspectes de fichiers. Ces schémas peuvent exposer des ransomwares connus et leurs variantes sans signature établie.

Cette couverture étendue crée également de l’ambiguïté. De nombreuses charges de travail légitimes produisent des changements importants ou inhabituels. Les systèmes de développement génèrent des types de fichiers inconnus, les processus de base de données réécrivent de grands ensembles de données, et les migrations peuvent ressembler à des modifications massives.

La seconde étape constitue la réponse de Druva à cette ambiguïté. Elle évalue si les fichiers présentent des caractéristiques compatibles avec un chiffrement ou une manipulation structurelle. Le système présente ensuite les indicateurs étayant l’alerte.

Druva qualifie ces éléments de preuves explicables. En pratique, l’administrateur devrait pouvoir comprendre pourquoi la plateforme a fait remonter un snapshot, plutôt que de recevoir uniquement un score de risque.

Cette distinction peut améliorer la collaboration entre les opérations de sécurité et les administrateurs de sauvegarde. Les analystes de sécurité comprennent l’attaque présumée, tandis que les équipes de sauvegarde connaissent les points de restauration disponibles. Les deux groupes ont besoin d’un dossier commun avant d’agir.

Le workflow commence par la détection, mais il se termine par une décision de récupération. L’explication produit de Druva divise le processus en détection comportementale, validation forensique et cyberrécupération.

Après avoir confirmé un impact probable, la plateforme présente les conclusions dans ses outils de récupération. Les équipes peuvent examiner les preuves, sélectionner un snapshot antérieur à l’infection, analyser le point de restauration proposé, puis procéder à la restauration.

Cette approche est plus utile qu’une alerte qui se limite à dire « quelque chose a changé ». Elle relie le diagnostic à la tâche opérationnelle consistant à remettre les systèmes en service.

Toutefois, la sortie du modèle dépend des données visibles dans l’environnement de Druva. Il ne peut pas reconstruire des événements qui n’ont jamais été capturés, ni garantir que chaque modification malveillante produise des preuves reconnaissables.

La détection de chiffrement ne traite également qu’une partie des ransomwares modernes. Les attaquants peuvent voler des données, détruire des identités, modifier des politiques d’accès ou établir une persistance avant de chiffrer quoi que ce soit. Certaines campagnes d’extorsion peuvent ne pas chiffrer les données du tout.

Druva répond en partie à cette lacune avec des services existants. Threat Watch recherche des indicateurs de compromission connus. Data Anomaly Detection signale les activités de données inhabituelles, tandis que la détection et la réponse gérées surveillent les menaces administratives et les actions destructrices.

La nouvelle capacité se situe entre ces outils. Elle est plus spécifique que la détection générale d’anomalies, mais ne remplace pas une enquête plus large sur les incidents. Sa mission consiste à valider l’impact d’un ransomware et à soutenir un choix de restauration plus sûr.

L’entreprise revendique des faux positifs « quasi nuls », mais cette affirmation nécessite des tests indépendants dans divers environnements clients. Les performances en matière de faux positifs changent souvent selon le type de charge de travail, le volume de données et les habitudes d’exploitation locales.

La disponibilité limitée offre à Druva une période contrôlée pour cette validation. Elle signifie également que l’annonce initiale décrit une capacité émergente plutôt qu’une fonctionnalité de production déployée universellement.

Pour les acheteurs en entreprise, la question d’évaluation est concrète. Druva peut-il distinguer de manière fiable le chiffrement malveillant d’un changement légitime à fort volume sans retarder la récupération ?

Cette mesure importe davantage que la simple présence de l’IA. Un modèle efficace doit réduire le temps d’enquête tout en préservant suffisamment de preuves pour qu’un intervenant puisse remettre sa conclusion en question.

Dru MetaGraph étend l’enquête aux identités

Les preuves au niveau des fichiers peuvent montrer ce qu’un ransomware a endommagé, mais le contexte d’identité est nécessaire pour expliquer comment l’attaquant y est parvenu.

Druva associe son pipeline de détection des menaces à Dru MetaGraph, une couche d’intelligence qui relie les identités, les activités et le contexte des données. Le système couvre les comptes humains et les identités non humaines, notamment les identités de service et les agents d’IA.

Il établit des relations entre Microsoft Entra ID, Active Directory et Okta. Druva indique que cela permet aux équipes de réponse d’examiner au fil du temps les modifications liées aux autorisations, aux applications, aux politiques et aux identités.

Un graphe est utile, car une attaque se résume rarement à un événement isolé. Un intrus peut obtenir des identifiants, accroître ses privilèges, établir une persistance, se déplacer entre les systèmes, puis affecter des données protégées.

Une liste d’alertes plate oblige les analystes à reconstituer manuellement ces relations. Dru MetaGraph vise à afficher le parcours sous forme de séquence connectée, y compris le rayon d’impact probable autour d’une identité compromise.

Druva indique qu’il associe les comportements observés à la base de connaissances ATT&CK. MITRE ATT&CK organise le comportement réel des adversaires en tactiques et techniques, offrant aux équipes de sécurité un vocabulaire commun pour les investigations.

Cette mise en correspondance peut aider à distinguer l’objectif derrière chaque événement. Une modification d’autorisation peut correspondre à une escalade de privilèges, tandis qu’un nouveau mécanisme d’authentification peut favoriser la persistance.

Druva affirme que sa vue contextuelle peut réduire les investigations de plusieurs jours à quelques heures. Cela reste une affirmation de l’entreprise, et les documents publics ne fournissent pas de référence indépendante à grande échelle étayant cette réduction de délai.

Le choix de conception le plus important consiste à relier l’historique des identités à celui des sauvegardes. Une alerte au niveau d’un fichier peut signaler un chiffrement suspect, tandis que les enregistrements d’identité peuvent montrer comment un attaquant a atteint la ressource concernée.

Ensemble, ces couches peuvent aider à établir l’état antérieur à l’attaque. L’équipe de réponse doit identifier des données saines, mais aussi des comptes, autorisations et politiques fiables.

Restaurer des fichiers sans supprimer les accès persistants laisse à l’attaquant un chemin de retour dans l’environnement. Réinitialiser les comptes sans valider les données peut ramener les utilisateurs vers des systèmes corrompus ou chiffrés.

Druva indique que son système peut générer un plan de reprise sur mesure. Ce plan identifie les objets affectés, recommande des actions et renvoie vers des snapshots sains. Chaque recommandation exige néanmoins une revue opérationnelle.

C’est l’argument concurrentiel le plus clair de Druva. Une plateforme SaaS de sauvegarde conserve déjà des données historiques à travers de nombreux points de reprise. L’ajout de relations entre identités peut transformer ces snapshots en chronologie d’analyse post-compromission.

La même architecture soulève des questions de gouvernance. Les graphes d’identité contiennent des informations sensibles sur les comptes, les privilèges, les applications et les comportements. Les clients doivent comprendre les périmètres de collecte, la rétention, les contrôles d’accès et le traitement régional.

Les agents d’IA rendent cet enjeu plus pressant. Les identités non humaines peuvent agir en continu, se connecter à plusieurs applications et recevoir des privilèges qui survivent à la tâche qui les a créées.

Les équipes de sécurité doivent distinguer une action automatisée légitime d’un attaquant qui abuse de cette identité. Le graphe de Druva peut apporter du contexte, mais le contexte n’élimine pas le besoin de contrôles d’identité et de jugement humain.

L’enjeu réel n’oppose donc pas seulement Druva aux ransomwares. Il oppose une reprise fondée sur des preuves à un processus de réponse fragmenté, dans lequel les équipes de sécurité, d’identité et de sauvegarde voient des parties différentes de l’incident.

Le véritable test porte sur la confiance, pas sur le volume d’alertes

Druva doit démontrer que ses preuves restent fiables dans des environnements complexes, face à des attaques discrètes et lors d’incidents qui ne suivent pas un schéma de chiffrement initial.

La promesse la plus forte du produit est la précision. Druva affirme qu’une validation en plusieurs étapes peut filtrer les faux signaux et fournir des preuves confirmées. Cette promesse mérite un examen attentif, car les décisions de reprise peuvent affecter toute une entreprise.

Un faux positif peut mettre en quarantaine un snapshot sain ou retarder la restauration. Un faux négatif peut qualifier des données compromises de sûres et réintroduire des modifications malveillantes en production.

Le risque augmente lorsque les attaquants s’adaptent au détecteur. Un adversaire qui comprend les indicateurs habituels de ransomware peut éviter les notes de rançon, ralentir les modifications de fichiers ou chiffrer certains actifs sous les seuils attendus.

L’IA peut accélérer cette adaptation en générant des variantes et en testant des comportements. Les modèles défensifs doivent donc évoluer sans devenir si sensibles que les opérations normales déclenchent des escalades constantes.

Druva indique que sa détection s’améliore grâce à la télémétrie, au renseignement sur les menaces et à l’affinement continu des modèles. Les clients devraient demander comment ces mises à jour sont testées et si les changements de modèle affectent la cohérence des alertes.

Ils devraient également examiner les preuves présentées pour chaque conclusion. Une explication lisible a davantage de valeur qu’un score de confiance générique, surtout durant une reprise sous forte pression.

La couverture des charges de travail constitue une autre limite. La version initiale en disponibilité limitée prend en charge VMware, les machines virtuelles Azure ainsi que AWS EC2 et EBS. Les organisations détiennent souvent des données critiques dans des applications SaaS, des terminaux, des bases de données, des conteneurs et des systèmes physiques.

Druva offre d’autres protections pour certains de ces environnements, mais la nouvelle capacité ransomware en deux étapes ne démarre pas avec une couverture universelle. Les acheteurs doivent distinguer le portefeuille plus large de la plateforme de la liste de prise en charge actuelle de cette fonctionnalité.

Une question de temporalité se pose également. L’analyse fondée sur les sauvegardes observe les données selon la cadence capturée par le processus de protection. Un contrôle de sécurité opérant sur l’activité de production peut observer les événements plus tôt, tandis que l’analyse des sauvegardes offre une séparation et un contexte historique.

Les deux rôles se complètent. Les contrôles sur les terminaux et les identités peuvent aider à arrêter ou contenir une attaque. L’investigation des sauvegardes peut valider les dommages et favoriser un retour au service plus éclairé.

Aucun fournisseur ne devrait transformer cette relation en faux choix. L’intelligence de reprise ne supprime pas le besoin de prévention, de surveillance, de segmentation, de réponse aux incidents ou de plans de continuité testés.

Les affirmations concurrentielles exigent une prudence similaire. Rubrik, Cohesity, Commvault et Veeam décrivent tous des capacités de détection et de reprise saine fondées sur des architectures différentes. Les comparaisons marketing reproduisent rarement les charges de travail ou contraintes de reprise réelles d’un client.

Les acheteurs ont besoin de tests fondés sur des scénarios. Une évaluation utile injecterait dans des snapshots représentatifs des modifications de fichiers suspectes, des opérations massives bénignes et un chiffrement contrôlé. Les équipes pourraient alors comparer la qualité de détection, l’explication et le temps de restauration.

Ils devraient inclure la compromission d’identité dans l’exercice. Le test devrait déterminer si la plateforme relie les changements de privilèges, la persistance, les mouvements latéraux et les données endommagées dans une séquence de reprise utile.

La facilité d’utilisation opérationnelle compte également. Des preuves que seul un spécialiste peut interpréter n’aideront pas une petite équipe lors d’un incident nocturne. Les alertes doivent guider l’action sans masquer l’incertitude.

L’annonce de Druva offre un mécanisme crédible pour réduire les conjectures, mais elle ne résout pas la question de la vérification. Les déploiements réels doivent montrer à quelle fréquence le système a raison, ce qu’il ne détecte pas et avec quelle rapidité les équipes peuvent agir.

Ce que les acheteurs d’entreprise devraient surveiller ensuite

Les prochaines preuves devraient venir d’une disponibilité élargie, de résultats de détection indépendants et d’exercices de reprise clients, plutôt que d’un branding IA supplémentaire.

Le premier signal est le passage d’une disponibilité limitée à un accès étendu en production. Druva devrait préciser quand davantage de clients pourront activer la capacité et si les charges de travail prises en charge s’étendront au-delà de son périmètre initial dans le cloud et les machines virtuelles.

Une disponibilité plus large ne renforcerait le récit du produit que si les performances restent cohérentes sur des jeux de données variés. Des retards ou une couverture étroite suggéreraient que la précision forensique est plus difficile à généraliser que ne le laisse entendre le lancement.

Le deuxième signal est une validation indépendante. Les acheteurs ont besoin de résultats mesurés sur les faux positifs et les faux négatifs, accompagnés de résultats sur les délais de reprise issus de simulations réalistes.

Une référence utile devrait inclure des changements massifs bénins, des ransomwares connus, des variantes inconnues, un chiffrement lent et des attaques qui modifient les identités avant de toucher aux fichiers. Elle devrait également expliquer le jeu de données et les seuils de décision.

Des preuves indépendantes renforceraient l’affirmation de Druva selon laquelle l’analyse en deux étapes fournit une confirmation fiable. Des résultats montrant une revue manuelle importante affaibliraient l’idée que le système remplace l’incertitude par des preuves de reprise claires.

Le troisième signal est l’adoption par les clients dans des flux de gestion d’incidents réels. La question importante est de savoir si les équipes de sécurité et de sauvegarde utilisent les mêmes preuves pour prendre une décision plus rapide et plus sûre.

Les retours des clients devraient décrire comment le système a identifié les snapshots affectés, sélectionné un point antérieur à l’attaque, validé la restauration proposée et géré les identités compromises. Des déclarations générales sur une résilience améliorée ne répondront pas à cette question.

Les réponses des concurrents méritent également l’attention, mais le nombre de fonctionnalités ne devrait pas dominer la comparaison. Le test le plus pertinent consiste à déterminer si une autre plateforme fournit des preuves plus claires, un contexte plus large ou une reprise validée plus rapide.

La détection de ransomware de Druva arrive à un moment où l’IA accélère à la fois l’activité des attaquants et l’analyse défensive. Son architecture en deux étapes confie à l’IA une mission limitée : examiner largement, valider en profondeur et relier les conclusions à la reprise.

Cette orientation est judicieuse. La question non résolue est de savoir si Druva peut maintenir cette précision lorsque les environnements clients, les méthodes des attaquants et les relations entre identités deviennent complexes.

Les responsables de la sécurité qui évaluent cette fonctionnalité devraient mener un exercice exigeant. Donnez à la plateforme un ensemble mixte de snapshots sains, inhabituels et malveillants, puis demandez à l’équipe de réponse d’effectuer la reprise sans accompagnement du fournisseur. Si les preuves permettent de prendre la bonne décision sous pression, la réponse IA de Druva a une valeur pratique. Si l’équipe doit encore reconstituer l’incident manuellement, le produit doit encore faire ses preuves.