FR3120143A1 - Procédés de commande d’un dispositif de protection d’un élément d’un réseau, entité de commande et dispositif de protection - Google Patents

Abstract

Procédés de commande d’un dispositif de protection d’un élément d’un réseau, entité de commande et dispositif de protection Le procédé de commande selon l’invention est mis en œuvre par une entité (3) dite de commande d’un réseau (NW), configurée pour commander un dispositif (2) de protection d’au moins un élément du réseau. Ce procédé de commande comprend, suite à un signalement d’une anomalie détectée par ledit dispositif de protection lors d’une exécution d’une première action de protection : - une étape de détermination si une deuxième action de protection doit être exécutée par le dispositif de protection en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par le dispositif de protection lors de l’exécution de la première action de protection ; - si oui, une étape d’envoi au dispositif de protection d’un ordre d’exécution de la deuxième action de protection. Figure 1

Description

Procédés de commande d’un dispositif de protection d’un élément d’un réseau, entité de commande et dispositif de protection

L’invention se rapporte au domaine général des télécommunications et plus particulièrement à la sécurité des réseaux de communications et à la protection de ces derniers contre des attaques telles que des attaques informatiques aussi communément appelées cyber-attaques.

Elle a une application privilégiée mais non limitative dans le contexte des réseaux exploitant des technologies de virtualisation de fonctions réseau (ou NFV pour « Network Function Virtualization » en anglais), de réseau défini par logiciel (ou SDN pour « Software Defined Networking » en anglais) ou encore de découpage de réseaux en tranches, plus communément appelée « network slicing » en anglais.

Ces technologies présentent un grand intérêt dans le cadre notamment des réseaux 5G (5^èmeGénération) ou des réseaux 6G (6^èmeGénération), ouvrant des perspectives d’usage des réseaux de télécommunications inédites. Elles permettent notamment aux opérateurs de créer pour leurs clients des réseaux logiques virtuels de bout-en-bout, sur mesure et indépendants, évolutifs et agiles, et ce à partir d’une même infrastructure de réseau physique (réseau(x) d’accès, réseau cœur, etc.). Par le biais de ces réseaux logiques virtuels, les opérateurs sont capables de fournir à leurs clients des solutions optimisées pour des scénarii variés correspondant à des contraintes diverses en termes de fonctionnalités, de performances et de qualités de service.

Toutefois, le recours à ces technologies logicielles et de virtualisation des fonctions réseau expose aussi le réseau à de nouvelles vulnérabilités et pose de véritables challenges en termes de cyber sécurité.

Le document de Y. Khettab et al., intitulé « Virtual Security as a Service for 5G Verticals », IEEE Wireless Communications and Networking Conference (WCNC), 2018, propose une solution permettant de sécuriser un réseau 5G mettant en œuvre du « network slicing ». Il s’intéresse plus particulièrement à la sécurisation de chaque slice, et notamment des fonctions réseau virtuelles (ou VNF pour « Virtual Network Functions » en anglais) déployées dynamiquement dans chaque slice. Cette sécurisation est permise via une architecture s’appuyant notamment sur un orchestrateur de sécurité et sur un contrôleur centralisés, ainsi que sur des VNFs dédiées à la sécurité prévues dans chaque slice, incluant des dispositifs de protection tels que des dispositifs de détection d’intrusion (ou IDS pour « Intrusion Detection Systems » en anglais) ou de prévention d’instrusion (ou IPS pour « Intrusion Prevention Systems » en anglais), ou encore d’inspection de paquets (ou DPI pour « Deep Packet Inspection » en anglais). Lorsqu’un dispositif de protection détecte un flux malicieux, il alerte l’orchestrateur de sécurité, qui tient compte du nombre d’alertes reçues et de la sévérité de ces alertes pour instruire le cas échéant le contrôleur de stopper le flux malicieux (temporairement ou définitivement), ou de réduire sa bande passante pour éviter de surcharger le réseau tout en maintenant un certain niveau de service. Afin de ne pas compromettre la sécurité du réseau en cas de dysfonctionnements des VNFs dédiées à la sécurité, cette architecture permet également le déploiement dynamique (« auto-scaling » en anglais), par le biais de l’orchestrateur de sécurité et du contrôleur, de VNFs dédiées à la sécurité dans chacun des slices en fonction des besoins.

La solution proposée par Y. Khettab et al requiert toutefois une grande complexité pour protéger de façon efficace les VNFs déployées dans le réseau et dans ses différents slices, et peut induire une latence préjudiciable à la qualité de service offerte par le réseau.

L’invention permet notamment de remédier à l’inconvénient précité en s’appuyant sur une configuration hiérarchique dans laquelle une entité dite de commande du réseau décide des tâches liées à la sécurité du réseau exécutées par des dispositifs configurables, déployés dans le réseau pour protéger ses éléments (par exemple, les fonctions réseau), ces tâches correspondant à différents niveaux de protection et de complexité de mise en œuvre.

Plus particulièrement, l’invention vise selon un premier aspect, un procédé de commande, par une entité dite de commande d’un réseau, d’un dispositif de protection d’au moins un élément du réseau, ce procédé de commande comprenant, suite à un signalement d’une anomalie détectée par le dispositif de protection lors d’une exécution d’une première action de protection :
- une étape de détermination si une deuxième action de protection doit être exécutée par ledit dispositif de protection en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par ledit dispositif de protection lors de l’exécution de ladite première action ;
- si oui, une étape d’envoi audit dispositif de protection d’un ordre d’exécution de ladite deuxième action de protection.

Corrélativement, l’invention vise également une entité dite de commande d’un réseau comprenant :
- un module de détermination, activé suite à un signalement d’une anomalie détectée par un dispositif de protection d’au moins un élément du réseau lors d’une exécution d’une première action de protection, ce module de détermination étant configuré pour déterminer si une deuxième action de protection doit être exécutée par le dispositif de protection en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par le dispositif lors de l’exécution de ladite première action de protection ; et
- un module d’envoi, activé le cas échéant, et configuré pour envoyer au dispositif de protection un ordre d’exécution de la deuxième action de protection.

L’invention concerne aussi, selon un deuxième aspect, un procédé de protection, par un dispositif de protection d’au moins un élément d’un réseau, comprenant :
- une étape de signalement, à une entité dite de commande du réseau, d’une anomalie détectée par le dispositif de protection lors d’une exécution d’une première action de protection ;
- sur réception d’un ordre de l’entité de commande, une étape d’exécution par le dispositif de protection d’une deuxième action de protection déterminée par l’entité de commande en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par le dispositif de protection lors de l’exécution de ladite première action de protection.

Corrélativement, l’invention vise également un dispositif de protection d’au moins un élément d’un réseau comprenant :
- un module de surveillance, configuré pour exécuter au moins une première action de protection et pour signaler à une entité dite de commande du réseau une anomalie détectée concernant ledit au moins un élément du réseau ; et
- un module de déclenchement, activé sur réception d’un ordre de l’entité de commande, configuré pour déclencher une exécution par le module de surveillance d’une deuxième action de protection déterminée par l’entité de commande en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par le dispositif de protection lors de l’exécution de ladite première action de protection.

Aucune limitation n’est attachée à la nature des éléments du réseau protégés par le dispositif de protection. Il peut s’agir d’équipements physiques (ex. serveurs, mémoires, CPU (pour « Central Processing Unit » en anglais), etc.) ou d’éléments virtuels ou logicielles (comme par exemple des fonctions réseau virtuelles ou VNFs). Ainsi, ledit au moins un élément du réseau protégé par le dispositif de protection peut être par exemple une fonction réseau virtuelle hébergeant le dispositif de protection.

Le niveau de détection d’anomalies associé à un dispositif de protection peut être indifféremment, au sens de l’invention, un niveau « absolu » (ex. nombre d’anomalies détectées par le dispositif de protection en question sur une période de temps donnée), un niveau « relatif » (ex. taux de détections correctes, correspondant au nombre d’anomalies détectées par le dispositif de protection compte tenu des anomalies effectivement présentes dans le réseau et susceptibles d’affecter le ou les éléments du réseau surveillés par le dispositif de protection), ou encore une combinaison des deux. Un niveau de détection « relatif » donne avantageusement une indication sur la précision et la robustesse du dispositif de protection, tandis qu’un niveau de détection « absolu » donne une indication sur la menace en termes de cyber-attaques portant sur le ou les éléments du réseau qu’il surveille. En outre, la consommation des ressources peut être évaluée aussi bien en termes de quantité de ressources physiques consommées (ex. espace mémoire requis, etc.), que de temps mis pour exécuter les actions de protection ou durant lequel de telles ressources physiques sont sollicitées (ex. temps CPU).

