FR3103920A1 - Procédé d’assistance pour la gestion d’une attaque informatique, dispositif et système associés. - Google Patents

Abstract

Procédé d’assistance pour la gestion d’une attaque informatique, dispositif et système associés Le procédé d’assistance selon l’invention est mis en œuvre par un dispositif (3) gérant des ressources d’un domaine informatique (2), ces ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ce procédé comprenant : - une étape de détermination d’une incapacité d’un premier service de protection parmi ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique; - une étape d’élaboration d’un plan de mitigation de ladite attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection parmi ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et - une étape de transmission du plan de mitigation élaboré au premier service de protection pour traiter l’attaque. Figure 2

Description

Procédé d’assistance pour la gestion d’une attaque informatique, dispositif et système associés.

L’invention se rapporte au domaine général des télécommunications.

Elle concerne plus particulièrement la résolution d’attaques informatiques susceptibles d’affecter les ressources d’un domaine informatique bénéficiant d’une connectivité au réseau public Internet.

L’invention s’applique notamment aux attaques informatiques de type déni de service (DoS, (pour «Denial of Service» en anglais) ou DDoS (pour «Distributed DoS» en anglais). Une attaque DoS est une tentative de rendre des ressources d’un domaine informatique, telles que par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs.

Les attaques DDoS sont souvent massives et de nature à compromettre plusieurs centaines de milliers d’équipements utilisateurs (terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, etc.), qui peuvent à leur tour être utilisés comme relais pour amplifier le pouvoir de nuisance de ces attaques. A titre indicatif, la société Symantec, dans son rapport annuel de 2019, fait état de près de 24000 applications embarquées dans des terminaux mobiles bloquées quotidiennement par de telles attaques, d’une augmentation de 600% entre 2016 et 2017 des attaques ciblant des objets connectés, et d’une augmentation de la volumétrie du trafic d’attaque entre 2016 et 2017 qui représentait 5% du trafic web global en 2016 contre 7.8% en 2017.

Les attaques DDoS sont de plus en plus fréquentes et intenses, et peuvent cibler plusieurs centaines de milliers de machines informatiques. Pour protéger leurs ressources informatiques contre de telles attaques, de nombreuses sociétés souscrivent à des offres de services de protection DPS (pour «DDoS Protection Services» en anglais). Toutefois, lorsqu’autant de machines sont impliquées dans l’exécution des attaques, la mise en place de politiques de filtrage adaptées, c’est-à-dire capables d’isoler le trafic en provenance de l’ensemble des machines affectées, est d’autant plus compliquée que ces machines peuvent être réparties sur plusieurs réseaux distincts. Ces réseaux sont eux-mêmes susceptibles d’être protégés par des offres DPS distinctes proposées et gérées par des entités administratives distinctes (indépendantes).

Lafigure 1représente, à titre illustratif, un domaine informatique client CL connecté à deux réseaux transitaires TN1 et TN2 lui fournissant un accès au réseau Internet. Chacun des réseaux transitaires héberge un service de protection DPS dédié, référencé par DPS1 pour le réseau transitaire TN1 et par DPS2 pour le réseau transitaire TN2. On suppose, dans l’exemple envisagé à la figure 1, que le domaine client CL utilise pour ses liens d’interconnexion avec les réseaux transitaires TN1 et TN2 des adresses dites PI (pour «Provider-Independent» en anglais): un même plan d’adressage est ainsi utilisé par le domaine client CL sur l’ensemble de ses liens d’interconnexion avec les réseaux transitaires TN1 et TN2, indépendamment du plan d’adressage utilisé par ces réseaux transitaires.

Il convient par ailleurs de noter que de plus en plus d’offres de protection DPS s’appuient sur des services hébergés dans le «cloud» et pas seulement au sein des infrastructures exploitées par les fournisseurs d’accès au réseau Internet. Ces déploiements dans le cloud posent des problèmes techniques notamment concernant la détection anticipée des attaques car les composantes du service DPS impliquées dans la détection ou la résolution d’attaques et hébergées dans le cloud ne sont pas forcément présentes sur les différents chemins empruntés par le trafic d’attaque, de sorte qu’elles ne sont pas en mesure d’inspecter et de filtrer ce trafic.

Les considérations précédentes ne se limitent pas bien entendu aux attaques DDoS, et restent valables pour d’autres types d’attaques, telles que des attaques par usurpation d’identité (par exemple à des fins de vol de données), des malwares de rançonnage (ou «ransomware» en anglais), etc.

Les attaques informatiques subies par les systèmes informatiques aujourd’hui sont donc protéiformes, tant par leur nature que par leur dimensionnement (volumétrie du trafic de l’attaque, amplitude de l’attaque, etc.) et leur portée de nuisance (une seule machine visée, ou plusieurs en visant le réseau local d’une entreprise, le réseau d’un opérateur, etc.). Les cibles de ces attaques ou les relais utilisés pour les propager sont en outre extrêmement variés: terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, etc.

Il s’ensuit que certains services de protection contre les attaques informatiques (services DPS ou autres suivant les attaques subies) peuvent rencontrer des difficultés pour traiter et mitiger ces attaques.

Ainsi, certains services de protection peuvent avoir une capacité de traitement et de mitigation limitée et ne pas être en mesure de traiter les attaques de forte amplitude ou correspondant à une volumétrie de trafic infecté dépassant un certain seuil. En effet, en plus de sa fonction de mitigation, un service de protection contre des attaques informatiques doit assurer la coordination des opérations d’acheminement du trafic vers le domaine informatique client qu’il protège, pour que le trafic légitime à destination de ce dernier soit acheminé normalement vers celui-ci. Pour ce faire, le service de protection doit identifier le trafic suspect puis l’isoler pour qu’il ne soit pas acheminé vers le domaine informatique client. A cet effet, il peut s’appuyer sur un centre ou une fonction dite de nettoyage (ou «scrubbing» en anglais), qui peut s’avérer sous-dimensionnée pour traiter des attaques sollicitant des ressources CPU (Central Processing Unit) ou capacitaires conséquentes. L’efficacité de la mitigation mise en œuvre par le service de protection est alors diminuée et le domaine informatique client continue de subir l’attaque en dépit de l’intervention du service de protection.

D’autres services de protection peuvent avoir une carence fonctionnelle en termes de détection et de mitigation de nouvelles attaques et échouer à mettre en place un plan de mitigation efficace contre de telles attaques, parce qu’ils ne disposent pas de mécanismes de détection et d’identification du trafic caractéristiques de ces attaques, par exemple. Les attaques les plus récentes sont en effet de plus en plus complexes à caractériser car elles peuvent faire intervenir des millions de sources, adopter une stratégie d’attaque dynamique telles que l’exploitation de plusieurs protocoles, etc.

Ces carences capacitaires ou fonctionnelles des services de protection peuvent avoir un impact non négligeable sur la mitigation (incluant le délai nécessaire à mettre en place les actions de mitigation) d’une attaque ciblant les ressources d’un domaine informatique client. A titre illustratif, considérons l’exemple de la figure 1.

Sur détection d’une attaque au sein du domaine informatique client CL et affectant en particulier l’ensemble des liens d’interconnexion raccordant le domaine client CL aux réseaux transitaires TN1 et TN2 (on note que ces liens sont impliqués dans l’acheminement du trafic de l’attaquemais ils ne sont pas forcément la cible de l’attaque), un agent AG du domaine informatique client CL sollicite les deux services de protection DPS1 et DPS2 pour la mitigation de l’attaque.

On suppose ici que le service DPS1 met en œuvre rapidement un plan de mitigation efficace car il dispose de mécanismes de détection et de mitigation adaptés au type d’attaque en cours, alors que le service DPS2 échoue à mettre en place un plan de mitigation efficace, par exemple parce qu’il ne dispose pas de mécanisme de détection et d’identification du trafic caractéristique de cette attaque. Le trafic de l’attaque est alors bloqué par le réseau transitaire TN1, mais continue d’être acheminé jusqu’au domaine client CL via le réseau transitaire TN2. Ainsi, le domaine client CL est toujours victime de l’attaque en dépit du plan de mitigation mis en place par le système DPS1.

On note qu’une attaque similaire peut être mise en œuvre si le domaine client CL utilise des adresses dites PA (Provider-Aggregatable), c’est-à-dire si les adresses utilisées sur les liens d’interconnexion qui raccordent le domaine client CL aux réseaux transitaires TN1 et TN2 sont celles fournies par chacun des fournisseurs de connectivité qui exploitent ces réseaux transitaires TN1 et TN2.

L’invention permet notamment de remédier aux inconvénients de l’état de la technique en proposant un procédé d’assistance mis en œuvre par un dispositif gérant des ressources d’un domaine informatique, lesdites ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ce procédé comprenant :
- une étape de détermination d’une incapacité d’un premier service de protection parmi ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique;
- une étape d’élaboration d’un plan de mitigation de l’attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection de la pluralité de services de protection ou utilisant une assistance fournie par au moins le deuxième service de protection; et
- une étape de transmission du plan de mitigation ainsi élaboré au premier service de protection pour traiter l’attaque.

Corrélativement, l’invention vise aussi un dispositif gérant des ressources d’un domaine informatique, configuré pour communiquer avec une pluralité de services de protection contre des attaques informatiques protégeant lesdites ressources du domaine informatique, ce dispositif comprenant :
- un module de détermination, configuré pour déterminer une incapacité d’un premier service de protection de la pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique;
- un module d’élaboration, configuré pour élaborer un plan de mitigation de ladite attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection de la pluralité de services de protection ou utilisant une assistance fournie par au moins le deuxième service de protection; et
- un module de transmission, configuré pour transmettre le plan de mitigation ainsi élaboré au premier service de protection pour traiter l’attaque.

Ainsi, l’invention propose d’exploiter la souscription par le domaine informatique à une pluralité de services de protection (pouvant être notamment, pour tout ou partie d’entre eux, gérés par des entités administratives distinctes) pour fournir dynamiquement une assistance à un service de protection incapable de gérer une attaque informatique détectée dans le domaine informatique (premier service de protection au sens de l’invention, désigné aussi par la suite par «service de protection incapable»). Cette assistance se traduit sous la forme d’un plan de mitigation élaboré et fourni au service de protection incapable, à partir d’un plan de mitigation mis en place ou déterminé par un autre service de protection (deuxième service de protection au sens de l’invention) en réponse à l’attaque, permettant ainsi de remédier à une insuffisance fonctionnelle du service de protection incapable, ou s’appuyant sur l’assistance d’un autre service de protection (deuxième service de protection au sens de l’invention), permettant ainsi de remédier à une insuffisance capacitaire du service de protection incapable.

Dans la suite, on désigne par «plan de mitigation» un ensemble d’actions élaborées pour la résolution d’une attaque. Ces actions ont pour but d’empêcher le trafic de l’attaque de se propager dans le domaine informatique. Il peut s’agir d’actions de mitigation à proprement parler mises en place ou élaborées par un service de protection, mais également inclure une assistance fournie par un service de protection pour étendre les capacités du service de protection incapable et lui permettre de résoudre l’attaque, etc.

Aucune limitation n’est attachée à la nature des ressources qui peuvent être la cible d’une attaque; il peut s’agir par exemple d’une adresse IP, d’un préfixe IP, d’une machine, d’un alias, d’un nom de domaine pleinement qualifié (FQDN pour Fully Qualified Domain Name en anglais), etc.

Ainsi, l’invention ne se limite pas à une application locale du plan de mitigation élaboré au sein du domaine informatique, application qui n’est pas toujours possible selon l’état des ressources affectées par l’attaque; mais elle prévoit également la transmission du plan de mitigation élaboré au service de protection incapable pour pallier ses carences. Cela permet, lorsque le service de protection protège des ressources telles que des liens d’interconnexion du domaine informatique avec le réseau Internet ou des réseaux transitaires, de bloquer de manière anticipée le trafic de l’attaque, en amont et/ou en entrée du domaine informatique client.

On note que l’invention n’est pas restreinte à un premier service de protection protégeant des ressources du domaine informatique ciblées par l’attaque. Elle peut également s’appliquer à un premier service de protection protégeant des ressources du domaine informatique impliquées dans l’acheminement du trafic de l’attaque vers les ressources ciblées par celle-ci. Ainsi, on envisage ici une attaque relevant du périmètre d’action du premier service de protection.

Ces considérations s’appliquent également au deuxième service de protection. On note toutefois que dans certains modes de réalisation décrits plus en détail ultérieurement, l’attaque peut ne pas relever du périmètre d’action du deuxième service de protection.

Avantageusement, conformément à l’invention, le plan de mitigation transmis au service de protection incapable est élaboré par un dispositif gérant les ressources du domaine informatique qui sont protégées par la pluralité de services de protection, aussi parfois désigné ici par «domaine client» ou encore «domaine informatique client». Les services de protection pouvant être gérés par des entités administratives distinctes, ils n’ont pas nécessairement connaissance des actions de mitigation mises en œuvre par les autres services de protection protégeant des ressources du domaine client. Au contraire, le domaine client dispose d’une visibilité globale sur les actions mises en œuvre pour protéger ses ressources, et l’invention exploite avantageusement cette visibilité pour coordonner et améliorer l’efficacité des efforts de mitigation entrepris par les services de protection en présence d’une attaque détectée dans le domaine client. Il résulte de ce pilotage par le domaine client un meilleur temps de réaction et de traitement des attaques ainsi qu’une rapidité d’exécution accrue des actions de mitigation. On garantit de la sorte la continuité des services offerts par le domaine informatique.

A titre illustratif, dans l’exemple précédemment décrit en référence à la figure 1, en cas de carence fonctionnelle du service de protection DPS1, l’invention permet d’exploiter la connaissance de l’attaque par le service de protection DPS2 et d’un plan de mitigation efficace de celle-ci en élaborant et en fournissant au service de protection DPS1 un plan de mitigation élaboré à partir du plan de mitigation mis en œuvre par le service de protection DPS2. Ainsi, il est possible de bloquer efficacement l’attaque ciblant le domaine informatique puisque dès lors, les services de protection DPS1 et DPS2 protégeant les liens d’interconnexion du domaine client CL affectés par l’attaque sont en mesure de mettre en place des politiques de filtrage du trafic de l’attaque entrant dans le domaine client CL.

Grâce à l’invention, la gestion de l’attaque affectant le domaine informatique est donc améliorée, non seulement individuellement au niveau de chaque service de protection, mais également au niveau de l’action globale menée par l’ensemble des services de protection. On note que cette amélioration est avantageusement obtenue sans avoir à modifier ou à étendre la visibilité du trafic dont dispose chacun des services de protection. Concrètement, les différents services de protection continuent de n’avoir qu’une visibilité partielle du trafic associé au domaine client et non le trafic global dudit domaine client.

L’invention permet ainsi une résolution rapide, automatique et fiable des attaques informatiques susceptibles d’affecter les ressources d’un domaine informatique. Grâce à l’exploitation des actions de mitigation mises en œuvre par différents services de protection, l’invention offre la possibilité de traiter des attaques affectant l’ensemble des ressources du domaine informatique.

On note qu’aucune limitation n’est attachée à la nature des attaques informatiques concernées (déni de service, usurpation d’identité, ransomware, etc.), ni à la nature des ressources informatiques du domaine impactées (ressources de calcul, ressources réseau, liens d’interconnexion avec d’autres réseaux, etc.).

Dans un mode particulier de réalisation:
- le deuxième service de protection a mis en place un plan de mitigation en réponse à l’attaque;
- ladite incapacité du premier service de protection provient d’une méconnaissance de l’attaque par le premier service de protection; et
- le plan de mitigation transmis au premier service de protection est élaboré en adaptant le plan de mitigation mis en place par le deuxième service de protection aux ressources du domaine informatique protégées par le premier service de protection.

Ce mode de réalisation permet plus particulièrement de gérer une incapacité fonctionnelle du premier service de protection, alors que le deuxième service de protection est en mesure de traiter cette attaque et a mis en place un plan de mitigation efficace à cet effet. Le plan de mitigation fourni au premier service de protection est alors dérivé du plan de mitigation mis en place par le deuxième service de protection. On note que le plan de mitigation dérivé n’est pas forcément une copie à l’identique du plan de mitigation fourni par un premier service de protection. Il peut être inspiré de celui-ci et/ou reprendre et/ou adapter tout ou partie des actions indiquées dans celui-ci, pour tenir compte par exemple de contraintes qui sont propres au premier service de protection.

Dans un autre mode de réalisation, lorsquel’attaque relève du périmètre d’action du premier service de protection uniquementet l’incapacité du premier service de protection provient d’une méconnaissance de l’attaque par le premier service de protection, le procédé comprend en outre:
- une étape d’envoi au deuxième service de protection d’une requête d’émulation de l’attaque sur au moins une ressourcedu domaine informatique protégée par le deuxième service de protection; et
- une étape d’obtention d’un plan de mitigation proposé lors de l’émulation de l’attaque par le deuxième service de protection pour traiter cette attaque;
le plan de mitigation transmis au premier dispositif étant élaboré à partir du plan de mitigation obtenu lors de l’étape d’obtention en l’adaptant aux ressources du domaine informatique protégées par le premier service de protection.

Ce mode de réalisation vise également à pallier une carence fonctionnelle du premier service de protection. Toutefois, il vise un contexte dans lequel l’attaque relève uniquement du périmètre d’action du premier service de protection(en d’autres termes, l’attaque vise des ressources du domaine informatique protégées par le premier service de protection ou celui-ci protège des ressources du domaine informatique impliquées dans l’acheminement du trafic de l’attaque vers les ressources ciblées par cette dernière). Le deuxième service de protection n’étant pas concerné directement par l’attaque affectant le domaine informatique, il n’a pas mis en place à proprement parler d’action de mitigation contre cette attaque. Cela ne l’empêche pas pour autant d’être en mesure de traiter cette attaque (autrement dit d’identifier le trafic de l’attaque et de savoir comment le filtrer efficacement), et c’est cette capacité qu’exploite l’invention dans ce mode de réalisation, en ordonnant au deuxième service de protection d’émuler l’attaque sur les ressources du domaine informatique qu’il protège et de proposer un plan de mitigation en réponse à cette attaque.

Il convient de noter que le plan de mitigation proposé par le deuxième service de protection correspond alors aux ressources du domaine informatique protégées par le deuxième service de protection (typiquement identifiées par des adresses ou préfixes IP dédiés), et non aux ressources protégées par le premier service de protection ciblées par l’attaque. L’élaboration d’un plan de mitigation destiné au premier service de protection consiste alors notamment en une adaptation par le dispositif gérant les ressources du domaine informatique du plan de mitigation proposé par le deuxième service de protection aux ressources protégées par le premier service de protection.

Dans un autre mode de réalisation, l’incapacité du premier service de protection provient d’une insuffisance de ressources disponibles au niveau du premier système de protection pour mitiger l’attaque, le procédé comprenant une étape d’obtention auprès du deuxième service de protection d’au moins une information permettant un établissement d’une communication entre le premier système de protection et le deuxième système de protection pour l’assister dans la mitigation de l’attaque, le plan de mitigation transmis au premier système de protection comprenant ladite au moins une information obtenue.

L’assistance fournie par le deuxième service de protection est alors dans ce mode de réalisation une assistance capacitaire pour traiter l’attaque, permettant de pallier à une insuffisance de ressources du premier service de protection pour résoudre l’attaque, par exemple en raison de l’amplitude de l’attaque. Ce mode de réalisation permet d’étendre artificiellement les ressources du premier service de protection pour résoudre de manière efficace l’attaque. Grâce à la communication établie entre le premier et le deuxième service de protection, le premier service de protection peut par exemple rediriger une partie du trafic destiné au domaine informatique vers le deuxième service de protection pour que celui-ci le filtre.

On peut bien entendu envisager d’établir une communication sécurisée entre les deux services de protection, par exemple au moyen d’un tunnel sécurisé.

On note en outre que l’assistance capacitaire fournie au premier service de protection peut provenir de plusieurs services de protection parmi la pluralité de services de protection protégeant les ressources du domaine informatique.

Dans un mode particulier de réalisation, le procédé comprend:
- une étape d’interrogation de tout ou partie de la pluralité de services de protection protégeant des ressources du domaine informatique pour déterminer les services de protection aptes à fournir une assistance pour mitiger une attaque informatique à au moins un autre service de protection de la pluralité de services de protection; et
- une étape de mémorisation, pour chaque service de protection se déclarant apte, d’au moins une information fournie par ce service de protection permettant une mise en œuvre de cette assistance.

L’interrogation peut se faire par exemple en amont de la détection d’une attaque. Ce mode de réalisation permet d’anticiper les problèmes liés à une défaillance capacitaire de l’un des services de protection. A partir des informations mémorisées, lorsqu’il est informé d’une telle défaillance, le dispositif gérant les ressources du domaine informatique client peut agir plus rapidement pour mettre en place une assistance auprès du service de protection défaillant.

En variante, l’étape d’interrogation peut être mise en œuvre suite à la détection d’une attaque ciblant au moins une ressource du domaine informatique.

Ce mode de réalisation permet d’obtenir des informations à jour, représentatives d’un état courant des services de protection aptes à fournir leur assistance.

Les informations fournies par les services de protection aptes à fournir une assistance peuvent être de différentes natures. Elles comprennent par exemple au moins un élément parmi:
- une capacité disponible au niveau dudit service de protection apte à fournir une assistance et utilisée par ladite assistance, de façon à faciliter la sélection d’un service de protection approprié pour fournir une assistance à un service de protection défaillant;
- une information permettant l’établissement d’une communication avec ledit service de protection apte à fournir une assistance;
- au moins une clé de sécurité destinée à être utilisée lors de ladite assistance avec le service de protection apte à fournir une assistance, ou tout autre élément permettant de sécuriser la communication entre le service de protection apte à fournir une assistance et le service de protection défaillant;
- une durée de vie de l’assistance fournie par ledit service de protection apte à fournir une assistance. De la sorte, lorsque cette durée de vie a expiré, le dispositif du domaine informatique client se tourne vers un autre service de protection et le service de protection qui n’est plus apte à fournir une telle assistance n’est pas sollicité inutilement.

Cette liste n’est bien entendu pas limitative.

Dans un mode particulier de réalisation, lors de l’étape d’interrogation, le dispositif indique aux services de protection interrogés une capacité minimale dont doit disposer un service de protection se déclarant apte pour fournir l’assistance.

Pour évaluer cette capacité minimale, le dispositif peut s’appuyer sur des mécanismes de prévision de trafic (ou «traffic forecast» en anglais), connus en soi. Cette capacité minimale peut être ensuite réévaluée au cas par cas suivant les besoins d’un service de protection défaillant.

Ce mode de réalisation permet d’éviter la sélection par le dispositif du domaine informatique client d’un service de protection n’ayant pas des ressources capacitaires suffisantes pour fournir une assistance à un service de protection défaillant, et donc une perte de temps dans l’exécution du procédé selon l’invention.

Dans un mode particulier de réalisation, le procédé comprend, après détection de l’attaque, une étape d’envoi à tout ou partie des services de protection de la pluralité de services de protection ayant un périmètre d’action dans lequel se trouve au moins une ressource du domaine informatique ciblée par l’attaque, d’une requête d’obtention d’un plan de mitigation mis en place par ces services de protection en réponse à l’attaque.

Autrement dit, dans ce mode de réalisation, les services de protection fournissent leurs plans de mitigation mis en place le cas échéant contre l’attaque détectée, en réponse à une sollicitation du dispositif du domaine informatique client.

En variante, on peut envisager la mise en place d’un mécanisme d’annonce spontanée par les services de protection des plans de mitigation en cours d’exécution. Le dispositif gérant les ressources du domaine informatique peut à cet effet par exemple s’inscrire auprès de chaque service de protection pour être informé par celui-ci des plans de mitigation qu’il met en place.

Dans un mode particulier de réalisation, lorsque l’attaque cible des ressources protégées par plusieurs services de protection de la pluralité de services de protection, le procédé comprend:
- une étape de vérification de la compatibilité des plans de mitigation mis en place en réponse à ladite attaque par lesdits plusieurs services de protection; et
- si au moins une incompatibilité est détectée entre des plans de mitigation lors de l’étape de vérification, une étape de coordination d’un ajustement de tout ou partie des plans de mitigation incompatibles de sorte à éliminer ladite au moins une incompatibilité.

Le dispositif gérant les ressources du domaine informatique client coordonne ainsi les actions de mitigation mises en place par les différents services de protection concernés par l’attaque (autrement dit, dans le périmètre d’action dont relève l’attaque) de sorte à éviter des incohérences entre ces actions.

En effet, comme mentionné précédemment, les services de protection étant susceptibles d’être gérés par des entités administratives distinctes, ils n’ont aucune visibilité mutuelle sur les actions mises en œuvre par les autres services de protection en présence d’une attaque, contrairement au domaine informatique client. Ainsi, un (ou plusieurs) service de protection peut prendre des décisions de mitigation qui peuvent avoir des implications négatives sur le service fourni au domaine informatique client, notamment parce qu’elles ne sont pas cohérentes avec d’autres décisions prises par un autre service de protection en réponse à l’attaque. Par exemple, des décisions prises par deux (ou plus) services de protection différents peuvent conduire à l’établissement d’une boucle de routagequi empêche le trafic légitime d’être acheminé vers le domaine informatique client.

Au vu de ce qui précède, il apparait que l’invention s’appuie sur le dispositif gérant les ressources du domaine informatique qui sont protégées par différents services de protection contre des attaques informatiques, mais également sur l’action de ces derniers.

Ainsi, selon un autre aspect, l’invention vise également un procédé d’obtention, par un premier service de protection d’une pluralité de services de protection contre des attaques informatiques protégeant des ressources d’un domaine informatique, d’un plan de mitigation d’une attaque informatique ciblant au moins une des ressources du domaine informatique, ce procédé comprenant, suite à une détection d’une incapacité du premier service de protection à traiter l’attaque:
- une étape de réception d’un plan de mitigation élaboré par le dispositif à partir d’un plan de mitigation obtenu d’un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins le deuxième service de protection ; et
- une étape de mise en place, en réponse à l’attaque, d’un plan de mitigation de l’attaque dérivé du plan de mitigation reçu du dispositif pour traiter l’attaque.

Corrélativement, l’invention concerne aussi un dispositif d’un premier service de protection d’une pluralité de services de protection contre des attaques informatiques protégeant des ressources d’un domaine informatique, au moins une des ressources du domaine informatique étant ciblée par une attaque informatique, ledit dispositif comprenant des modules activés suite à une détection d’une incapacité du dispositif à traiter l’attaque, ces modules comprenant:
- un module de réception, configuré pour recevoir un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique à partir d’un plan de mitigation obtenu d’un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et
- un module de mise en place, configuré pour mettre en place en réponse à ladite attaque un plan de mitigation dérivé du plan de mitigation reçu du dispositif pour traiter l’attaque.

Le procédé d’obtention et le dispositif du premier service de protection bénéficient des mêmes avantages cités précédemment que le procédé d’assistance et le dispositif du domaine informatique.

Dans un mode particulier de réalisation, l’étape de mise en place du plan de mitigation comprend, lorsque le plan de mitigation utilise une assistance fournie par au moins le deuxième service de protection, un acheminement de données suspectées d’être associées à l’attaque vers le deuxième service de protection pour un traitement de ces données.

Les données sont par exemple acheminées vers le deuxième service de protection via un tunnel sécurisé établi avec le deuxième service de protection au moyen d’informations contenues dans le plan de mitigation reçu du dispositif.

L’assistance fournie par le deuxième service de protection (et éventuellement d’autres services de protection) permet au premier service de protection de se délester d’une partie du trafic suspect qu’il n’est pas en mesure de traiter et de l’acheminer vers le deuxième service de protection pour qu’il applique un plan de mitigation approprié à ce trafic suspect.

Dans un mode particulier de réalisation de l’invention, le procédé d’assistance et/ou le procédé d’obtention sont mis en œuvre par un ordinateur.

Dans un mode particulier de réalisation de l’invention, le procédé d’assistance et/ou le procédé d’obtention sont mis en œuvre par un ordinateur non directement connecté au domaine informatique (par ex., un smartphone) mais apte à gérer les ressources dudit domaine informatique.

L’invention vise également un premier programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif gérant les ressources d’un domaine informatique client conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’assistance tel que décrit ci-dessus.

L’invention vise aussi un deuxième programme d’ordinateur sur un support d’enregistrement, ce programme étant susceptible d’être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif d’un premier service de protection contre des attaques informatiques conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé d’obtention tel que décrit ci-dessus.

Chacun de ces programmes peut utiliser n’importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet, tel que dans une forme partiellement compilée, ou dans n’importe quelle autre forme souhaitable.

L’invention vise aussi un support d'information ou un support d’enregistrement lisibles par un ordinateur, et comportant des instructions du premier, du deuxième ou du troisième programme d'ordinateur mentionné ci-dessus.

Les supports d'information ou d’enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.

D'autre part, les supports d'information ou d’enregistrement peuvent être des supports transmissibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par lien radio, par lien optique sans fil ou par d'autres moyens.

Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type Internet.

Alternativement, chaque support d'informations ou d’enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de communication, conforme à l’invention, ou du procédé de sélection, conforme à l’invention.

L’invention vise aussi un système de protection d’un domaine informatique comprenant:
- une pluralité de services de protection contre des attaques informatiques protégeant des ressources du domaine informatique;
- un dispositif gérant lesdites ressources du domaine informatique conforme à l’inventionet configuré pour communiquer avec lesdits services de protection;
ladite pluralité de services de protection comprenantau moins:
- un premier service de protection comportant un dispositif selon l’invention incapable de traiter une attaque informatique ciblant au moins une ressource du domaine informatique; et
- un deuxième service de protection ayant mis en place un plan de mitigation de ladite attaque ou apte à fournir une assistance au premier service de protection pour traiter ladite attaque sur lequel ledit dispositif gérant lesdites ressources du domaine informatique s’appuie pour élaborer et transmettre audit premier service de protection un plan de mitigation de l’attaque.

Dans un mode particulier de réalisation, le deuxième service de protection comprend :
- un module d’émulation, activé sur requête du dispositif du domaine informatique lorsque l’attaque relève du périmètre d’action du premier service de protection uniquement, ledit module d’émulation étant configuré pour émuler ladite attaque sur au moins une ressource du domaine informatique protégée par le deuxième service de protection; et
- un module de transmission, configuré pour transmettre au dispositif du domaine informatique un plan de mitigation de l’attaque proposé par le deuxième service de protection lors de l’émulation de ladite attaque par le module d’émulation.

Dans un mode particulier de réalisation, le deuxième service de protection comprend un module de fourniture, activé sur requête du dispositif gérant les ressources du domaine informatique lorsque ladite attaque se trouve dans le périmètre d’action du deuxième service de protection, ledit module de fourniture étant configuré pour fournir au dispositif gérant les ressources du domaine informatique un plan de mitigation mis en place par le deuxième service de protection en réponse à l’attaque.

Le système selon l’invention bénéficie des mêmes avantages cités précédemment pour le procédé d’assistance, le procédé d’obtention, le dispositif du domaine informatique et le dispositif du premier service de protection selon l’invention.

On peut également envisager, dans d'autres modes de réalisation, que le procédé d’assistance, le procédé d’obtention, le dispositif gérant les ressources du domaine informatique, le dispositif du premier service de protection et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.

D’autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures:
la figure 1, déjà décrite, représente un domaine informatique protégé par deux services de protection contre des attaques informatiques, selon l’état de la technique ;
la figure 2 représente un système de protection d’un domaine informatique conforme à l’invention dans un mode particulier de réalisation ;
la figure 3 représente l’architecture matérielle d’un dispositif gérant les ressources du domaine informatique protégées par le système de protection de la figure 2, dans un mode particulier de réalisation;
la figure 4 représente l’architecture matérielle d’un dispositif serveur d’un service de protection du système de protection de la figure 2, dans un mode particulier de réalisation;
la figure 5 représente les principales étapes d’un procédé d’assistance selon l’invention telles qu’elles sont mises en œuvre, dans un mode particulier de réalisation, par le dispositif de la figure 3;
la figure 6 représente les principales étapes d’un procédé d’obtention selon l’invention telles qu’elles sont mises en œuvre, dans un mode particulier de réalisation, par un dispositif serveur du système de protection de la figure 2 ; et
la figure 7 représente des étapes pouvant être mises en œuvre, dans un mode particulier de réalisation, par un dispositif serveur du système de protection de la figure 2.
Description de l’invention

Lafigure 2représente un système 1 de protection d’un domaine informatique 2 contre des attaques informatiques, conforme à l’invention, dans un mode particulier de réalisation.

On entend ici par domaine informatique, aussi désigné par domaine informatique client ou domaine client, un ensemble de ressources informatiques (incluant notamment des ressources réseaux telles que des routeurs, commutateur, serveurs, terminaux, etc.), placées sous la responsabilité d’une entité administrative donnée. Un tel domaine informatique est par exemple un réseau d’entreprise, un réseau domestique ou un système autonome ou AS (pour «Autonomous System») utilisant le protocole BGP (pour «Border Gateway Protocol» en anglais). Toutefois, aucune limitation n’est attachée à la nature du domaine ni au type de protocoles utilisés au sein du domaine informatique 2.

Le domaine informatique 2 est connecté au réseau public Internet, directement ou via un ou plusieurs réseaux transitaires. Il possède diverses ressources informatiques (ressources CPU, ressources mémoires, ressources réseau, liens d’interconnexion avec d’autres réseaux, etc.), protégées par une pluralité de services de protection contre des attaques informatiques SP1, SP2, …, SPN, auxquels a souscrit l’administrateur ou le propriétaire du domaine informatique 2, N désignant un nombre entier supérieur à 1. Par souci de simplification, sur la figure 2, trois services de protection SP1, SP2 et SP3 sont représentés, toutefois le nombre N peut être un entier quelconque supérieur à 1.

Tout ou partie des services de protection SP1, SP2, …, SPN, protégeant les ressources du domaine informatique 2, et en particulier dans l’exemple envisagé ici SP1, SP2 et SP3, sont gérés par des entités administratives (par exemple, par des opérateurs de réseaux) distinctes. En d’autres termes, chacune de ces entités administratives n’a pas de visibilité sur les actions de mitigation d’attaques mises en place par les autres entités administratives et leurs propres services de protection (c’est-à-dire pas de connaissancea prioride ces actions de mitigation). Dans la suite de la description, on entend par «plan de mitigation» des actions proposées ou mises en place par un service de protection pour la résolution d’une attaque, en vue notamment d’empêcher le trafic de l’attaque de se propager pour atteindre une ou plusieurs cibles dans le domaine informatique 2.

Aucune limitation n’est attachée à la localisation de ces services de protection SP1, SP2, …, SPN. Ils peuvent être hébergés sur un ou plusieurs dispositifs (par exemple sur un ou des serveurs) se trouvant dans un système informatique en nuage (plus communément désigné par «cloud»), dans le réseau Internet, ou dans des réseaux transitaires fournissant au domaine informatique client 2 un accès au réseau Internet, etc. Ainsi, par services de protection SPk, k=1, …, N, on entend ici aussi bien le service en lui-même fourni au domaine informatique 2 que le ou les dispositifs hébergeant la logique de ce service. Aussi, aucune hypothèse n’est faite quant à la structure fonctionnelle et organique d’un service DPS.

On considère ici, à titre illustratif, l’exemple d’attaques de dénis de service distribué (ou DDoS) et on suppose que le domaine informatique 2 comprend une (ou plusieurs) fonctions de détection d’attaques DDoS. Toutefois, l’invention s’applique à tout type d’attaque informatique (déni de service, usurpation d’identité, ransomware, etc.). En outre, aucune limitation n’est attachée à la nature des ressources qui peuvent être la cible d’une attaque; il peut s’agir par exemple d’une adresse IP, d’un préfixe IP, d’une machine, d’un alias, d’un nom de domaine pleinement qualifié (FQDN pour Fully Qualified Domain Name en anglais), etc.

Dans le mode de réalisation décrit ici, le système de protection 1 s’appuie sur une architecture client/serveur DOTS (pour «DDoS Open Threat Signaling») telle que définie par l’IETF (Internet Engineering Task Force). De façon connue, l’architecture DOTS spécifiée par l’IETF a pour objectif de fournir un mécanisme de signalisation de détection de trafic suspect voire d’attaque avérée, de sorte que des mesures de mitigation appropriées puissent être mises en œuvre le plus rapidement possible. Plus particulièrement, elle permet à un client dit client DOTS qui gère un domaine informatique d’informer un serveur dit serveur DOTS de la détection d’un trafic suspect potentiellement caractéristique d’une attaque DDoS en cours et que des actions de mitigation appropriées sont requises. Le serveur DOTS peut alors mettre en place ou coordonner diverses actions pour que, par exemple, le trafic associé à l’attaque de déni de service ne soit plus acheminé vers le domaine informatique du client DOTS, et que seul le trafic consenti (c’est-à-dire légitime) soit acheminé vers ledit domaine informatique. On note que le client DOTS n’est pas nécessairement un élément réseau du domaine informatique en question, mais peut être connecté indirectement à ce dernier; il peut s’agir par exemple d’un réseau de contrôle ou d’un terminal (par exemple, un smartphone) d’un administrateur du domaine informatique, etc.

A cet effet, deux canaux de communication DOTS sont définis entre le client DOTS et le serveur DOTS:
- un canal de signalisation DOTS («DOTS Signal Channel», en anglais) : ce canal est utilisé seulement pendant la durée des attaques DDoS. Ainsi, le client DOTS peut utiliser ce canal pour demander de l’aide au serveur DOTS en l’informant qu’une attaque est en cours. La table 1 illustre un exemple de requête de mitigation pouvant être envoyée via un canal de signalisation DOTS «draft-ietf-dots-signal-channel» (correspondant à une cible de l’attaque identifiée par l’attribut «ietf-dots-signal-channel:mitigation-scope» dans la table 1), par un client DOTS identifié par un identifiant unique CUID (pour «Client Unique Identifier») «mydotsclient», à son serveur DOTS, pour l’informer que le préfixe «1.2.3.0/24» (identifié dans le champ «target-prefix») subit une attaque DDoS. Sur réception d’une telle requête de mitigation (reconnaissable à la nature de la requête (PUT) et à la présence des attributs Uri-Path ("mitigate") et («mid»)), le serveur DOTS, après vérification que ce client est autorisé à demander des actions pour «1.2.3.0/24», prend les mesures adéquates pour mettre fin à l’attaque si cette demande n’est pas en conflit avec d’autres demandes provenant d’autres clients du même domaine informatique ou avec une règle de filtrage installée par un autre client DOTS du domaine, et si le serveur est habilité à/configuré pour honorer la dernière requête de mitigation reçue. En cas de conflit, le serveur renvoie un message d’erreur «4.09 Conflict» pour informer le client; et
- un canal de données DOTS («DOTS Data Channel» en anglais) : ce canal est utilisé si et seulement aucune attaque n’est en cours. Le client DOTS peut par exemple utiliser ce canal pour installer des règles de filtrage (ou ACL pour «Access Control List») telles que le filtrage du trafic reçu de certaines adresses ou destiné à une machine donnée. La table 2 fournit l’exemple d’un message envoyé sur un canal de données DOTS «draft-ietf-dots-data-channel» (correspondant à un filtre caractérisé par l’attribut «ietf-dots-data-channel:access-lists» dans la table 2), par un client DOTS ayant comme identifiant CUID «mydotsclient», demandant à un serveur DOTS de bloquer («actions»: {"forwarding": "drop"}) tout le trafic à destination du préfixe «1.2.3.0/24». Sur réception d’une telle demande (reconnaissable à la nature de la requête (POST), de la «Request-URI» («/restconf/data/ietf-dots-data-hannel:dots-data/dots-client=mydotsclient»), après vérification que ce client DOTS est autorisé à demander l’installation de règles de filtrage pour le préfixe «1.2.3.0/24», le serveur DOTS procède à l’installation des règles de filtrage si cette demande n’est pas en conflit avec d’autres demandes provenant d’autres clients du même domaine informatique ou avec une règle de filtrage existante. En cas de conflit avec d’autres règles maintenues par le serveur DOTS, ce dernier renvoie un message d’erreur "4.09 Conflict" pour informer le client DOTS.

Ces différents canaux sont décrits plus en détail respectivement dans les documents de T. Reddy et al. intitulé «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification», et de M. Boucadair et al. intitulé «Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Specification», édités par l’IETF en 2019.

Table [1]

Table [2]

DOTS est donc une architecture destinée à faciliter la prise en charge de requêtes de mitigation d’attaques émises par un client DOTS et reçues par un serveur DOTS, comme par exemple un serveur exploité par un fournisseur de service de protection contre des attaques informatiques.

On suppose ici que le domaine informatique 2 comprend un dispositif 3, conforme à l’invention, en charge de la gestion et de la surveillance de l’ensemble des ressources informatiques du domaine informatique 2, et les services de protection SP1, …, SPN, comprennent des dispositifs 4-1, …, 4-N respectivement, également conformes à l’invention, le dispositif 3 et les dispositifs 4-1, …, 4-N étant susceptibles d’interagir entre eux selon les principes qui viennent d’être décrits et caractéristiques de l’architecture client/serveur DOTS. Dans ce mode de fonctionnement, le dispositif 3 agit comme un client DOTS (on le désigne par souci de simplification dans la suite par «dispositif client 3») et les dispositifs 4-1, 4-2, …, 4-N comme des serveurs DOTS. L’invention s’applique toutefois à d’autres architectures et/ou à d’autres protocoles permettant aux dispositifs 3, 4-1, …, 4-N de communiquer entre eux.

On note que par souci de simplification, dans l’exemple envisagé sur la figure 2, le dispositif client 3 et les dispositifs serveurs 4-1, …, 4-N communiquent directement entre eux (après éventuellement une authentification préalable du dispositif client DOTS 3 par les dispositifs serveurs DOTS 4-1, …, 4-N). En variante, les communications DOTS entre un client DOTS et un serveur DOTS peuvent se faire via des relais (ou «DOTS Gateways» en anglais). Ces relais peuvent être hébergés au sein du domaine du client DOTS (désigné aussi par «domaine client») ou au sein du domaine du serveur (désigné aussi par «domaine serveur») ou dans les deux. Un relai DOTS localisé dans un domaine du client est considéré par un serveur DOTS comme un client DOTS. Un relai DOTS localisé dans un domaine serveur est considéré par un client DOTS comme un serveur DOTS.

On note par ailleurs qu’en cas de présence d’un relai DOTS dans un domaine serveur, l’authentification des clients DOTS est de la responsabilité du relai. Un serveur DOTS doit être configuré avec la liste des relais DOTS actifs au sein de son domaine; il peut alors déléguer certaines de ses fonctions à ces relais de confiance. De plus, le serveur DOTS peut utiliser en toute sécurité les informations fournies par un relai figurant dans une liste déclarée auprès du serveur DOTS et maintenue par celui-ci, moyennant une procédure d’authentification ad hoc (par exemple, configuration explicite de la liste des relais par l’administrateur habilité du serveur, récupération de la liste auprès d’un serveur AAA (pour «Authentication, Authorization and Accounting» en anglais), etc.).

Dans le mode de réalisation décrit ici, le dispositif client 3 est configuré pour établir avec les dispositifs serveurs 4-1, …, 4-N des services de protection SP1, …, SPN (ou des relais DOTS localisés dans les domaines informatiques hébergeant les dispositifs serveurs 4-1, …, 4-N) des sessions DOTS sécurisées conformément à la spécification IETF précitée intitulée «Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification». En particulier, les sessions sont établies ici en utilisant le protocole DTLS (pour «Datagram Transport Layer Security» en anglais), ou le protocole TLS (pour «Transport Layer Security» en anglais). Les détails des échanges TLS/DTLS et ceux concernant la gestion d’éventuelles clés de sécurité ne sont pas reproduits ici.

En outre, dans le mode de réalisation décrit ici, on suppose que les différents agents (clients, serveurs et relais) DOTS impliqués (c’est-à-dire le dispositif client DOTS 3 et les dispositifs serveurs DOTS 4-1, …, 4-N ou relais entre ces dispositifs DOTS) sont configurés pour s’authentifier mutuellement. On s’assure ainsi que les messages DOTS reçus d’une machine usurpant l’identité d’un dispositif serveur DOTS 4-1, …, 4-N légitime sont rejetés par le dispositif client 3 DOTS. De la même manière, les demandes de dispositifs clients DOTS non-autorisés à accéder au service offert par le dispositif serveur DOTS 4-1, …, 4-N considéré sont ignorées par ce dernier.

Dans le mode de réalisation décrit ici, le dispositif client DOTS 3 a l’architecture matérielle d’un ordinateur, telle que représentée à lafigure 3. Il comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 lui permettant notamment de communiquer, en utilisant en particulier le protocole DOTS, avec les dispositifs serveurs 4-1, …, 4-N des services de protection SP1, …, SPN. Ces moyens de communication 9 s’appuient sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici.

La mémoire morte 7 du dispositif client 3 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 5 et sur lequel est enregistré un programme d’ordinateur PROG3 conforme à l’invention, comportant des instructions pour l’exécution des étapes d’un procédé d’assistance selon l’invention. Le programme PROG3 définit des modules fonctionnels du dispositif client 3, qui s’appuient ou commandent les éléments matériels 5 à 9 du dispositif client 3 cités précédemment, et qui comprennent notamment (cf. figure 2) :
- un module de détermination 3A, configuré pour déterminer une incapacité d’un premier service de protection parmi la pluralité de services de protection SP1, …, SPN, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique 2, et relevant du périmètre d’action du premier service de protection;
- un module d’élaboration 3B, configuré pour élaborer un plan de mitigation de ladite attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection parmi la pluralité de services de protection SP1, …, SPN, ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et
- un module de transmission 3C, configuré pour transmettre le plan de mitigation élaboré au premier service de protection pour traiter l’attaque.

On note que le dispositif client 3 peut également comprendre une fonction de détection d’attaque DDoS. Dans le mode de réalisation décrit ici, on suppose toutefois que cette fonction de détection d’attaque DDoS est hébergée par un autre dispositif 10 du domaine informatique 2 (cf. figure 2).

Les différentes fonctions mises en œuvre par les modules 3A à 3C du dispositif client 3 sont détaillées davantage ultérieurement.

De façon similaire, dans le mode de réalisation décrit ici, chaque dispositif serveur DOTS 4-1, …, 4-N a l’architecture matérielle d’un ordinateur, telle que représentée à lafigure 4. Il comprend notamment un processeur 11, une mémoire vive 12, une mémoire morte 13, une mémoire non volatile 14, et des moyens de communication 15 lui permettant notamment de communiquer, en utilisant en particulier le protocole DOTS, avec le dispositif client 3. Ces moyens de communication 15 s’appuient sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici.

La mémoire morte 13 de chaque dispositif serveur 4-k, k=1,…N constitue ici un support d’enregistrement conforme à l’invention, lisible par le processeur 11 et sur lequel est enregistré un programme d’ordinateur PROG4 conforme à l’invention, comportant des instructions pour l’exécution des étapes d’un procédé d’obtention selon l’invention. Le programme PROG4 définit des modules fonctionnels du dispositif serveur 4-k, qui s’appuient ou commandent les éléments matériels 11 à 15 cités précédemment, et qui comprennent notamment (cf. figure 2) un module de réception 4A et un module de mise en place 4B, activés suite à une détection d’une incapacité du dispositif serveur 4-k à traiter une attaque informatique ciblant une ou des ressources du domaine informatique 2.

Plus particulièrement, le module de réception 4A est configuré pour recevoir un plan de mitigation élaboré par le dispositif client 3 à partir d’un plan de mitigation obtenu d’un autre service de protection (deuxième service au sens de l’invention) SPj, j=1…N et j≠k ou utilisant une assistance fournie par au moins un tel autre service de protection. Le module de mise en place 4B est quant à lui configuré pour mettre en place en réponse à l’attaque informatique un plan de mitigation dérivé du plan de mitigation reçu du dispositif client 3.

Dans le mode de réalisation décrit ici, chaque dispositif serveur 4-k, k=1…N, comporte également les modules fonctionnels (et logiciels ici) suivants:
- un module de fourniture 4C, le cas échéant, d’un plan de mitigation mis en place par le dispositif serveur 4-k en réponse à une attaque détectée sur les ressources du domaine informatique 2 relevant du périmètre d’action du service de protection SPk;
- un module d’émulation 4D, activé sur requête du dispositif client 3, et configuré pour émuler une attaque informatique sur au moins une ressource du domaine informatique 2 protégée par le service de protection SPk, ainsi qu’un module de transmission 4E configuré pour transmettre au dispositif client 3 un plan de mitigation de l’attaque proposé par le service de protection SPk lors de l’émulation de l’attaque par le module d’émulation 4D.

Les différentes fonctions mises en œuvre par les modules 4A à 4E de chaque dispositif serveur 4-k, k=1… N sont détaillées davantage ultérieurement. On note que par souci de simplification, les modules 4A à 4E des dispositifs serveurs 4-k, k=1… N ne sont représentés sur la figure 2 que pour le dispositif serveur 4-1.

Nous allons maintenant décrire, en référence auxfigures 5 et 6, les principales étapes mises en œuvre respectivement par le dispositif client 3 et par les dispositifs serveur 4-k, k=1… N pour améliorer la gestion des attaques informatiques ciblant des ressources du domaine informatique 2 conformément à l’invention. La figure 5 illustre ainsi les étapes d’un procédé d’assistance selon l’invention, telles que mises en œuvre par le dispositif client 3 dans un mode particulier de réalisation. La figure 6 illustre ainsi les étapes d’un procédé d’obtention selon l’invention telles que mises en œuvre par un dispositif serveur 4-k0 d’un service de protection SPk0 parmi les services de protection SP1, …, SPN protégeant les ressources du domaine informatique 2, ainsi que les étapes mises en œuvre par les autres dispositifs serveurs 4-k, k=1,…N, k≠k0 dans ce mode particulier de réalisation.

En référence à la figure 5, on suppose ici qu’une attaque informatique ATTACK a été détectée sur au moins une ressource du domaine informatique 2 par la fonction de détection 10 d’attaques informatiques, de façon connue en soi. Cette attaque est signalée par la fonction de détection 10 au dispositif client 3 (étape E10). Lors de ce signalement, la fonction de détection 10 fournit diverses informations sur l’attaque ATTACK au dispositif client 3, comme par exemple les caractéristiques du trafic de l’attaque (adresse(s) source, adresse(s) destination, identifiant(s) de protocoles (par exemple ICMP (pour Internet Control Message Protocol), TCP (pour Transmission Control Protocol), etc.), la nature de l’attaque (ici attaque DDoS), etc. Ces informations peuvent être complétées par des informations de volumétrie du trafic d’attaque, obtenues par exemple par la fonction 10 via la collecte de compteurs SNMP (pour Simple Network Management Protocol) sur les interfaces incriminées.

Sur réception de ce signalement, le dispositif client 3 envoie une requête DOTS à tout ou partie des dispositifs 4-1, …, 4-N pour signaler l’attaque informatique ATTACK détectée et leur demander de l’aide pour résoudre cette attaque (étape E20). La requête DOTS envoyée est par exemple une requête DOTS «Request Mitigation» connue de l’état de la technique, similaire ou identique à la requête donnée à titre illustratif dans la table 1. Elle est envoyée par le dispositif client 3 à tous les dispositifs serveurs 4-1, …, 4-N ou seulement aux dispositifs serveurs parmi les dispositifs serveurs 4-1, …, 4-N protégeant les ressources ciblées par l’attaque ou impliquées dans l’acheminement du trafic de l’attaque vers le domaine informatique 2. Cet envoi peut être effectué en parallèle vers chacun des dispositifs serveurs ou séquentiellement.

A titre uniquement illustratif, on suppose ici que l’attaque ATTACK relève du périmètre d’action des services de protection SP1 et SP2, et plus particulièrement cible des ressources protégées par les services de protection SP1 et SP2, et que la requête DOTS est envoyée par le dispositif client 3 aux dispositifs serveurs 4-1 et 4-2 seulement.

En référence à lafigure 6, le ou les dispositif(s) serveur(s) contacté(s) (étape F10) par le dispositif client 3, et qui est (sont) en mesure de traiter cette attaque (réponse «oui» à l’étape test F20), acquitte(nt) la requête de mitigation de l’attaque reçue du dispositif client 3 en lui envoyant un message DOTS «2.01 Created» (étape F30). Par «en mesure de traiter cette attaque» ou «capable de traiter cette attaque», on entend ici que le dispositif serveur a la capacité fonctionnelle (c’est-à-dire il connait l’attaque, sait comment l’identifier et la mitiger) et dispose des ressources matérielles et/ou logicielles (en quantité appropriée) pour la traiter et la mitiger.

Chaque dispositif serveur d’un service de protection capable de traiter l’attaque met en outre en place un plan de mitigation pour traiter le trafic destiné au domaine informatique 2 dont il a la visibilité (autrement dit destiné ou passant par les ressources du domaine informatique 2 dont il assure la protection) (étape F40). Il informe le dispositif client 3 qu’il a mis en place avec succès un plan de mitigation contre l’attaque.

Dans l’exemple illustratif introduit précédemment, on suppose ici que le service de protection SP1 est en mesure de traiter l’attaque, met en place avec succès un plan de mitigation contre cette attaque et en informe le dispositif client 3.

Si en revanche, l’un des services de protection contacté n’est pas en mesure de traiter cette attaque (réponse «non» à l’étape test F20), il en informe le dispositif client 3 en lui envoyant par exemple un message d’erreur tel qu’un message DOTS «5.03 (Service Unavailable)» (étape F70).

Dans l’exemple illustratif introduit précédemment, on suppose ici que le service de protection SP2 n’est pas en mesure de traiter l’attaque, et en informe le dispositif client 3.

En référence à la figure 5, le dispositif client 3 demande au(x) service(s) de protection ayant mis en place un plan de mitigation contre l’attaque (branche «SPk/ATTACK OK») de lui fournir ce(s) plan de mitigation (étape E30). A cet effet, il envoie par exemple, à chaque dispositif serveur concerné, une requête DOTS GET contenant un attribut («Uri-Path») nouvellement introduit pour les besoins de l’invention et appelé ici «mplan». Un exemple d’une telle requête est fourni à titre illustratif dans la table 3 ci-dessous.

La requête peut comprendre un identifiant de mitigation de l’attaque, «mid» (pour «Mitigation IDentifier»), supposé égal ici pour l’attaque ATTACK à «12332». Si cet identifiant n’est pas renseigné dans la requête alors, dans le mode de réalisation décrit ici, le dispositif serveur doit communiquer tous les plans de mitigation de l’ensemble des actions de mitigation en cours d’exécution par le service de protection associé.

Sur réception de cette requête (étape F50), le dispositif serveur fournit au dispositif client 3, via son module de fourniture 4B, les caractéristiques techniques du plan de mitigation mis en place contre l’attaque ATTACK (ou de l’ensemble des plans de mitigation en cours d’exécution si aucun identifiant de mitigation d’attaque n’est précisé dans la requête GET) (étape F60). Le plan de mitigation est fourni sous la forme d’une liste (qui peut être ordonnée) comprenant une ou plusieurs règles, chaque règle définissant (c’est-à-dire caractérisant) le trafic que l’on souhaite traiter (par exemple le trafic identifié comme suspect), et la ou les actions devant être appliquées au trafic caractérisé par la règle. De telles actions sont par exemple, un rejet du trafic défini par la règle associée à l’action, une redirection du trafic, une limitation du débit du trafic, etc.

Un exemple de réponse fournie par le dispositif serveur est illustré à la table 4.

Selon cet exemple, le plan de mitigation est fourni dans l’attribut “mplan”, dans le corps de la réponse. L’attribut «mplan» peut être structuré selon un formalisme similaire ou identique à celui des listes ACL (Access Control Lists) définies dans la spécification du protocole DOTS, ou selon une chronologie ECA (Event, Condition, Action), etc.. A titre illustratif, un exemple de plan de mitigation est donné ci-après dans la table 5.

Le plan décrit dans la table 5 contient une entrée ACE (pour «Access Control Entry»), c’est-à-dire une action de filtrage dont le nom est «rule1»: cette action consiste à rejeter (comme l’indique la clause «forwarding» positionnée à «drop» pour rejeter sans notification à la source) tout le trafic défini par l’attribut «matches», à savoir ici le trafic émis depuis n’importe quelle adresse du réseau associé au préfixe "192.0.2.0/24" et à destination des ressources associées au préfixe "1.2.3.0/24".

On note qu’un plan de mitigation peut en variante inclure plusieurs entrées ACE; en effet, des actions distinctes telles que la redirection, la réduction de débit, etc. peuvent être exécutées par un même service de mitigation en réponse à une attaque.

Dans la suite de la description, un plan de mitigation est identifié selon le formalisme suivant,lorsqu’il contient une ou plusieurs règles : mplan=LIST_RULES(match, action, …), LIST_RULES désignant une liste de règles, chaque règle étant définie par une ou plusieurs conditions («match») permettant d’identifier le trafic concerné par la règle, et une ou plusieurs actions («action») préconisées par la règle pour le trafic ainsi identifié. On note qu’au sens de l’invention, un plan de mitigation peut également ou en variante, comprendre une ou plusieurs informations permettant de mettre en œuvre une assistance fournie par un service de protection pour le traitement d’une attaque.

Le dispositif client 3 mémorise localement, par exemple dans sa mémoire non volatile 8, tous les plans de mitigation reçus des services de protection compétents pour traiter l’attaque ATTACK en association avec les dispositifs serveurs et/ou les services de protection lui ayant fourni ces plans (étape E40). Dans la suite de la description, on désigne par mplan(SPk,mid#j) le plan de mitigation mis en place par le service de protection SPk (et son dispositif serveur 4-k) en réponse à l’attaque identifiée par l’identifiant de mitigation d’attaque mid#j, j désignant un entier supérieur à 1. On note que des identifiants de mitigation distincts peuvent être utilisés pour une même attaque pour faciliter la gestion des plans de mitigation pendant ou après leur exécution.

Ainsi, dans l’exemple illustratif envisagé ici où le service de protection SP1 a mis un plan de mitigation en place pour traiter l’attaque ATTACK, le dispositif client 3 reçoit ce plan de mitigation du dispositif serveur 4-1 et le mémorise sous la forme mplan(SP1,mid=12332) dans sa mémoire non volatile, 12332 désignant l’identifiant de mitigation de l’attaque ATTACK.

On note que dans le mode de réalisation décrit ici, les plans de mitigation mis en place le cas échéant par les services de protection SPk, k=1,…, N sont obtenus par le dispositif client 3 suite à la détection de l’attaque ATTACK. En variante, on peut envisager que le dispositif client 3 sollicite les services de protection SPk, k=1,…, N de façon décorrélée par rapport à la détection d’une attaque ATTACK, ou suite à la détection d’une anomalie dans le domaine informatique 2 (par exemple une boucle de routage entre les domaines transitaires, la perte de trafic entrant/sortant du domaine informatique 2, la dégradation des services accessibles au domaine), etc.

Dans une autre variante encore, on peut envisager que le dispositif client 3 souscrive auprès des services de protection SPk, k=1,…,N à un service de notification des différentes actions de mitigation mises en œuvre par ces derniers pour protéger les ressources du domaine informatique 2, et/ou de la mise à jour ou de l’évolution de ces actions (cessation de l’action, mise en place d’action(s) de mitigation additionnelle(s), etc.).

Dans l’exemple illustratif envisagé ici, comme mentionné précédemment, on suppose que le service de protection SP2 est incapable de traiter l’attaque ATTACK relevant de son périmètre d’action (branche «SPk/ATTACK NOK»). Le dispositif serveur 4-2 du service de protection SP2 notifie le dispositif client 3 de cette incapacité lors de l’étape F750 décrite précédemment en lui transmettant un message d’erreur en réponse à sa requête de mitigation «5.03 (Service Unavailable)». Dans le mode de réalisation décrit ici, le message d’erreur «5.03 (Service Unavailable)» comprend avantageusement, dans un paramètre «status» introduit dans la spécification du protocole DOTS pour les besoins de l’invention, la cause de l’erreur.

Dans le mode de réalisation décrit ici, on suppose qu’un service de protection SPk0 donné peut s’avérer incapable de traiter une attaque informatique dont il est notifié par le dispositif client 3 et de mettre en place un plan de mitigation de cette attaque pour deux raisons:
- l’attaque ATTACK est méconnue du service de protection SPk0, autrement dit, il ne dispose pas de moyens d’identifier le trafic de l’attaque et/ou ne sait pas comment traiter cette attaque. Le service de protection SPk0 n’est donc pas capable de mettre en œuvre un plan de mitigation adapté en réponse à l’attaque détectée. Cette raison est codifiée dans le message d’erreur par un paramètre «status» valorisé par exemple à «unknown-attack»; ou
- le service de protection SPk0 connaît l’attaque mais souffre d’une insuffisance de ressources disponibles pour mitiger l’attaque (problème capacitaire, par manque de ressources adéquates et/ou de ressources en quantité suffisante pour mitiger l’attaque, par exemple si celle-ci est de grande ampleur). Cette raison est alors codifiée dans le message d’erreur par un paramètre «status» ayant par exemple la valeur «attack-exceeded-capacity».

Aucune limitation n’est attachée toutefois au nombre de raisons ni aux raisons pour lesquelles un service de protection peut s’avérer incapable de traiter une attaque.

Le dispositif client 3 peut de cette sorte détecter, au moyen de son module 3A de détermination, non seulement l’incapacité du service de protection SP2 à traiter l’attaque ATTACK, mais également déterminer la cause de cette incapacité en examinant la valeur du paramètre «status» inclus dans le message d’erreur reçu du dispositif serveur 4-2 (étape E50).

L’envoi de la requête de mitigation au dispositif serveur 4-2 et la réception du message d’erreur en réponse à cette requête constituent ainsi conjointement une étape de détermination de l’incapacité du service de protection SP2 à traiter l’attaque ATTACK par le dispositif client 3 au sens de l’invention.

Dans une variante de réalisation, le dispositif client 3 peut détecter cette incapacité autrement que par une information reçue directement du dispositif serveur 4-2. Par exemple, le dispositif client 3 peut détecter (directement ou indirectement par le biais d’une information reçue d’une autre entité du domaine informatique 2 ou par une entité externe) que le domaine informatique 2 reçoit toujours le trafic de l’attaque depuis des ressources protégées par le service de protection SP2 alors qu’une demande de mitigation explicite a été émise par le dispositif client 3 vers ce dernier, etc.

Si selon le paramètre «status» du message d’erreur, l’incapacité du service de protection SP2 provient d’une méconnaissance de l’attaque ATTACK (branche (I) sur la figure 5), et par ailleurs, au moins un autre service de protection concerné par l’attaque a mis en place un plan de mitigation efficace en réponse à cette attaque (réponse «oui» à l’étape test E60), le dispositif client 3 sélectionne dans sa mémoire non volatile 8 l’un de ces plans de mitigation (étape E70). Dans l’exemple illustratif envisagé ici, le service de protection SP1 a mis en place un tel plan de mitigation (plan de mitigation mplan(SP1,mid=12332)) et l’a communiqué lors de l’étape F60 au dispositif client 3.

On note que dans le mode de réalisation décrit ici, le dispositif client 3 a sollicité les services de protection au moyen de la requête GET pour obtenir leurs plans de mitigation dès la détection de l’attaque. En variante, il peut envoyer la requête GET sur détection de l’incapacité du service de protection SP1 à mettre en place un plan de mitigation (cela peut permettre d’avoir une version plus à jour du plan de mitigation si l’attaque a évolué par exemple), ou suite à la détection de l’attaque et suite à la détection de l’incapacité du service de protection SP1, ou encore de manière périodique, etc. Aucune limitation n’est attachée au nombre de fois ni aux moments où le dispositif client 3 peut solliciter les services de protection pour connaître les plans de mitigation qu’ils exécutent.

Puis, le dispositif client 3 élabore, au moyen de son module d’élaboration 3B, à partir du plan de mitigation sélectionné (mplan(SP1,mid=12332) ici), un plan de mitigation adapté aux ressources protégées par le service de protection incapable de traiter l’attaque aussi désigné par «service de protection incapable» dans la suite de la description par souci de simplification (SP2 dans l’exemple illustratif considéré) (étape E80).

Si les ressources du domaine informatique 2 protégées par le service de protection incapable sont également protégées par le service de protection (SP1 dans l’exemple) ayant fourni le plan de mitigation sélectionné, le plan élaboré par le dispositif client 3 peut alors consister en la reprise à l’identique du plan de mitigation sélectionné mplan(SP1,mid=12332), ou en la reprise uniquement des règles et des actions correspondant aux ressources protégées par le service de protection incapable SP2 (dans l’hypothèse par exemple où le service de protection SP1 protège d’autres ressources en plus de celles protégées par le service de protection incapable SP2).

Si les ressources du domaine informatique 2 protégées par le service de protection incapable SP2 diffèrent au moins en partie des ressources du domaine informatique 2 protégées par le service de protection SP1 ayant fourni le plan de mitigation sélectionné, alors le dispositif client 3 adapte le plan de mitigation fourni par le service de protection SP1 pour qu’il s’applique aux ressources protégées par le service de protection SP2. Cette adaptation peut consister notamment à adapter les règles définissant les caractéristiques du trafic traité. Par exemple, si le plan de mitigation mplan(SP1,mid=12332) contient des adresses IP uniquement protégées par le service de protection SP1 (par exemple identifiant des ressources d’interconnexion avec le réseau auquel appartient le service de protection SP1 alors que le service de protection SP2 protège des ressources d’interconnexion avec un autre réseau), le dispositif client 3 remplace ces adresses par celles protégées par le service de protection SP2.

Les tables 6 et 7 illustrent un exemple d’adaptation pouvant être réalisé par le dispositif client 3 pour élaborer à partir du plan de mitigation mplan(SP1,mid=12332) un plan de mitigation destiné au service de protection SP2.

La table 6 ci-dessous propose à titre illustratif un exemple de plan de mitigation mplan(SP1,mid=12332)mis en place et fourni par le service de protection SP1.

La table 7 montre en caractères gras l’adaptation réalisée par le dispositif client 3 pour élaborer un plan de mitigation adapté au service de protection SP2 (changement de l’identification des ressources ciblées par l’attaque).

D’autres types de modifications peuvent être envisagés pour être en cohérence avec le contexte d’une mitigation, comme par exemple la modification d’un filtre IPv4 en un filtre IPv6, la modification d’un filtre portant sur des numéros de port et non une plage d’adresses, la création de filtres pour chacune des adresses si les adresses protégées par le service de protection incapable ne peuvent pas être agrégées, le remplacement de certaines actions, etc.

Dans la suite de la description on désigne par g(mplan(SP1)) le plan élaboré par le dispositif client 3 à partir du plan mplan(SP1,mid=12332).

On note que si plusieurs services de protection ont fourni au dispositif client 3 des plans de mitigation de l’attaque ATTACK, le dispositif client 3 peut sélectionner l’un quelconque de ces plans (de manière aléatoire, ou le premier fourni, ou encore celui correspondant à un service de protection particulier (par exemple le plus attractif en termes de coût), etc.), agréger les différent plans reçus, ou en variante tenir compte d’un critère de sélection prédéterminé, comme par exemple le plan de mitigation qui requiert le moins d’adaptation pour pouvoir convenir au service de protection incapable.

Une fois le plan g(mplan(SP1)) élaboré, le dispositif client 3 le transmet par l’intermédiaire de son module de transmission 3C et de ses moyens de communication 9 au service de protection SP2 incapable et plus particulièrement au dispositif serveur 4-2 appartenant au service de protection SP2 (étape E90). Il peut à cet effet envoyer à destination du dispositif serveur 4-2 une requête de mitigation DOTS «Request Mitigation» telle que décrite précédemment comprenant le plan de mitigation g(mplan(SP1)).

Si selon le paramètre «status» du message d’erreur, l’incapacité du service de protection SP2 provient d’une méconnaissance de l’attaque ATTACK (branche (I) sur la figure 5), mais l’attaque relève uniquement du le périmètre d’action du service de protection incapable SP2 (autrement dit les ressources ciblées par l’attaque ATTACK ou impliquées dans l’acheminement du trafic de l’attaque ATTACK sont protégées par un unique service de protection parmi la pluralité de services de protection SP1, …, SPN protégeant les ressources du domaine informatique 2, à savoir SP2) (réponse «non» à l’étape E60), alors cela signifie qu’aucun des services de protection sollicité parmi la pluralité de services de protection lors de l’étape E30 n’a mis en place un plan de mitigation efficace contre l’attaque ATTACK eta fortiorin’a fourni un tel plan de mitigation au dispositif client 3 lors de l’étape E40. En d’autres termes, le dispositif client 3 ne dispose dans sa mémoire non volatile 9 d’aucun plan de mitigation déjà «connu» contre l’attaque ATTACK.

Dans le mode de réalisation décrit ici, dans ce cas, le dispositif client 3 envoie à au moins l’un des services de protection SPk, k≠2, protégeant des ressources du domaine informatique 2, et plus particulièrement au dispositif serveur 4-k de ce service de protection, une requête d’émulation de l’attaque ATTACK sur les ressources protégées par ce service de protection et d’obtention d’un plan de mitigation mis en place dans le cadre de cette émulation par le service de protection en réponse à l’attaque ATTACK (étape E100).

A cet effet, il peut par exemple utiliser une requête DOTS de mitigation «Request Mitigation» telle que décrite précédemment dans laquelle le dispositif client 3 insère un attribut, nouvellement défini pour les besoins de l’invention (nommé par exemple «emulate»), requérant une émulation de l’attaque ATTACK, et l’attribut mplan requérant le plan de mitigation proposé le cas échéant par le service de protection lors de l’émulation. Ces attributs ont pour objectif de déterminer si l’un au moins des services de protection SPk, k=1,.., N avec k≠2 (ou plus généralement k différent des indices des services de protection pour lesquels une incapacité à traiter l’attaque a été détectée par le dispositif client 3) est en mesure de traiter l’attaque. On note que l’attribut «emulate» peut être utilisé à d’autres fins, par exemple à des fins de simulation de crise dans le domaine informatique 2, non détaillées davantage ici.

Comme mentionné ci-avant, l’émulation de l’attaque est réalisée sur les ressources du domaine informatique 2 protégées par le service de protection exécutant l’émulation. La requête de mitigation adressée par le dispositif client 3 au dispositif serveur du service de protection doit donc être adaptée pour être compatible avec le périmètre du service de protection auquel elle est adressée. Autrement dit, les adresses cibles de l’attaque mentionnées dans la requête doivent être celles de ressources protégées par le service de protection et validées avec ce dernier. Un tel mécanisme de validation d’adresses est connu dans le cadre du protocole DOTS et n’est pas décrit en détail ici.

Dans l’exemple illustratif envisagé ici, on suppose que le dispositif client 3 envoie une telle requête d’émulation au service de protection SP1. Lafigure 7illustre les principales étapes mises en œuvre par le service de protection SP1 sur réception de cette requête, et plus particulièrement ici par le module d’émulation 4D de son dispositif serveur 4-1.

Sur réception de la requête d’émulation (étape G10), le dispositif serveur 4-1 déclenche l’émulation de l’attaque ATTACK sur les ressources qu’il protège (étape G20). Une telle émulation consiste à reproduire l’attaque ATTACK subie par le domaine informatique 2 selon les caractéristiques fournies par le dispositif client 3 dans la requête d’émulation, et en particulier à générer un trafic d’attaque semblable. Le dispositif serveur peut à cet effet s’appuyer sur une bibliothèque de trafics d’attaques collectés au fil du temps.

Lors de cette émulation, si le service de protection SP1 est capable de traiter l’attaque ainsi émulée (réponse «oui» à l’étape test G30), le dispositif serveur 4-1 dérive à partir de cette simulation des actions de mitigation appropriées en réponse à cette attaque.

On note que le plan de mitigation, noté ici mplan_emul(SP1), proposé lors de l’émulation par le dispositif serveur 4-1 n’est pas mis en place (c’est-à-dire activé) par ce dernier: du fait de la présence de l’attribut «emulate» dans la requête, celle-ci n’est prise en compte par le dispositif serveur 4-1 qu’à des fins de simulation de l’attaque sur les ressources qu’il protège.

Le plan de mitigation mplan_emul(SP1) élaboré le cas échéant lors de l’émulation est ensuite fourni au dispositif client 3 en réponse à sa requête d’émulation (étape G40).

Si le service de protection SP1 n’est pas capable de traiter l’attaque telle qu’émulée par le dispositif serveur 4-1 (réponse «non» à l’étape test G30), le dispositif serveur 4-1 en informe le dispositif client 3 en envoyant en réponse à sa requête d’émulation un message d’erreur tel que décrit précédemment (étape G50).

En référence à la figure 5, le dispositif client 3 examine la ou les réponse(s) reçue(s) à sa requête d’émulation (selon qu’un ou plusieurs services de protection ont été contactés pour émuler l’attaque) (étape test E110), autrement dit dans l’exemple illustratif envisagé ici, la réponse du service de protection SP1.

Si au moins un plan de mitigation mplan_emul(SPi) issu de l’émulation de l’attaque a été fourni au dispositif client 3 par un service de protection autre que le service de protection incapable (réponse «oui» à l’étape test E110), le dispositif client 3 élabore alors à partir de ce plan de mitigation (ou de l’un des plans de mitigation reçus et sélectionné par exemple de façon arbitraire ou en fonction de la richesse des informations contenues dans les plans de mitigation reçus), un plan de mitigation destiné au service de protection incapable, SP2 dans l’exemple envisagé. Dans l’exemple envisagé ici, on suppose que le dispositif client 3 élabore à partir du plan mplan_emul(SP1) un plan g(mplan_emul(SP1)): il procède à cet effet de façon identique à ce qui a été décrit précédemment pour l’étape E80. Le plan ainsi élaboré g(mplan_emul(SP1)) est ensuite transmis au dispositif serveur 4-2 du service de protection SP2 (étape E90).

Sinon (réponse «non» à l’étape test E110), il contacte un autre service de protection parmi la pluralité de services de protection protégeant les ressources du domaine informatique 2 pour émuler l’attaque si un tel autre service de protection existe et réitère les étapes E100 et E110 avec cet autre service de protection qui met alors en œuvre les étapes précédemment décrites de la figure 7.

On note qu’en cas d'échec des différentes requêtes d’émulation, le dispositif client 3 peut réitérer ses requêtes en fournissant plus de détails sur l’attaque ou en envoyant des captures du trafic de l’attaque aux services de protection.

En référence à la figure 6, sur réception du plan de mitigation élaboré par le dispositif client 3 (à partir du plan de mitigation mis en place par le service de protection SP1 ou d’un plan de mitigation émulé par ce dernier), via son module de réception 4A et ses moyens de communication 15 (étape F80), le dispositif serveur 4-2, par l’intermédiaire de son module de mise en place 4B,met alors en place, en réponse à l’attaque ATTACK, un plan de mitigation de cette attaque dérivé du plan de mitigation g(mplan(SP1)) ou g(mplan_emul(SP1)) reçu du dispositif client 3 (étape F90). Par «dérivé», on entend ici que le plan de mitigation mis en place peut être identique au plan reçu du dispositif client 3, être élaboré par le dispositif serveur 4-2 à partir de tout ou partie des informations (règles et actions de mitigation notamment) contenues dans le plan de mitigation reçu du dispositif client 3, ou s’inspirer de la logique du plan reçu. L’invention ne se limite pas à une exécution telle quelle par le dispositif serveur 4-2 du plan de mitigation reçu du dispositif client 3, mais inclut également une version adaptée de celui-ci.

On note que si le plan de mitigation élaboré par le dispositif serveur 4-2 à partir du plan fourni par le dispositif client 3 n’est pas suffisant pour mettre fin à l’attaque ATTACK, le dispositif client 3 en est informé (soit par le dispositif serveur 4-2 directement, soit par un autre biais), et peut alors élaborer et communiquer au dispositif serveur 4-2 un autre plan de mitigation dérivé d’un plan de mitigation fourni par un autre service de protection que le service de protection SP1.

La branche (I) de la figure 5 qui vient d’être décrite fait référence à une incapacité fonctionnelle du service de protection SP2 pour traiter l’attaque ATTACK ciblant les ressources du domaine informatique 2 qu’il protège, et à l’assistance fournie par le dispositif client 3 au service de protection SP2 pour traiter l’attaque ATTACK dans le cas d’une telle incapacité fonctionnelle. Comme mentionné précédemment, l’incapacité du service de protection SP2 peut en variante provenir d’une insuffisance capacitaire, autrement dit, le service de protection SP2 ne dispose pas de ressources suffisantes pour mitiger l’attaque, par exemple parce que celle-ci est de grande ampleur.

Dans ce cas (branche II de la figure 5), le dispositif client 3, sur réception du message d’erreur transmis par le dispositif serveur 4-2, interroge au moins un autre service de protection parmi les services de protection SP1, …, SPk, …, SPN, k≠2, protégeant des ressources du domaine informatique 2, pour déterminer s’il est apte à fournir une assistance capacitaire au service de protection SP2 pour mitiger l’attaque ATTACK (étape E120). A cet effet, il envoie, dans le mode de réalisation décrit ici, à au moins l’un des services de protection SP1, …, SPk, …, SPN, k≠2, une requête d’assistance DOTS. Dans l’exemple illustratif envisagé ici, on suppose que cette requête d’assistance est envoyée au service de protection SP1 et plus particulièrement à son dispositif serveur 4-1. On note qu’une telle requête n’existe pas dans la version actuelle du protocole DOTS et nécessite d’être définie pour les besoins de l’invention. Une telle requête est par exemple nommée «Request Assisted Mitigation».

Dans le mode de réalisation décrit ici, le corps de la requête d’assistance «Request Assisted Mitigation» comprend notamment les attributs suivants:
- un attribut nommé ici «type» permettant au dispositif client 3 de préciser l’urgence de l’assistance requise, à savoir si l’assistance requise doit être fournie immédiatement ou de manière différée; et
- un attribut nommé ici «required_capacity» permettant au dispositif client 3 de préciser les ressources capacitaires minimales requises pour fournir une assistance au service de protection incapable SP2(notamment la quantité et la nature des ressources requises).

Cette liste d’attributs n’est aucunement exhaustive ni limitative en soi. D’autres attributs peuvent être envisagés en variante ou en complément des attributs précités.

Sur réception d’une telle requête d’assistance par le dispositif serveur 4-1, celui-ci vérifie si le service de protection SP1 a la capacité nécessaire pour la mise en place de l’assistance requise. Si tel est le cas et si le service de protection SP1 accepte de fournir cette assistance, le dispositif serveur 4-1 répond au dispositif client 3 avec un message de réponse DOTS «2.01 Created», dans lequel il inclut des informations pour la mise en place de l’assistance que propose de fournir le service de protection SP1. En particulier, dans le mode de réalisation décrit ici, un attribut nommé par exemple «Scrubbing_Endpoint(s)» est inclus dans le corps du message de réponse et contient l’adresse ou les adresses IP (ou le ou les noms de domaines) de la ou des entités avec lesquelles le dispositif serveur 4-2 peut établir une communication pour bénéficier de l’assistance fournie par le service de protection SP2 pour résoudre l’attaque ATTACK. Une telle entité est par exemple un centre de nettoyage (plus communément appelé «scrubbing center») du service de protection SP1 en charge du filtrage de tout ou partie du trafic suspect qui lui parvient.

D’autres informations peuvent être incluses dans la réponse, comme par exemple une capacité disponible au niveau du service de protection fournissant son assistance,
une ou plusieurs clés de sécurité destinées à être utilisées lors de cette assistance (par exemple dans le cadre d’un tunnel de communication sécurisé établi entre le service de protection incapable et le service de protection fournissant son assistance), une durée de vie de l’assistance fournie par le service de protection, etc.

Sur réception des informations fournies par le ou les services de protection se déclarant aptes à fournir une assistance au service de protection SP2 incapable de traiter l’attaque, le dispositif client 3 les mémorise dans sa mémoire non volatile 9 (étape E130). On note qu’en fonction de la durée de vie associée le cas échéant à l’assistance proposée par les services de protection, ces informations ont vocation à être utilisées pour traiter l’attaque ATTACK et prêter assistance au service de protection SP2 incapable de traiter l’attaque ATTACK, mais également si besoin ultérieurement pour ce même service de protection ou un autre.

Puis il élabore, par le biais de son module 3B d’élaboration, un plan de mitigation destiné au service de protection SP2 utilisant l’assistance d’un ou de plusieurs services de protection s’étant déclarés aptes à fournir une telle assistance (étape E140).

Dans l’exemple illustratif considéré ici, il élabore par exemple un plan de mitigation s’appuyant sur l’assistance proposée par le service de protection SP1. Plus particulièrement, ce plan de mitigation comprend les informations fournies par le service de protection SP1 pour établir une communication entre le service de protection SP2 et le service de protection SP1 afin de lui permettre de bénéficier de l’assistance du service de protection SP1 pour la mitigation de l’attaque ATTACK. Si plusieurs services de protection ont répondu favorablement pour fournir une assistance au service de protection SP2, le plan de mitigation peut comprendre les informations indiquées au dispositif client 3 par tout ou partie de ces services de protection aptes à fournir leur assistance.

Dans le mode de réalisation décrit ici, le plan de mitigation comprenant les informations permettant au service de protection SP2 de bénéficier de l’assistance d’un ou de plusieurs autres services de protection pour mitiger l’attaque est transmis par le dispositif client 3 au dispositif serveur 4-1 du service de protection SP1 dans une requête de mitigation DOTS «Request Mitigation» comprenant notamment comme attributs l’identifiant de mitigation de l’attaque «mid» et un attribut nommé «assist-on» comprenant les informations fournies par le ou les services de protection ayant proposé leur assistance pour établir une communication avec lui ou eux (SP1 ici) (étape E150).

En référence à la figure 6, sur réception de ce plan de mitigation (étape F80), le dispositif serveur 4-2, par l’intermédiaire de son module de mise en place 4B,met alors en place, en réponse à l’attaque ATTACK ciblant les ressources du domaine informatique 2 qu’il protège, un plan de mitigation de cette attaque dérivé du plan de mitigation reçu du dispositif client 3 (étape F90). Ce plan de mitigation consiste notamment à établir une communication pouvant être sécurisée (par exemple un tunnel sécurisé) avec la ou les entités du service de protection SP1 identifiées dans les informations fournies dans le plan de mitigation («scrubbing center» du service de protection SP1) et à rediriger via la communication ainsi établie, tout ou partie du trafic suspect (i.e., des données suspectées d’être associées à l’attaque) vers le scrubbing center du service de protection SP1 pour traitement ou filtrage. Des mécanismes connus de l’état de la technique peuvent être utilisés à cet effet pour établir une telle communication comme par exemple la suite de protocoles IPsec.

Le trafic suspect redirigé et acheminé vers le service de protection SP1 est alors traité par ce dernier. Le trafic considéré comme légitime peut être retourné vers le service de protection SP2 ou être acheminé directement vers le domaine informatique 2 par le service de protection SP1.

Dans le mode de réalisation décrit ici, le dispositif client 3 sollicite les services de protection SP1, …, SPN distincts du service de protection SP2 suite à la détection de l’attaque ATTACK et dès lors qu’il a été informé de l’incapacité du service de protection SP2 à traiter celle-ci. En variante, afin d’anticiper les problèmes liés à une défaillance capacitaire de l’un des services de protection (par exemple pour pouvoir absorber le trafic d’une attaque dont le volume dépasse un certain seuil), le dispositif client 3 peut préconfigurer l’assistance susceptible d’être fournie par les services de protection SP1,…,SPN. A cet effet, il peut envoyer, indépendamment de la détection d’une attaque informatique contre des ressources du domaine informatique 2, une requête d’assistance «Request Assisted Mitigation» à tout ou partie des services de protection SP1, …, SPN (plus particulièrement à leurs dispositifs serveurs 4-1, ..., 4-N) dans laquelle l’attribut «type» est positionné par exemple à la valeur «preconfigured». Le dispositif client 3 peut éventuellement inclure également dans la requête une estimation de la capacité nécessaire pour l’assistance requise. Une telle estimation peut être réalisée au moyen d’une heuristique reposant sur l’analyse de compteurs SNMP (Simple Network Management Protocol) ou NETCONF permettant d’estimer la volumétrie des paquets de données échangés sur un réseau. L’envoi de cette requête aux services de protection peut se faire de manière simultanée ou séquentielle.

Sur réception de cette requête par un dispositif serveur d’un service de protection concerné, ce dernier vérifie s’il dispose de la capacité nécessaire pour la mise en place d’une telle assistance, comme décrit ci-avant. Si la demande d’assistance est acceptée par le service de protection, le dispositif serveur répond avec un message «2.01 Created», incluant dans le corps de la réponse les informations décrites précédemment permettant d’établir une communication avec le service de protection. Une durée de vie de l’assistance proposée peut également être incluse dans le message de réponse. La réception et la mémorisation de ces informations par le dispositif client 3 dans sa mémoire non volatile 9 achève la pré-configuration de l’assistance.

Ainsi, en cas de détection d’une attaque ciblant les ressources du domaine informatique 2, le dispositif client 3 peut alors, dès l’envoi de la requête de mitigation «Request Mitigation» aux services de protection protégeant les ressources affectées par l’attaque, requérir l’intervention de ces services de protection tout en insérant dans la requête l’offre d’assistance préconfigurée offerte par les services de protection (autrement dit les informations transmises par ces derniers pour permettre d’établir une communication avec eux aux fins de la fourniture de cette assistance), dès lors que celle-ci a encore une durée de vie valide. Sur réception de cette requête, chaque service de mitigation procède à l’exécution d’un plan de mitigation en mettant en place des contre-mesures contre l’attaque. S’il n’est pas en mesure de traiter le trafic suspect pour des raisons capacitaires, il peut ainsi réacheminer une partie de l’excédent du trafic vers un ou plusieurs services de protection ayant offert son assistance. A cet effet, il établit une communication avec les entités idoines de ces services de protection («scrubbing centers») en utilisant les informations communiquées dans la requête de mitigation. Une fois cette communication établie, le service de protection défaillant peut rediriger l’excédent du trafic suspect qu’il ne peut pas gérer vers un service de protection lui prêtant assistance. Cet excédent est alors géré par le service de protection fournissant l’assistance, tandis que le trafic légitime peut être retourné vers le service de protection défaillant ou être acheminé directement vers le domaine informatique 2.

On note que si un service de protection n’est plus en mesure de fournir son assistance à un service de protection défaillant ou si le dispositif client 3 ne renouvelle pas la demande après expiration de la durée de vie de son offre d’assistance, alors le dispositif client 3 ne doit plus inclure cette offre dans la requête de mitigation.

L’invention permet donc de manière générale de fournir une assistance à un service de protection défaillant en s’appuyant sur les autres services de protection protégeant les ressources du domaine informatique 2, quelle que soit la raison de cette défaillance. On a évoqué dans les exemples illustratifs fournis une défaillance de type capacitaire ou une défaillance fonctionnelle, toutefois ces exemples ne sont pas limitatifs en soi et on peut envisager d’autres types de défaillances.

Par ailleurs, dans un mode particulier de réalisation, outre la fourniture de cette assistance, on peut envisager que le dispositif client 3 soit également en mesure, lorsque l’attaque relève du périmètre d’action de plusieurs services de protection parmi les services de protection SP1, …, SPN, de vérifier la compatibilité des plans de mitigation mis en place par chacun des services de protection concernés par l’attaque, et de coordonner le cas échéant la cohérence de ces plans de mitigation entre eux. Par exemple, à l’issue de l’étape E30, lorsque le dispositif client 3 a été informé de l’ensemble des plans de mitigation mis en place par les services de protection concernés par l’attaque, il peut vérifier si les plans de mitigation obtenus sont compatibles entre eux pour traiter l’attaque ATTACK.

Un exemple d’incompatibilité (autrement dit d’anomalie entre les plans de mitigation) est la création d’une boucle de routage par l’association de plans de mitigation non coordonnés mis en place par plusieurs services de protection. Pour illustrer une telle boucle de routage, prenons l’exemple de la figure 1 et du domaine client CL relié à deux réseaux transitaires TN1 et TN2 via respectivement les liens d’interconnexion R2 et R1. Sur détection d’une attaque, on suppose que le service DPS1 met en place un plan de mitigation redirigeant tout le trafic légitime vers le lien d’interconnexion R1, et que le service DPS2 met en place un plan de mitigation redirigeant tout le trafic légitime vers le lien d’interconnexion R2. Ce faisant, une boucle de routage est créée: le trafic légitime ne peut plus être acheminé vers le domaine client CL. Cette boucle de routage n’est toutefois pas détectable par les services de protection DPS1 et DPS2.

Au contraire, dans le contexte de l’invention où le dispositif client 3 dispose à l’issue de l’étape E40 des plans de mitigation mis en place par les différents services de protection en réponse à l’attaque ATTACK, le dispositif client 3 a la possibilité de détecter une telle boucle de routage, ou plus généralement une incompatibilité entre les plans de mitigation mis en place. On peut noter que le domaine client CL peut également détecter une telle anomalie en observant le trafic entrant/sortant du domaine informatique 2 (une boucle de routage telle que décrite ci-avant peut se manifester typiquement par une absence de trafic entrant dans le domaine informatique).

Sur détection d’une telle incompatibilité entre les plans de mitigation mis en place par au moins deux services de protection désignés par SPk1 et SPk2, le dispositif client 3 coordonne, dans un mode particulier de réalisation, un ajustement de tout ou partie des plans de mitigation incompatibles de sorte à éliminer l’incompatibilité. A cet effet, il peut procéder par exemple selon l’une ou l’autre des variantes de réalisation suivantes.

Selon une première variante de réalisation, le dispositif client 3 sélectionne au moins l’un des services de protection «en conflit» (par exemple SPk1) et notifie au dispositif serveur (4-k1) de ce dernier l’incompatibilité entre les plans de mitigation (par exemple l’existence d’une boucle de routage). Le service de protection notifié peut être sélectionné arbitrairement parmi les services de protection en conflit, ou on peut envisager de sélectionner par exemple celui qui présente le plan de mitigation le moins efficace. Pour notifier au dispositif serveur du service de protection sélectionné l’incompatibilité détectée, le dispositif client 3 peut lui envoyer une requête DOTS de mitigation avec un attribut, nouvellement introduit dans le protocole DOTS pour les besoins de l’invention, nommé ici «thirdparty-dps-conflict» visant à requérir un ajustement, autrement dit une mise à jour, du plan de mitigation proposé par le service de protection en question (SPk1 ici). Cette requête peut contenir en outre des éléments nécessaires pour identifier le conflit, comme par exemple tout ou partie des plans de mitigation présentant une incompatibilité avec celui du service de protection en question (typiquement les règles et les actions en conflit).

Sur réception de cette requête, le dispositif serveur 4-k1 modifie son plan de mitigation pour éviter l’incompatibilité et transmet son plan modifié du dispositif client 3. Le dispositif client 3 vérifie si l’incompatibilité est effectivement résolue et si aucune autre incompatibilité n’a été créée du fait de l’ajustement du plan du service de protection SPk1.

Selon une deuxième variante, le dispositif client 3 notifie tous les dispositifs serveurs des services de protection impliqués dans l’incompatibilité détectée pour leur demander d’ajuster leurs plans de mitigation. Dans l’exemple illustratif envisagé ci-dessus, il notifie ainsi les dispositifs serveurs 4-k1 et 4-k2. Il peut à cet effet utiliser une requête de mitigation avec un attribut «thirdparty-dps-conflict» telle que décrite ci-avant.

Sur réception de cette requête, chaque dispositif serveur procède à un ajustement de son plan de mitigation pour résoudre l’incompatibilité détectée et transmet son plan de mitigation ajusté au dispositif client 3. Le dispositif client 3 vérifie la compatibilité des plans de mitigation ajustés et en cas d’incompatibilité procède de nouveau selon la première variante ou la deuxième variante.

On note que le dispositif client 3 peut contacter à fréquence régulière les dispositifs serveurs 4-k, k=1,…,N pour vérifier si une modification a été apportée à leurs plans de mitigation, et le cas échéant, procéder à la vérification de la compatibilité des mises à jour avec les plans de mitigation existants. Alternativement, chaque dispositif serveur peut notifier le dispositif client 3 d’une mise à jour de son plan de mitigation.

L’invention offre ainsi une solution efficace permettant de valoriser l’utilisation d’une pluralité de services de protection pour protéger les ressources d’un domaine informatique client. Elle s’applique de façon avantageuse mais non limitative lorsque les services de protection sont gérés par des entités administratives distinctes. Cette invention s’appuie avantageusement sur la visibilité dont dispose le domaine informatique client pour coordonner les actions des services de protection.

Claims (18)

1. Procédé d’assistance mis en œuvre par un dispositif (3) gérant des ressources d’un domaine informatique (2), lesdites ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ledit procédé comprenant :

   • une étape de détermination (E20,E50) d’une incapacité d’un premier service de protection parmi ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique ;
   • une étape d’élaboration (E80,E140) d’un plan de mitigation de ladite attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection parmi ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et
   • une étape de transmission (E90,E150) du plan de mitigation élaboré au premier service de protection pour traiter ladite attaque.
2. Procédé selon la revendication 1 dans lequel:

   • le deuxième service de protection a mis en place un plan de mitigation en réponse à ladite attaque;
   • ladite incapacité du premier service de protection provient d’une méconnaissance de ladite attaque par le premier service de protection; et
   • le plan de mitigation transmis au premier service de protection est élaboré (E80) en adaptant ledit plan de mitigation mis en place par le deuxième service de protection aux ressources du domaine informatique protégées par le premier service de protection.
3. Procédé selon la revendication 1 dans lequel, lorsqueladite attaque relève d’un périmètre d’action du premier service de protectionuniquement et ladite incapacité du premier service de protection provient d’une méconnaissance de l’attaque par le premier service de protection, ledit procédé comprend en outre:

   • une étape d’envoi (E100) audit deuxième service de protection d’une requête d’émulation de ladite attaque sur au moins une ressourcedu domaine informatique protégée par le deuxième service de protection; et
   • une étape d’obtention (E110) d’un plan de mitigation proposé lors de l’émulation de l’attaque par le deuxième service de protection pour traiter cette attaque;

   le plan de mitigation transmis au premier dispositif étant élaboré à partir du plan de mitigation obtenu lors de l’étape d’obtention en l’adaptant aux ressources du domaine informatique protégées par le premier service de protection.
4. Procédé selon la revendication 1 dans lequel ladite incapacité du premier service de protection provient d’une insuffisance de ressources disponibles au niveau du premier service de protection pour mitiger ladite attaque, ledit procédé comprenant une étape d’obtention (E130) auprès dudit deuxième service de protection d’au moins une information permettant un établissement d’une communication entre ledit premier service de protection et le deuxième service de protection pour l’assister dans la mitigation de ladite attaque, le plan de mitigation transmis au premier service de protection comprenant ladite au moins une information obtenue.
5. Procédé selon l’une quelconque des revendications 1 à 4 comprenant:

   • une étape d’interrogation (E120) de tout ou partie de ladite pluralité de services de protection protégeant des ressources du domaine informatique pour déterminer lesdits services de protection aptes à fournir une assistance pour mitiger une attaque informatique à au moins un autre service de protection de ladite pluralité de services de protection; et
   • une étape de mémorisation (E130), pour chaque service de protection se déclarant apte à fournir une assistance, d’au moins une information fournie par ce service de protection permettant une mise en œuvre de cette assistance.
6. Procédé selon la revendication 5 dans lequel ladite au moins une information comprend au moins un élément parmi:

   • une capacité disponible au niveau dudit service de protection apte pour ladite assistance;
   • une information permettant l’établissement d’une communication avec ledit service de protection apteà fournir une assistance ;
   • au moins une clé de sécurité destinée à être utilisée lors de ladite assistance avec le service de protection apteà fournir une assistance ;
   • une durée de vie de l’assistance fournie par ledit service de protection apte à fournir une assistance.
7. Procédé selon la revendication 5 ou 6 dans lequel lors de l’étape d’interrogation, le dispositif indique auxdits services de protection interrogés une capacité minimale dont doit disposer un service de protection se déclarant apte à fournir ladite assistance.
8. Procédé selon l’une quelconque des revendications 5 à 7 dans lequel ladite étape d’interrogation est mise en œuvre suite à la détection d’une attaque ciblant au moins une ressource du domaine informatique.
9. Procédé selon l’une quelconque des revendications 1 à 8 comprenant, après détection de ladite attaque, une étape d’envoi (E30) à tout ou partie des services de protection de ladite pluralité de services de protection , d’une requête d’obtention d’un plan de mitigation mis en place par ces services de protection en réponse à ladite attaque.
10. Procédé selon l’une quelconque des revendications 1 à 9 comprenant, lorsque ladite attaque se trouve dans un périmètre d’action de plusieurs services de protection de ladite pluralité de services de protection:

    • une étape de vérification de la compatibilité des plans de mitigation mis en place en réponse à ladite attaque par lesdits plusieurs services de protection; et
    • si au moins une incompatibilité est détectée entre desdits plans de mitigation lors de l’étape de vérification, une étape de coordination d’un ajustement de tout ou partie desdits plans de mitigation incompatibles de sorte à éliminer ladite au moins une incompatibilité.
11. Procédé d’obtention, par un premier service de protection d’une pluralité de services de protection contre des attaques informatiques protégeant des ressources d’un domaine informatique, d’un plan de mitigation d’une attaque informatique ciblant au moins une ressource du domaine informatique, ledit procédé comprenant, suite à une détection d’une incapacité du premier service de protection à traiter ladite attaque:

    • une étape de réception (F80) d’un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique, à partir d’un plan de mitigation obtenu d’un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et
    • une étape de mise en place (F90), en réponse à ladite attaque, d’un plan de mitigation de l’attaque dérivé du plan de mitigation reçu du dispositif pour traiter ladite attaque.
12. Procédé selon la revendication 11 dans lequel l’étape de mise en place du plan de mitigation comprend, lorsque ledit plan de mitigation utilise une assistance fournie par au moins ledit deuxième service de protection, un acheminement de données suspectées d’être associées à ladite attaque vers ledit deuxième service de protection pour un traitement desdites données.
13. Procédé selon la revendication 12 dans lequel lesdites données sont acheminées vers ledit deuxième service de protection dans un tunnel sécurisé établi avec ledit deuxième service de protection au moyen d’au moins une information contenue dans ledit plan de mitigation reçu du dispositif.
14. Programme d’ordinateur (PROG3,PROG4) comportant des instructions pour l’exécution d’un procédé selon l’une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté par un ordinateur.
15. Support d’enregistrement lisible par un ordinateur sur lequel est enregistré un programme d’ordinateur selon la revendication 14.
16. Dispositif (3) gérant des ressources d’un domaine informatique, configuré pour communiquer avec une pluralité de services de protection contre des attaques informatiques protégeant lesdites ressources du domaine informatique, ledit dispositif comprenant :

    • un module de détermination (3A), configuré pour déterminer une incapacité d’un premier service de protection de ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique;
    • un module d’élaboration (3B), configuré pour élaborer un plan de mitigation de ladite attaque à partir d’un plan de mitigation obtenu d’un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et
    • un module de transmission (3C), configuré pour transmettre le plan de mitigation élaboré au premier service de protection pour traiter ladite attaque.
17. Dispositif (SPk) d’un premier service de protection d’une pluralité de services de protection contre des attaques informatiques protégeant des ressources d’un domaine informatique, au moins une dite ressource du domaine informatique étant ciblée par une attaque informatique, ledit dispositif comprenant des modules activés suite à une détection d’une incapacité dudit dispositif à traiter ladite attaque, lesdits modules comprenant:

    • un module de réception, configuré pour recevoir un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique à partir d’un plan de mitigation obtenu d’un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et
    • un module de mise en place, configuré pour mettre en place en réponse à ladite attaque un plan de mitigation dérivé du plan de mitigation reçu.
18. Système (1) de protection d’un domaine informatique comprenant:

    • une pluralité de services de protection contre des attaques informatiques protégeant des ressources du domaine informatique ;
    • un dispositif gérant lesdites ressources du domaine informatique, conforme à la revendication 16et configuré pour communiquer avec lesdits services de protection;

    ladite pluralité de services de protection comprenantau moins:

    • un premier service de protection comportant un dispositif selon la revendication 17 incapable de traiter une attaque informatique ciblant au moins une des ressources du domaine informatique ; et
    • un deuxième service de protection configuré pour fournir au dispositif gérant les ressources du domaine informatique un plan de mitigation de ladite attaque ou une assistance au premier service de protection pour traiter ladite attaque.