Conformément à l’invention, l’entité de commande décide donc, à partir d’informations dont elle dispose sur les ressources consommées par le dispositif de protection et sur le niveau de menace courant pesant sur l’élément ou les éléments qu’il protège et/ou sur l’efficacité du dispositif de protection (fourni notamment par le niveau de détection associé au dispositif de protection), des actions de protection que ce dernier doit exécuter pour protéger efficacement ce ou ces éléments. Cela permet avantageusement de faire un compromis entre le niveau de protection appliqué par le dispositif de protection et la complexité qui en découle pour le dispositif de protection et incidemment pour le réseau.

La réalisation conjointe de plusieurs actions de protection (ex. détection d’anomalies, prédiction d’attaque, et mitigation) par un même dispositif de protection peut s’avérer extrêmement coûteuse et complexe, et peut « épuiser » les ressources de l’élément du réseau qui héberge ce dispositif de protection, ce qui peut s’avérer extrêmement préjudiciable pour cet élément et incidemment dégrader les performances du réseau. L’invention permet d’adapter ces actions de protection et de les sélectionner en fonction du contexte dans lequel se trouve(nt) l’élément ou les éléments protégés par le dispositif de protection, incluant les contraintes imposées au réseau. En outre, le procédé de commande selon l’invention est avantageusement réversible.

Ainsi, par exemple, si l’environnement dans lequel se trouve l’élément ou les éléments protégés par le dispositif de protection se dégrade (menace d’attaque plus importante ou attaque avérée), et que les ressources matérielles et/ou logicielles dont dispose le dispositif de protection sont suffisantes, l’entité de commande peut décider que ce dernier bascule vers un mode de protection plus robuste, ou inversement, si l’environnement s’améliore, vers un mode de protection plus léger.

Plus spécifiquement, et à titre illustratif, si le dispositif de protection exécute par exemple comme première action de protection un algorithme simple de détection d’anomalies (par exemple, un algorithme utilisant des règles de détection ou un algorithme supervisé binaire apte à distinguer deux classes de comportement, à savoir un comportement normal ou un comportement anormal), l’entité de commande peut, en fonction du contexte et d’un compromis précision de la détection/complexité qu’elle cherche à atteindre, décider que le dispositif de protection exécute un algorithme plus robuste et plus performant permettant de caractériser les attaques affectant le ou les éléments que le dispositif d’exécution protège. Un tel algorithme est par exemple un algorithme d’apprentissage automatique multi-classes. Elle peut en variante décider, si l’environnement est très menaçant, que le dispositif de protection exécute localement une ou plusieurs mesures de mitigation, telles que l’éviction de l’élément ou des éléments affectés par une attaque, ou le changement d’au moins une clé cryptographique utilisée pour communiquer sur le réseau par ce ou ces éléments affectés par l’attaque.

Bien entendu d’autres actions de protection que les actions de détection d’anomalies, de prédiction et de mitigation précitées peuvent être envisagées en variante. On note que préférentiellement, pour limiter la complexité de mise en œuvre de l’invention, les actions de protection ne sont pas exécutées simultanées par le dispositif de protection (autrement dit, lorsque l’entité de commande ordonne l’exécution d’une deuxième action de protection, le dispositif de protection exécute cette deuxième action en remplacement de la première action de protection). On peut toutefois envisager, pour plus d’efficacité en cas d’attaque avérée, que certaines actions de protection dûment sélectionnées par l’entité de commande soient exécutées de façon concomitante par le dispositif de protection, comme par exemple une action de détection et une action de mitigation.

L’invention, via la collaboration proposée entre l’entité de commande et le dispositif de protection, permet donc de tenir compte, pour sécuriser les éléments d’un réseau contre d’éventuelles cyber-attaques, et notamment les fonctions réseau virtuelles déployées dans ce réseau, de l’impact en termes de complexité des actions de protection mises en œuvre contre de telles cyber-attaques. Typiquement, ledit au moins un niveau de consommation de ressource peut comprendre :
- une quantité de signalisation pour signaler une anomalie détectée par le dispositif de protection ; et/ou
- une consommation d’une ressource de calcul et/ou de traitement ; et/ou
- une consommation d’une ressource de stockage.

Bien entendu, ces exemples ne sont donnés qu’à titre illustratif et d’autres ressources consommées par le dispositif de protection peuvent être prises en compte. La prise en compte de tels paramètres pour décider des actions de protection mises en œuvre par le dispositif de protection permet avantageusement de préserver la qualité de service du réseau tout en le protégeant efficacement.

L’invention peut également considérer, en complément du niveau de détection et du ou des niveaux de consommation des ressource, d’autres critères pour déclencher l’exécution d’une action de protection, comme par exemple un contexte spécifique, un niveau de vulnérabilité du réseau, un niveau de menace, etc.

En outre, l’intervention de l’entité de commande permet de gérer le cas de figure où le dispositif de protection est lui-même ciblé par une cyber-attaque. Dans le cas par exemple d’une attaque de type « épuisement des ressources » ou « resource exhaustion attack » en anglais, le dispositif de protection peut déclencher diverses mesures visant à amenuiser les capacités de l’élément du réseau qui l’héberge, ce qui peut entrainer la détérioration de la fonction assurée par cet élément dans le réseau et sa chute. En laissant la liberté au dispositif de protection de décider des actions de protection qu’il doit exécuter pour protéger le réseau (détection, prédiction, mesures de mitigation, etc.), il devient en effet plus vulnérable aux attaques. L’intervention de l’entité de commande comme préconisée par l’invention permet d’éviter cette situation.

L’invention est donc particulièrement bien adaptée pour une application à des réseaux évolutifs, tels que par exemple des réseaux 5G ou 6G, et en particulier des réseaux mettant en œuvre des technologies NFV de virtualisation de fonctions réseau, SDN de réseau défini par logiciel et/ou de network slicing.

On note que différentes configurations peuvent être envisagées pour mettre en œuvre l’invention.

Ainsi par exemple, le dispositif de protection peut être embarqué au niveau du réseau d’accès (par exemple dans une antenne micro-cellulaire ou dans une station de base), et l’entité de commande de ce dispositif de protection au niveau du réseau d’accès (par exemple dans une station de base pour un dispositif de protection localisé dans une antenne micro-cellulaire) ou du réseau cœur (pour un dispositif de protection localisé dans une antenne micro-cellulaire). Elle peut notamment être embarquée dans une fonction réseau (par exemple au niveau de la fonction réseau gérant l’accès et la mobilité aussi connue sous l’appellation de fonction AMF (pour « Access and Mobility Managmenent Function » en anglais) dans un réseau 5G ou dans un réseau 6G). On peut également envisager de déployer un ou plusieurs dispositifs de protection au niveau de fonctions réseau du réseau cœur, et l’entité de commande de ces dispositifs de protection dans un centre d’opérations de sécurité (ou SOC pour « Security Operations Center » en anglais).

En outre, un même élément du réseau (par exemple un équipement du réseau cœur) peut embarquer une entité de commande, commandant des dispositifs de protection situés à un niveau hiérarchique inférieur (par exemple situés dans un réseau d’accès), et un dispositif de protection, lui-même commandé par une entité de commande située à un niveau hiérarchique supérieur, comme par exemple dans un centre d’opérations de sécurité.

On peut également envisager qu’une entité de commande soit configurée pour commander un ou plusieurs dispositifs de protection.

Ainsi, l’invention concerne également une entité d’un réseau d’accès d’un réseau comprenant une entité de commande ou un dispositif de protection selon l’invention, et une entité d’un réseau cœur d’un réseau comprenant une entité de commande ou un dispositif de protection selon l’invention.

Dans un mode particulier de réalisation, l’étape de détermination du procédé de commande comprend une évaluation d’un indicateur défini à partir d’une fonction linéaire du niveau de détection d’anomalies et dudit au moins un niveau de consommation de ressource, et une comparaison dudit indicateur avec au moins un seuil donné dépendante de ladite deuxième action de protection.

A titre illustratif, dans un mode particulier de réalisation, la première action de protection comprend une exécution d’un algorithme de détection d’anomalies et lors de l’étape de détermination, l’entité de commande décide :
- si l’indicateur est inférieur à un premier seuil, de maintenir l’exécution par le dispositif de protection de la première action de protection ;
- si l’indicateur est compris entre le premier seuil et un deuxième seuil, d’ordonner au dispositif de protection d’exécuter un algorithme de prédiction d’une attaque affectant ledit au moins un élément protégé par le dispositif de protection ; et
- si l’indicateur est supérieur au deuxième seuil, d’ordonner au dispositif de protection d’exécuter au moins une mesure de mitigation d’une attaque affectant ledit au moins un élément protégé par le dispositif de protection.

De cette sorte, on s’assure d’une réponse graduelle en fonction de la sévérité de l’anomalie détectée et des ressources qui doivent être engagées pour y répondre. En outre, un tel indicateur est particulièrement simple à évaluer et permet d’adopter un compromis en fonction des paramètres que l’on souhaite privilégier via un choix approprié des facteurs de pondération appliqués dans la fonction linéaire.

Bien entendu, cet exemple n’est donné qu’à titre illustratif et d’autres fonctions, par exemple des fonctions plus complexes, peuvent être envisagées. En outre, les facteurs de pondération de la fonction linéaire peuvent également évoluer dans le temps si besoin ou en fonction des contraintes des opérateurs.

Dans un mode particulier de réalisation de l’invention, ledit au moins un niveau de consommation d’au moins une ressource par ledit dispositif de protection lors de l’exécution de ladite première action de protection est fourni par le dispositif de protection lors du signalement de l’anomalie.

Ce mode de réalisation est particulièrement simple à mettre en œuvre. En effet, ces informations peuvent être estimées aisément par le dispositif de protection, qui peut ensuite les faire remonter à chaque signalement d’anomalie à l’entité de commande. Cela permet à l’entité de commande de déterminer sans délai si une autre action de protection doit être envisagée pour protéger le réseau.

Dans un mode particulier de réalisation de l’invention, les procédés de commande et/ou de protection sont mis en œuvre par un ordinateur.

L’invention vise également un 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 une entité de commande conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de commande tel que décrit ci-dessus.

L’invention vise également un 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 de protection conforme à l’invention et comporte des instructions adaptées à la mise en œuvre d’un procédé de protection 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 d’un programme d'ordinateur tel que mentionné ci-dessus.

Le support d'information ou d’enregistrement peut être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, le support peut 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, le support d'information ou d’enregistrement peut être un support transmissible tel 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.

Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type Internet.

Alternativement, le support d'information 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 des procédés de commande et de protection selon l’invention.

Selon un autre aspect, l’invention vise aussi un système de surveillance d’un réseau comprenant au moins un dispositif de protection d’au moins une ressource du réseau selon l’invention et au moins une entité de commande selon l’invention dans lequel ledit au moins un élément du réseau comprend une fonction réseau virtuelle hébergeant ledit dispositif de protection.

Par exemple, au moins un dit dispositif de protection, dit premier dispositif de protection, est embarqué dans un équipement d’un réseau d’accès au réseau, et au moins un dit dispositif de protection, dit deuxième dispositif de protection, est embarqué dans une fonction réseau d’un réseau cœur du réseau, et une dite entité de commande du premier dispositif de protection est embarquée dans la fonction réseau, et une dite entité de commande du deuxième dispositif de protection est embarquée dans un centre d’opérations de sécurité du réseau cœur.

Dans un mode particulier de réalisation, le système de surveillance peut également être une fonction réseau virtuelle hébergeant un dispositif de protection selon l’invention et une entité de commande selon l’invention, configurée pour commander au moins un autre dispositif de protection selon l’invention.

Le système de surveillance selon l’invention dispose des mêmes avantages cités précédemment que le procédé de commande, l’entité de commande, le procédé de protection et le dispositif de protection selon l’invention.

On peut également envisager, dans d'autres modes de réalisation, que le procédé de commande, le procédé de protection, l’entité de commande, le dispositif de protection et le système de surveillance 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 représente, dans son environnement, un système de surveillance selon l’invention dans un mode particulier de réalisation ;
la représente l’architecture matérielle d’un équipement hébergeant un dispositif de protection et/ou une entité de commande selon l’invention appartenant au système de surveillance de la , dans un mode particulier de réalisation ;
la représente les modules fonctionnels d’un dispositif de protection selon l’invention appartenant au système de surveillance de la , dans un mode particulier de réalisation ;
la représente les modules fonctionnels d’une entité de commande selon l’invention appartenant au système de surveillance de la , dans un mode particulier de réalisation ;
la représente les étapes d’un procédé de protection selon l’invention telles qu’elles sont mises en œuvre par le dispositif de protection de la , dans un mode particulier de réalisation ;
la représente les étapes d’un procédé de commande selon l’invention telles qu’elles sont mises en œuvre par l’entité de commande de la , dans un mode particulier de réalisation ;

Description de l’invention

La représente, dans son environnement, un système 1 de surveillance d’un réseau NW, conforme à l’invention, dans un mode particulier de réalisation. Le réseau NW est par exemple ici un réseau 5G tel que défini par le standard 3GPP et on s’intéresse notamment, dans l’exemple illustré à la , à la protection de fonctions réseau virtuelles (ou VNFs) déployées au niveau du réseau cœur CN du réseau NW et du ou des réseaux d’accès RAN du réseau NW permettant d’accéder au réseau cœur CN. De telles fonctions virtuelles sont par exemple pour un réseau 5G une fonction gNodeB d’un réseau d’accès, ou une fonction AMF (pour « Access Mobility Function » en anglais) ou UDM (pour « Unified Data Management » en anglais) du réseau cœur CN, connues de l’homme du métier.

On note que ces hypothèses ne sont pas limitatives en soi, et on peut envisager d’appliquer l’invention à d’autres réseaux que des réseaux 5G, comme par exemple à des réseaux 6G, ainsi qu’à la surveillance d’autres éléments du réseau que des fonctions réseau virtuelles, comme par exemple des équipements physiques du réseau tels que des serveurs, des espaces de stockage, des équipements utilisateurs connectés au réseau, à des éléments du réseau jouant le rôle de relais (ex. véhicules, drones, etc.), etc.

Pour assurer la surveillance des éléments du réseau NW, le système 1 de surveillance comprend une pluralité de dispositifs 2 de protection configurables et conformes à l’invention. Par souci de simplification, dans l’exemple envisagé ici, chacun de ces dispositifs 2 de protection est configuré pour protéger un élément distinct du réseau NW, et plus spécifiquement, une fonction réseau. Bien entendu, cette hypothèse n’est pas limitative en soi, et on peut envisager en variante qu’un dispositif 2 de protection soit configuré pour protéger plusieurs éléments du réseau.

Parmi ces dispositifs 2 de protection, certains, alors référencés plus spécifiquement par L-IDS (pour « Local-Intrusion Detection Systems » en anglais), sont déployés au niveau du ou des réseaux d’accès RAN permettant d’accéder au réseau cœur CN, par exemple ils sont hébergés par des stations de base de type gNodeB pour protéger l’accès au réseau cœur CN (dans l’exemple envisagé ici, un L-IDS est configuré pour protéger la station de base gNodeB qui l’héberge, mais comme mentionné ci-avant on peut envisager qu’un même dispositif L-IDS soit configuré pour protéger non seulement la station de base gNode mais également des antennes micro-cellulaires qui lui sont le cas échéant rattachées). Par ailleurs, au moins un dispositif 2 de protection, alors référencé par G-IDS (pour « Global-Intrusion Detection Systems » en anglais), est déployé au niveau du réseau cœur CN ; par exemple, le dispositif G-IDS est hébergé par une fonction réseau virtuelle AMF de gestion de l’accès et de la mobilité dans le réseau 5G. On peut bien entendu envisager d’autres dispositifs G-IDS hébergés par d’autres fonctions réseau du réseau cœur CN, comme par exemple dans des fonctions PCF (ou « Policy Control Function » en anglais), SMF (ou « Session Management Function » en anglais), UDM (ou « User Data Management » en anglais), etc.

Conformément à l’invention, chaque dispositif 2 de protection (L-IDS et G-IDS) est configurable et peut exécuter différentes actions de protection pour protéger l’élément dont il est en charge. Dans le mode de réalisation décrit ici, on considère les actions de protection suivantes :

• une action de protection DETECT dite de détection, consistant en l’exécution d’un algorithme de détection d’anomalies relativement simple. Cet algorithme permet au dispositif 2 de protection de classer les comportements de l’élément qu’il surveille dans deux classes (ou catégories), à savoir dans une classe associée aux comportements normaux et dans une classe associée aux comportements anormaux. Il s’agit préférentiellement d’un algorithme peu complexe (ou « lightweight » en anglais) comme par exemple un algorithme basé sur des règles de détection ou des signatures permettant de distinguer un comportement normal d’un comportement anormal de l’élément surveillé du réseau, ou sur un modèle comportemental reflétant un comportement normal de l’élément surveillé, ou encore sur un algorithme supervisé binaire tel qu’un algorithme de type machine à supports de vecteurs (ou SVM pour « Support Vector Machine ») binaire ;
• une action de protection PRED dite de prédiction, consistant en l’exécution d’un algorithme de prédiction capable de caractériser plus précisément le comportement de l’élément surveillé et protégé par le dispositif 2 de protection, et notamment d’associer ce comportement à un type d’attaque particulier ou au contraire à un comportement normal. Un tel algorithme de prédiction est généralement plus performant et plus robuste qu’un algorithme de détection d’anomalies binaire tel que celui exécuté lors d’une action de détection DETECT, mais en contrepartie, il est également plus complexe. Un tel algorithme de prédiction est par exemple un algorithme basé sur des signatures d’attaques connues, ou un algorithme d’apprentissage automatique s’appuyant sur un réseau de neurones profond ou encore un algorithme SVM multi-classes. Il est capable de classer les comportements de l’élément surveillé par le dispositif 2 de protection selon un nombre N de catégories ou classes, N désignant un entier supérieur à 2 ; de telles catégories ou classes sont par exemple une classe C(1) regroupant les comportements normaux, une classe C(2) regroupant les comportements associés à un premier type d’attaque ATTACK1 (ex. attaques par déni de service ou DoS), une classe C(3) regroupant les comportements associés à un deuxième type d’attaque ATTACK2 (ex. attaques de type botnet), …, une classe C(N-2) regroupant les comportements associés à un N-2-ième type d’attaque ATTACKN-2 (ex. attaques de type « resource exhaustion »), et une classe C(N) regroupant les comportements inconnus que l’algorithme de prédiction n’est pas capable d’associer à l’une des N-1 autres classes ; et
• une action de protection REACT dite de réaction ou de mitigation, consistant en l’exécution d’au moins une mesure de mitigation locale en réponse à l’attaque affectant le cas échéant l’élément surveillé par le dispositif 2 de protection. Une telle mesure de mitigation locale est par exemple l’éviction de l’élément surveillé et protégé par le dispositif 2 de protection affecté par l’attaque (à cet effet, l’élément peut être enregistré par le dispositif 2 de protection dans une liste noire (ou « blacklist » en anglais) d’éléments du réseau NW à éviter, autrement dit vers lesquels le réseau NW n’envoie plus de données ou en provenance desquels le réseau n’accepte plus de données), ou le changement par le dispositif 2 de protection d’au moins une clé cryptographique utilisée pour communiquer sur le réseau NW par l’élément protégé par le dispositif 2 de protection et affecté par une attaque.

Bien entendu, ces actions de protection ne sont données qu’à titre illustratif et d’autres actions ou un nombre différent d’actions de protection possibles peuvent être envisagés en variante.

Conformément à l’invention, les actions de protection (DETECT, PRED ou REACT dans l’exemple envisagé ici) exécutées à un instant donné par les dispositifs 2 de protection (L-IDS et G-IDS) du système 1 de surveillance sont décidées et configurées au niveau de ces dispositifs 2 de protection par l’entremise d’une ou de plusieurs entités 3 de commande conformes à l’invention, appartenant au système 1 de surveillance et déployées dans le réseau NW.

Plus particulièrement, dans le mode de réalisation décrit ici, les dispositifs 2 de protection L-IDS sont commandés (i.e. configurés pour exécuter une action de protection particulière) par une entité 3 de commande hébergée dans une fonction réseau virtuelle du réseau cœur CN du réseau NW, et plus spécifiquement ici, dans la fonction réseau virtuelle AMF. Autrement dit, dans le mode de réalisation décrit ici, la fonction réseau virtuelle AMF héberge d’une part, un dispositif 2 de protection G-IDS, et d’autre part, une entité 3 de commande commandant des dispositifs 2 de protection L-IDS hébergés dans le ou les réseaux d’accès au réseau cœur CN. C’est également à ce titre un système de surveillance conforme à l’invention.

Le dispositif 2 de protection G-IDS hébergé par la fonction réseau AMF, et le cas échéant, les dispositifs 2 de protection G-IDS hébergés par les autres fonctions réseau du réseau cœur CN, est (sont) quant à lui (eux) commandé(s) par une entité 3 de commande hébergée dans le centre 4 d’opérations de sécurité (ou SOC) du réseau NW, situé dans le réseau cœur CN. De façon connue en soi, le SOC 4 est une entité de confiance du réseau NW qui dispose d’une vue d’ensemble sur le réseau NW, et en particulier sur les attaques diligentées contre ses éléments. Il peut lui-même exécuter un algorithme de prédiction performant et robuste s’appuyant par exemple sur une technique d’apprentissage automatique profond (« deep machine learning »). Il bénéficie avantageusement d’informations fournies par des experts en cyber-sécurité ou par des tiers, concernant des attaques susceptibles d’affecter le réseau NW (ex. signatures d’attaques connues, données d’apprentissage) offrant la possibilité de mettre à jour ou d’entraîner les algorithmes exécutés dans les dispositifs 2 de protection et dans le SOC lui-même.

Dans le mode de réalisation décrit ici, les dispositifs 2 de protection (L-IDS et G-IDS) et les entités 3 de commande sont des entités logicielles, hébergées dans des fonctions réseau virtuelles (ou VNFs) du réseau NW, ces VNFs étant elles-mêmes hébergées par des équipements physiques du réseau NW (ex. serveurs, unité en bande de base (ou BBU pour « Base Band Unit » en anglais), etc.). On note qu’une fonction réseau virtuelle ou VNF peut comprendre indifféremment une ou plusieurs machines virtuelles (ou VM pour « Virtual Machines » en anglais) ou un ou plusieurs conteneurs. Les équipements physiques hébergeant ces fonctions réseau virtuelles disposent de l’architecture matérielle d’un ordinateur 5, telle que représentée à la , comprenant notamment un processeur 6, une mémoire vive 7, une mémoire morte 8, une mémoire non volatile 9, et des moyens de communication 10. Les moyens de communication 10 intègrent diverses interfaces physiques et protocolaires permettant à l’ordinateur 5 de communiquer avec d’autres équipements du réseau NW ayant le même type d’architecture matérielle. Dans le cadre de l’invention, ces moyens de communication 10 sont exploités notamment par les dispositifs 2 de protection et par les entités 3 de commande pour communiquer entre eux. De telles interfaces sont connues en soi et non décrites en détail ici.

La mémoire morte 8 constitue un support d’enregistrement conforme à l’invention, lisible par le processeur 6 et sur lequel est enregistré un programme d’ordinateur conforme à l’invention (ce programme d’ordinateur pouvant lui-même être constitué par un ou plusieurs sous-programmes), à savoir, pour les équipements physiques hébergeant des dispositifs 2 de protection, un programme d’ordinateur PROG2, et pour les équipements physiques hébergeant des entités 3 de commande, un programme d’ordinateur PROG3.

Comme illustré sur la , le programme PROG2 définit par l’intermédiaire de ses instructions des modules fonctionnels d’un dispositif 2 de protection selon l’invention qui s’appuient ou commandent les éléments matériels 6 à 10 précités. Ces modules fonctionnels comprennent notamment :
- un module SURV de surveillance, configuré pour exécuter au moins une première action de protection et pour signaler, à l’entité 3 de commande dont le dispositif 2 de protection dépend, une anomalie détectée le cas échéant concernant l’élément du réseau que le dispositif 2 de protection surveille. La première action de protection est par exemple une action de détection DETECT ou de prédiction PRED telles que décrites précédemment. Le signalement effectué par le module SURV de surveillance peut être accompagné des caractéristiques de trafic concernant l’élément surveillé collectées par le dispositif 2 de protection et qui ont conduit à la détection de l’anomalie détectée, éventuellement si cela s’applique la signature associée à cette anomalie (selon la technique utilisée par le module de surveillance), une identification de l’élément impacté (notamment si le dispositif 2 de protection surveille plusieurs éléments) ou de l’élément malicieux à l’origine de cette anomalie si cela est disponible au niveau du module SURV de surveillance, ou toute autre information pouvant être exploitée par le réseau NW, et en particulier par l’entité 3 de commande ou par le SOC 4 pour vérifier l’anomalie détectée et, en cas d’attaque avérée, prendre des dispositions contre cette attaque (ex. mesures de mitigation locales et/ou globales) ; et
- un module TRIG de déclenchement, activé sur réception d’un ordre de l’entité 3 de commande, et configuré pour déclencher une exécution par le module SURV de surveillance d’une deuxième action de protection déterminée par l’entité de commande en fonction d’un niveau de détection d’anomalies associé au dispositif 2 de protection et d’au moins un niveau de consommation de ressource par ce dispositif 2 de protection lors de l’exécution de la première action de protection. La deuxième action de protection est par exemple une action de prédiction PRED ou une action de mitigation REACT si la première action de protection est une action de détection DETECT, ou une action de détection DETECT ou une action de mitigation REACT si la première action de protection est une action de prédiction PRED. Comme détaillé davantage ultérieurement, pour décider de l’action de protection à activer au niveau du dispositif 2 de protection, divers niveaux de consommation de ressource peuvent être considérés par l’entité 3 de commande, comme par exemple une quantité OVERH de signalisation (aussi plus communément désignée par « overhead » en anglais) pour signaler une anomalie détectée par le dispositif 2 de protection en exécutant la première action de protection, une consommation COMPUT d’une ressource de calcul et/ou de traitement (ou plus généralement de puissance CPU pour « Central Processing Unit » en anglais)) lors de l’exécution de la première action de protection, et/ou une consommation MEM d’une ressource de stockage lors de l’exécution de la première action de protection. Bien entendu, ces exemples ne sont donnés qu’à titre illustratif et ne sont pas limitatifs de l’invention, on peut envisager d’autres niveaux de consommation d’autres ressources, et l’entité 3 de commande peut exploiter un ou plusieurs de ces niveaux.

Dans le mode de réalisation décrit ici, le programme PROG2 définit également un autre module fonctionnel, à savoir un module ESTIM d’estimation configuré notamment pour estimer et communiquer à l’entité 3 de commande le(s) niveau(x) de consommation de ressource qu’elle exploite pour décider de l’action de protection à exécuter par le module SURV de surveillance. On suppose par exemple ici que l’entité 3 de commande exploite les trois niveaux de ressource précités, OVERH, COMPUT et MEM et que le module ESTIM d’estimation est configuré pour estimer ces trois niveaux de ressource et les transmettre à l’entité 3 de commande lors du signalement de l’anomalie détectée par le module SURV de surveillance.

Les modules SURV, TRIG et ESTIM sont ainsi configurés pour mettre en œuvre les étapes d’un procédé de protection selon l’invention. Leur fonctionnement est décrit plus en détail en référence à la décrivant les principales étapes de ce procédé.

De façon similaire, et comme illustré sur la , le programme PROG3 définit par l’intermédiaire de ses instructions des modules fonctionnels d’une entité 3 de commande selon l’invention qui s’appuient ou commandent les éléments matériels 6 à 10 précités de l’ordinateur 5. Ces modules fonctionnels comprennent notamment :
- un module DET de détermination, activé suite à un signalement d’une anomalie concernant un élément du réseau NW détectée, lors de l’exécution d’une première action de protection, par un dispositif 2 de protection chargé de protéger cet élément du réseau. Le module DET est configuré pour déterminer si une deuxième action de protection doit être exécutée par le dispositif 2 de protection en fonction, comme mentionné précédemment, d’un niveau de détection d’anomalies associé au dispositif 2 de protection et d’au moins un niveau de consommation de ressource par le dispositif 2 de protection dans le premier mode de protection. Ce(s) niveau(x) de consommation est (sont) fourni(s) dans le mode de réalisation décrit ici, comme mentionné précédemment, par le dispositif 2 de protection lors du signalement de l’anomalie ; et
- un module TX d’envoi, activé le cas échéant, et configuré pour envoyer au dispositif 2 de protection un ordre d’exécution de la deuxième action de protection.

Les modules DET et TX sont ainsi configurés pour mettre en œuvre les étapes d’un procédé de commande selon l’invention. Leur fonctionnement est décrit plus en détail en référence à la décrivant les principales étapes de ce procédé.

Nous allons maintenant décrire, en référence auxfigures 5 et 6, les principales étapes d’un procédé de protection et d’un procédé de commande telles qu’elles sont mises en œuvre respectivement par un dispositif 2 de protection et par une entité 3 de commande tels que décrits ci-avant, dans un mode particulier de réalisation de l’invention.

On envisage ici, pour faciliter la compréhension de l’invention, que le dispositif 2 de protection est embarqué au niveau d’un réseau d’accès RAN du réseau NW, dans une station de base gNodeB, et est configuré pour protéger cette station de base gNodeB : il s’agit donc d’un dispositif 2 de protection de type L-IDS. On suppose par ailleurs que ce dispositif L-IDS est géré par une entité 3 de commande hébergée par la fonction réseau virtuelle AMF du réseau cœur CN, qui décide de l’action de protection que le dispositif 2 de protection doit exécuter pour assurer la protection de l’équipement dans lequel il est embarqué, à savoir ici la station de base gNodeB.

On note toutefois que ces hypothèses ne sont pas limitatives en soi et l’invention peut s’appliquer indifféremment à d’autres niveaux du réseau NW. Selon un premier exemple, elle peut s’appliquer notamment, au niveau d’un dispositif 2 de protection hébergé dans le réseau cœur CN (autrement dit, au niveau d’un dispositif de type G-IDS), comme par exemple dans la fonction AMF, et au niveau d’une entité 3 de commande hébergée dans une autre fonction du réseau cœur CN, comme par exemple dans le SOC 4. Selon un deuxième exemple, le dispositif 2 de protection L-IDS peut être hébergé par une antenne micro-cellulaire d’un réseau d’accès RAN au réseau cœur CN et son entité 3 de commande dans une station de base gNodeB du réseau d’accès en question ; dans cette configuration, la station de base gNodeB peut également héberger un dispositif 2 de protection G-IDS dont l’entité 3 de commande se trouve hébergée par une VNF du réseau cœur CN et notamment par la fonction AMF du réseau cœur CN. Bien entendu ces exemples ne sont donnés qu’à titre illustratif et bien d’autres configurations peuvent être envisagées.

On suppose ici, que le dispositif 2 de protection, et plus particulièrement son module SURV de surveillance, est configuré pour surveiller et protéger l’élément du réseau NW dont il a la charge (station gNodeB dans l’exemple envisagé ici) en exécutant une première action de protection. On suppose ici à titre illustratif que cette première action de protection est une action de détection DETECT telle qu’introduite précédemment. Toutefois, cette hypothèse n’est pas limitative en soi, la première action de protection peut être une autre action de protection comme par exemple une action de prédiction PRED.

La configuration du dispositif 2 de protection pour qu’il exécute lors de la surveillance de la station de base gNodeB l’hébergeant cette première action de protection peut être définie par défaut ou résulter d’un ordre de l’entité 3 de commande gérant le dispositif 2 de protection.

En référence à la , le module SURV de surveillance du dispositif 2 de protection surveille donc l’élément du réseau qu’il est chargé de protéger en exécutant une action de détection DETECT (étape E10) et détermine si le comportement de cet élément du réseau présente une anomalie (étape test E20). A cet effet, comme mentionné précédemment, le module SURV de surveillance peut utiliser un algorithme de détection d’anomalies s’appuyant sur des règles de détection ou sur un modèle comportemental simple décrivant un comportement normal de l’élément qu’il surveille, ou encore un algorithme d’apprentissage automatique capable de classer le comportement de l’élément surveillé selon deux classes, à savoir une classe associée à un comportement normal et une classe associée à un comportement anormal (ex. algorithme SVM binaire). Le module SURV de surveillance applique cet algorithme à des caractéristiques (ou « features » en anglais) du trafic transitant par l’élément du réseau surveillé (émanant de, destinées à ou relayées par cet élément), et obtenues directement par le dispositif 2 de protection ou par l’intermédiaire de sondes déployées dans le réseau NW de façon connue en soi. De telles caractéristiques sont par exemple un taux de paquets erronés, un nombre d’échecs de communication, une adresse source, un nombre de redémarrages d’équipements utilisateurs attachés à l’élément du réseau surveillé, un nombre d’accès à certaines VNFs, un nombre de paquets envoyés et supprimés par seconde, un taux d’information altéré, etc. Les caractéristiques à surveiller peuvent être déterminées notamment par des experts en cyber-sécurité, en fonction des attaques susceptibles de menacer le réseau NW.

Si aucune anomalie n’est détectée (réponse non à l’étape test E20), la surveillance continue, comme décrit ci-avant.

Si une anomalie est détectée par le module SURV de surveillance alors qu’il exécute l’algorithme de détection d’anomalies (réponse oui à l’étape test E20), le module SURV signale cette anomalie à l’entité 3 de commande (étape E30). Dans le mode de réalisation décrit ici, lors de ce signalement, le module SURV fournit différentes informations à l’entité 3 de commande, à savoir les caractéristiques de trafic ayant conduit à détecter une anomalie ainsi que différents niveaux de consommation de ressource associés à l’exécution de la première action de protection DETECT (c’est-à-dire à l’exécution de l’algorithme de détection).

Dans l’exemple envisagé ici, comme mentionné précédemment, ces niveaux de consommation comprennent la quantité OVERH de signalisation (overhead) pour signaler l’anomalie détectée (incluant les informations complémentaires fournies lors du signalement par le module SURV et évoquées ci-avant), la consommation COMPUT de puissance CPU, et la consommation MEM de mémoire relatives au fonctionnement du dispositif 2 de protection dans le premier mode de protection DETECT (autrement dit lorsqu’il est configuré pour mettre en œuvre l’algorithme de détection). Elles sont évaluées par le module ESTIM du dispositif 2 de protection à partir d’informations disponibles auprès du dispositif 2 de protection : par exemple, la quantité OVERH peut être estimée en nombre de bits en tenant compte de la quantité d’informations remontée lors du signalement à l’entité 3 de commande ; concernant les consommations COMPUT et MEM, celles-ci sont accessibles auprès du système d’exploitation de l’ordinateur 5 hébergeant le dispositif 2 de protection, qui est en mesure d’indiquer pour chaque tâche exécutée par l’ordinateur 5, en l’espèce ici l’algorithme de détection, le temps d’utilisation du CPU, et la quantité de mémoire requise. Ces données sont ensuite normalisées par rapport aux valeurs maximales qu’elles peuvent atteindre, compte tenu des contraintes fixées par le constructeur de l’équipement (ex. VNF ou équipement physique selon le cas de figure considéré) hébergeant le dispositif 2 de protection. On note que cette normalisation est effectuée pour obtenir des niveaux de consommation sans dimension tous compris entre 0 et 1, par souci de simplification, mais est toutefois optionnelle.

En référence à la , suite au signalement du dispositif 2 de protection (étape F10), l’entité 3 de commande, par l’intermédiaire de son module DET de détermination, incrémente un compteur CNT d’anomalies détectées par le dispositif 2 de détection (en variante, ce compteur CNT peut être incrémenté par le dispositif 2 de protection lui-même et fournit lors du signalement à l’entité 3 de commande) et détermine s’il convient de maintenir l’exécution par le dispositif 2 de protection de la première action de protection DETECT ou d’activer l’exécution d’une deuxième action de protection au niveau du dispositif 2 de protection.

A cet effet, dans le mode de réalisation décrit ici, le module DET de détermination évalue
un indicateur f pour le dispositif 2 de protection, défini à partir d’une fonction linéaire du niveau DL de détection d’anomalies du dispositif 2 de protection et des niveaux OVERH, COMPUT et MEM de consommation de ressource fournis par le dispositif 2 de protection dans son signalement (étape F20). Par exemple : où et désignent des facteurs de pondération prédéterminés, choisis entre 0 et 1. Ces facteurs de pondération sont choisis en fonction du compromis que l’on souhaite avoir entre le niveau de détection d’anomalies du dispositif 2 de protection et la complexité de mise en œuvre du mode de protection appliqué par le dispositif 2 de protection. Par exemple, on peut choisir les facteurs de pondération tous égaux à ¼ ou en variante accorder plus d’importance au niveau de détection d’anomalies si l’on souhaite accroître la sécurité du réseau NW, ou au contraire accorder plus d’importance aux niveaux de consommation, si l’on souhaite favoriser une complexité faible et une latence en résultant plus faible, ou encore ne pas appliquer les mêmes coefficients de pondération à chacun des niveaux de consommation de ressource, en fonction des contraintes dont on dispose, etc.

Il convient de noter que comme évoqué précédemment, l’indicateur f peut tenir compte, dans un autre mode de réalisation, d’autres critères que le niveau de détection d’anomalies et des niveaux de consommation de ressource.

Le niveau DL de détection d’anomalies associé au dispositif 2 de protection (dispositif L-IDS pour mémoire) est plus particulièrement ici un taux de détection d’anomalies par le dispositif 2 de protection L-IDS au regard des anomalies effectivement présentes dans le réseau NW et affectant l’élément du réseau NW surveillé par le dispositif 2 de protection L-IDS. On prend ici comme référence pour déterminer les anomalies effectivement présentes dans le réseau NW les anomalies détectées par le dispositif G-IDS hébergé par le même équipement que l’entité 3 de commande, à savoir dans l’exemple envisagé ici la fonction réseau AMF. Ce dispositif G-IDS est avantageusement situé à un niveau hiérarchique supérieur par rapport au dispositif L-IDS et bénéficie des informations récoltées par l’entité 3 de commande colocalisée dans la fonction AMF provenant d’une pluralité de dispositifs 2 de protection L-IDS (par exemple une pluralité de dispositifs 2 de protection hébergés par une pluralité de stations de base gNodeB d’un même réseau d’accès ou de plusieurs réseaux d’accès distincts permettant d’accéder au réseau cœur CN). A chaque anomalie signalée par un dispositif 2 de protection L-IDS, l’entité 3 de commande communique au dispositif G-IDS toutes les informations récoltées des dispositifs L-IDS (en particulier les caractéristiques de trafic) dont elle a la charge et qui lui ont remonté des anomalies dans une période prédéterminée, et le dispositif G-IDS détermine à partir de ces informations si une anomalie affecte effectivement l’élément surveillé par le dispositif 2 de protection. Par exemple, si nœud mobile malicieux cible plusieurs stations de base gNodeB du réseau d’accès (ce qui est souvent le cas en pratique) gérées par une même entité de commande, l’entité de commande remonte au dispositif G-IDS toutes les anomalies qui lui ont été signalées par des dispositifs L-IDS qui sont en lien avec le comportement de ce nœud mobile. On note que pour cette détermination, le dispositif G-IDS peut appliquer notamment son algorithme de prédiction, qui est comme mentionné précédemment, robuste et précis. Il peut en variante utiliser un autre algorithme robuste tel qu’un algorithme d’apprentissage profond (ou « deep learning » en anglais). Si l’anomalie est confirmée par le dispositif G-IDS, l’entité 3 de commande via son module DET de détermination incrémente un compteur N.

On note par ailleurs que si l’on se place au niveau d’un dispositif 2 de protection G-IDS, c’est le SOC 4 qui exécute un algorithme de prédiction pour confirmer ou non l’anomalie remontée par le dispositif 2 de protection G-IDS.

Puis le module DET de détermination de l’entité 3 de commande détermine le taux d’anomalies détecté par le dispositif 2 de protection à partir du compteur CNT d’anomalies et du nombre N, soit :
DL = CNT/N

Dans une variante de réalisation, le nombre N d’anomalies effectives peut être fourni à l’entité 3 de commande par une autre entité du réseau NW, comme par exemple par le SOC 4. Dans une autre variante encore, l’entité 3 de commande peut s’appuyer sur les anomalies détectées par les autres dispositifs L-IDS sous sa responsabilité (et pour l’entité 3 de commande hébergée dans le SOC 4 sur les anomalies détectées le cas échéant par les autres dispositifs G-IDS sous sa responsabilité), en appliquant par exemple un système de vote, pour déterminer si une anomalie est effectivement présente. Ces exemples ne sont donnés qu’à titre illustratif et d’autres variantes peuvent être envisagées pour déterminer le niveau de détection d’anomalies associé au dispositif 2 de protection. Dans une autre variante, le niveau de détection d’anomalies peut consister en le nombre N d’anomalies effectives détectées par le dispositif 2 de protection, reflétant le niveau de menace effectif à l’encontre de l’élément protégé par le dispositif 2 de protection. Dans une autre variante encore, le niveau de détection d’anomalies associé au dispositif 2 de protection peut combiner ces différents aspects (ex. un niveau « relatif » comme un taux de détection et un niveau « absolu » comme le nombre d’anomalies effectives détectées).

Le module DET de détermination de l’entité 3 de commande compare ensuite l’indicateur f ainsi évalué avec au moins un seuil donné (étape F30). Plus spécifiquement ici, le module DET compare l’indicateur f par rapport à deux seuils THR1 et THR2 correspondant respectivement à l’activation des actions de protection PRED et REACT. Préférentiellement, on considère autant de seuils que d’actions de protection alternatives possibles par rapport à la première action de protection DETECT exécutée par le dispositif 2 de protection. Ces seuils sont compris ici entre 0 et 1. Par exemple, THR1 est pris égal à 0.5 et THR2 est pris égal à 0.6. Toutefois ces exemples ne sont donnés qu’à titre illustratif, et d’autres valeurs de seuil peuvent être envisagées.

Si l’indicateur f est inférieur au seuil THR1 (réponse non à l’étape test F40), le module DET de détermination de l’entité 3 de commande décide de maintenir au niveau du dispositif 2 de protection l’exécution de la première action de protection DETECT. Autrement dit, le dispositif 2 de protection continue d’appliquer aux caractéristiques de trafic qu’il collecte sur l’élément du réseau NW qu’il surveille, un algorithme de détection d’anomalies.

Sinon (réponse oui à l’étape test F40), le module DET de détermination de l’entité 3 de commande décide de déclencher au niveau du dispositif 2 de protection l’exécution d’une deuxième action de protection différente de l’action de détection DETECT.

Plus spécifiquement ici, si l’indicateur f est compris entre le seuil THR1 et le seuil THR2, le module DET de l’entité 3 de commande décide de déclencher au niveau du dispositif 2 de protection une action de prédiction PRED : autrement dit, le dispositif 2 de protection ne détecte pas seulement que le trafic transitant par l’élément du réseau qu’il surveille présente des anomalies mais tente maintenant de qualifier le type d’attaque correspondant aux anomalies détectées et affectant l’élément qu’il protège.

Si l’indicateur f est supérieur au seuil THR2, le module DET de l’entité 3 de commande décide de déclencher au niveau du dispositif 2 de protection l’exécution d’une action de mitigation REACT : autrement dit, le dispositif 2 de protection exécute une ou plusieurs mesures de mitigation locales destinées à mettre fin à la ou aux attaques affectant l’élément qu’il protège.

On note que dans le mode de réalisation décrit ici, la deuxième action de protection est exécutée en remplacement de la première action de protection. Autrement dit, les actions de protection sont exclusives les unes des autres et ne sont pas exécutées simultanément afin de préserver les ressources de la VNF hébergeant le dispositif 2 de protection. Toutefois, on peut envisager, dans une variante de réalisation, que des actions de protection soient exécutées de façon concomitante, comme par exemple de l’action de mitigation REACT avec l’action de détection DETECT, dès lors que la complexité en résultant a été actée par l’entité 3 de commande.

Si le module DET de l’entité 3 de commande détermine que le dispositif 2 de protection doit exécuter une deuxième action de protection autre que la première action de protection, il envoie au dispositif 2 de protection, via son module TX d’envoi, un ordre CMD d’exécution de la deuxième action de protection en remplacement de la première action de protection (étape F50).

Dans le mode de réalisation décrit ici, si le module DET de l’entité 3 de commande détermine que le dispositif 2 de protection doit continuer d’exécuter la première action de détection, il envoie au dispositif 2 de protection, via son module TX d’envoi, un ordre CMD de maintien de la première action de protection DETECT (étape F60). On note toutefois que cette étape est optionnelle et on peut envisager en variante que dans ce cas de figure, l’entité 3 de commande acquitte simplement le signalement remonté par le dispositif 2 de protection sans lui envoyer de commande explicite en retour (ce qui revient implicitement à lui demander de continuer d’exécuter la première action de protection DETECT).

Sur réception de l’ordre CMD de l’entité 3 de commande (étape E40), le dispositif 2 de protection l’exécute par l’intermédiaire de son module TRIG (étape E50). Si l’ordre de l’entité 3 de commande ordonne de maintenir l’action de protection en cours (DETECT dans l’exemple envisagé ici), le module SURV de surveillance du dispositif 2 de protection continue d’appliquer aux caractéristiques de trafic qu’il collecte l’algorithme de détection d’anomalies. Sinon, le module TRIG du dispositif 2 de protection configure le module SURV de surveillance pour qu’il exécute l’action de protection indiquée dans l’ordre CMD reçu de l’entité 3 de commande (à savoir PRED ou REACT dans l’exemple envisagé ici).

Autrement dit, si l’ordre CMD comprend un ordre d’exécuter une action de prédiction PRED, le module SURV de surveillance du dispositif 2 de protection applique dorénavant aux caractéristiques de trafic qu’il collecte un algorithme de prédiction plus robuste et plus performant lui permettant non seulement de détecter des anomalies mais également de qualifier l’attaque à l’origine de ces anomalies. Les étapes des figures 5 et 6 qui viennent d’être décrites sont alors réitérées en les appliquant à l’action de protection PRED (qui devient « première action de protection » au sens de l’invention). Dès lors, dès qu’il détecte une anomalie (en l’espèce ici une attaque), le module SURV de surveillance signale cette anomalie à l’entité 3 de commande, incluant dans son signalement non seulement les informations précitées décrites précédemment en référence à l’étape E30 (les niveaux de ressources étant maintenant évalués en référence à l’action de prédiction PRED), mais également le type de l’attaque qu’il a associé à cette anomalie.

On note que dans l’exemple envisagé ici, l’algorithme de prédiction exécuté par le module SURV de surveillance dans le mode de protection PRED peut conduire à associer à l’anomalie détectée la classe C(N) qui contient toutes les anomalies que le dispositif 2 de protection n’est pas en mesure de caractériser, c’est-à-dire d’associer à un type d’attaque particulier. S’il s’avère qu’une anomalie est associée à cette classe C(N) par le module SURV de surveillance, alors sur réception du signalement, l’entité 3 de commande communique au dispositif 2 de protection qui est colocalisé avec elle (dispositif G-IDS dans l’exemple envisagé ici) les caractéristiques de trafic associées à l’anomalie pour qu’il tente à son tour de qualifier cette anomalie et de l’associer à une attaque connue. On note que dans le cas où les procédés qui viennent d’être décrits sont appliqués entre le dispositif G-IDS embarqué dans la fonction réseau AMF et le SOC 4, c’est le SOC 4 qui est chargé de caractériser l’anomalie détectée par le dispositif 2 de protection L-IDS.

Si l’ordre CMD comprend l’exécution d’une action de mitigation REACT, le module SURV de surveillance du dispositif 2 de protection exécute alors une ou plusieurs mesures de mitigation à l’égard de l’attaque affectant l’élément qu’il protège. Une telle mesure de mitigation est par exemple l’éviction de l’élément affecté par l’attaque ou de l’équipement à l’origine de l’attaque (ex. en référençant ces éléments dans une liste noire et en supprimant le trafic destiné à ou issu de cet élément), le changement d’une ou de plusieurs clés cryptographiques utilisées par l’élément affecté par l’attaque pour communiquer sur le réseau NW, etc. On note que l’exécution d’actions de mitigation locales au niveau du dispositif 2 de protection peut s’accompagner d’autres actions de mitigations au niveau global, appliquées par exemple par le SOC 4, par un dispositif 2 de protection G-IDS ou par d’autres équipements du réseau. Une telle action est par exemple l’instantiation de nouvelles VNFs (par exemple d’une fonction AMF si la fonction AMF est affectée par une attaque).

Comme mentionné précédemment, les étapes E10 à E50 et F10 à F60 qui viennent d’être décrites sont appliquées respectivement entre chaque dispositif 2 de protection L-IDS et l’entité 3 de commande gérant ce dispositif L-IDS (colocalisée ici dans la fonction réseau AMF avec un dispositif 2 de protection G-IDS), et de façon similaire entre chaque dispositif 2 de protection G-IDS et l’entité 2 de commande gérant ce dispositif G-IDS hébergée par le SOC 4. Les niveaux de consommation de ressource pris en compte sont alors ceux du dispositif G-IDS. On note que pour évaluer l’indicateur f, le SOC 4 peut utiliser une fonction différente (ex. des facteurs de pondération différents ou une fonction non linéaire) que celle utilisée par l’entité de commande d’un dispositif L-IDS.

On note également que l’invention s’applique dans d’autres configurations que celle représentée à la où les dispositifs L-IDS sont hébergés par des stations de base gNodeB et le dispositif G-IDS est hébergé par une fonction réseau virtuelle AMF du réseau cœur CN, et où l’entité 3 de commande des dispositifs L-IDS est hébergée dans la fonction réseau virtuelle AMF tandis que l’entité 3 de commande du dispositif G-IDS est hébergée dans le SOC 4. De manière générale, on peut prévoir des dispositifs 2 de protection dans n’importe quel équipement du réseau d’accès (ex. antennes microcellulaire, points d’accès ou stations de base) ou du réseau cœur CN (ex. fonctions réseau virtuelles, équipements physiques), tandis que les entités 3 de commande peuvent être hébergées indifféremment dans le réseau d’accès ou dans le réseau cœur CN, et en particulier dans les fonctions réseau virtuelles ou dans le SOC. En outre, l’invention s’applique également dans le cadre d’un réseau 5G, 6G ou autre utilisant une technique de network slicing sur chaque tranche de réseau du réseau.

Claims (16)

1. Procédé de commande, par une entité (3) dite de commande d’un réseau (NW), d’un dispositif (2) de protection d’au moins un élément du réseau, ledit procédé de commande comprenant, suite à un signalement (F10) d’une anomalie détectée par ledit dispositif de protection lors d’une exécution d’une première action de protection (ACT1) :
   - une étape de détermination (F20,F30,F40) si une deuxième action (ACT2) de protection doit être exécutée par ledit dispositif de protection en fonction d’un niveau de détection d’anomalies associé au dispositif de protection et d’au moins un niveau de consommation de ressource par ledit dispositif de protection lors de l’exécution de ladite première action de protection ;
   - si oui, une étape d’envoi (F50) audit dispositif de protection d’un ordre d’exécution de ladite deuxième action (ACT2) de protection.
2. Procédé de commande selon la revendication 1 dans lequel l’étape de détermination comprend une évaluation (F20) d’un indicateur (f) défini à partir d’une fonction linéaire du niveau de détection d’anomalies et dudit au moins un niveau de consommation de ressource, et une comparaison (F30,F40) de l’indicateur évalué avec au moins un seuil (THR1, THR2) dépendant de ladite deuxième action de protection.
3. Procédé de commande selon la revendication 2 dans lequel la première action de protection (ACT1) comprend une exécution d’un algorithme (DETECT) de détection d’anomalies et lors de l’étape de détermination, l’entité de commande décide :
   - si ledit indicateur (f) est inférieur à un premier seuil (THR1), de maintenir (F60) l’exécution par le dispositif de protection de la première action de protection ;
   - si ledit indicateur (f) est compris entre le premier seuil (THR1) et un deuxième seuil (THR2), d’ordonner (F50) au dispositif de protection d’exécuter un algorithme de prédiction (PRED) d’une attaque affectant ledit au moins un élément protégé par le dispositif de protection ; et
   - si ledit indicateur (f) est supérieur au deuxième seuil (THR2), d’ordonner (F50) au dispositif de protection d’exécuter au moins une mesure de mitigation (REACT) d’une attaque affectant ledit au moins un élément protégé par le dispositif de protection.
4. Procédé de commande selon l’une quelconque des revendications 1 à 3 dans lequel ledit au moins un niveau de consommation d’au moins une ressource par ledit dispositif de protection lors de l’exécution de ladite première action de protection est fourni par le dispositif de protection lors du signalement de l’anomalie.
5. Procédé de protection, par un dispositif (2) de protection d’au moins un élément d’un réseau, comprenant :
   - une étape (E30) de signalement, à une entité dite de commande du réseau, d’une anomalie détectée par ledit dispositif de protection lors d’une exécution d’une première action de protection ;
   - sur réception (E40) d’un ordre de ladite entité de commande, une étape d’exécution (E50) par le dispositif de protection d’une deuxième action (ACT2) de protection déterminée par l’entité de commande en fonction d’un niveau de détection d’anomalies associé audit dispositif de protection et d’au moins un niveau de consommation de ressource par ledit dispositif de protection lors de l’exécution de ladite première action de protection.
6. Procédé selon l’une quelconque des revendications 1 à 5 dans lequel ladite au moins une première action de protection (ACT1) comprend une exécution d’un algorithme de détection (DETECT) d’anomalies et ladite deuxième action de protection comprend une exécution d’un algorithme de prédiction (PRED) d’une attaque affectant ledit au moins un élément du réseau ou d’au moins une mesure de mitigation (REACT) d’une attaque affectant ledit au moins un élément du réseau.
7. Procédé selon la revendication 3 ou 6 dans lequel ladite au moins une mesure de mitigation (REACT) comprend une éviction dudit au moins un élément du réseau affecté par ladite attaque, ou un changement d’au moins une clé cryptographique utilisée pour communiquer sur le réseau par ledit au moins un élément du réseau affecté par ladite attaque.
8. Procédé selon l’une quelconque des revendications 1 à 7 dans lequel ledit au moins un niveau de consommation de ressource comprend :
   - une quantité de signalisation pour signaler une anomalie détectée par le dispositif de protection ; et/ou
   - une consommation d’une ressource de calcul et/ou de traitement ; et/ou
   - une consommation d’une ressource de stockage.
9. Procédé selon l’une quelconque des revendications 1 à 8 dans lequel ledit au moins un élément du réseau est une fonction réseau virtuelle (AMF) hébergeant le dispositif de protection.
10. Programme d’ordinateur (PROG2,PROG3) comportant des instructions pour l’exécution d’un procédé selon l’une quelconque des revendications 1 à 9, lorsque ledit programme est exécuté par un ordinateur.
11. Entité (3) dite de commande d’un réseau comprenant :
    - un module (DET) de détermination, activé suite à un signalement d’une anomalie détectée par un dispositif de protection d’au moins un élément du réseau lors d’une exécution d’une première action de protection, ledit module de détermination étant configuré pour déterminer si une deuxième action de protection doit être exécutée par ledit dispositif de protection en fonction d’un niveau de détection d’anomalies associé audit dispositif de protection et d’au moins un niveau de consommation de ressource par ledit dispositif lors de l’exécution de ladite première action de protection ; et
    - un module (TX) d’envoi, activé le cas échéant, et configuré pour envoyer au dispositif de protection un ordre d’exécution de ladite deuxième action de protection.
12. Dispositif (2) de protection d’au moins un élément d’un réseau, ledit dispositif de protection comprenant :
    - un module (SURV) de surveillance, configuré pour exécuter au moins une première action de protection et pour signaler à une entité dite de commande du réseau une anomalie détectée concernant ledit au moins un élément du réseau ; et
    - un module (TRIG) de déclenchement, activé sur réception d’un ordre de ladite entité de commande, configuré pour déclencher une exécution par le module de surveillance d’une deuxième action de protection déterminée par l’entité de commande en fonction d’un niveau de détection d’anomalies associé audit dispositif de protection et d’au moins un niveau de consommation de ressource par ledit dispositif de protection lors de l’exécution de ladite première action de protection.
13. Entité d’un réseau d’accès d’un réseau comprenant une entité (3) de commande selon la revendication 11 ou un dispositif (2) de protection selon la revendication 12.
14. Entité (AMF, 4) d’un réseau cœur d’un réseau comprenant une entité (3) de commande selon la revendication 11 ou un dispositif (2) de protection selon la revendication 12.
15. Système de surveillance (1, AMF) d’un réseau (NW) comprenant :
    - au moins un dispositif (2) de protection d’au moins un élément du réseau selon la revendication 12 ; et
    - au moins une entité (3) de commande selon la revendication 11 ;
    dans lequel ledit au moins un élément du réseau comprend une fonction réseau virtuelle (AMF) hébergeant ledit dispositif de protection.
16. Système de surveillance (1) d’un réseau selon la revendication 15 dans lequel :
    - au moins un dit dispositif (L-IDS) de protection, dit premier dispositif de protection, est embarqué dans un équipement d’un réseau d’accès (RAN) audit réseau, et au moins un dit dispositif (G-IDS) de protection, dit deuxième dispositif de protection, est embarqué dans une fonction réseau (AMF) d’un réseau cœur (CN) dudit réseau ; et
    - une dite entité (3) de commande du premier dispositif de protection est embarquée dans ladite fonction réseau (AMF), et une dite entité de commande (3) du deuxième dispositif de protection est embarquée dans un centre (4) d’opérations de sécurité du réseau cœur.