FR3060164A1 - Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance. - Google Patents

Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance. Download PDF

Info

Publication number
FR3060164A1
FR3060164A1 FR1662319A FR1662319A FR3060164A1 FR 3060164 A1 FR3060164 A1 FR 3060164A1 FR 1662319 A FR1662319 A FR 1662319A FR 1662319 A FR1662319 A FR 1662319A FR 3060164 A1 FR3060164 A1 FR 3060164A1
Authority
FR
France
Prior art keywords
communicating
local
objects
network
category
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
FR1662319A
Other languages
English (en)
Other versions
FR3060164B1 (fr
Inventor
Benoit Meunier
Eric Bouvet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Orange SA filed Critical Orange SA
Priority to FR1662319A priority Critical patent/FR3060164B1/fr
Priority to PCT/FR2017/053339 priority patent/WO2018109304A1/fr
Publication of FR3060164A1 publication Critical patent/FR3060164A1/fr
Application granted granted Critical
Publication of FR3060164B1 publication Critical patent/FR3060164B1/fr
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/104—Grouping of entities
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L61/00—Network arrangements, protocols or services for addressing or naming
    • H04L61/50—Address allocation
    • H04L61/5007—Internet protocol [IP] addresses
    • H04L61/5014—Internet protocol [IP] addresses using dynamic host configuration protocol [DHCP] or bootstrap protocol [BOOTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/102—Entity profiles
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/10—Network architectures or network communication protocols for network security for controlling access to devices or network resources
    • H04L63/105—Multiple levels of security
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1433—Vulnerability analysis

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

L'invention concerne un procédé de gestion d'un réseau de communication local (401-403) comprenant une pluralité d'objets communicants (11-17 ; 21) aptes à être connectés au réseau et un serveur de configuration de paramètres d'accès des objets communicants au réseau. Un tel procédé comprend : - une surveillance (25) de données émises par les objets communicants ; - une affectation (27) d'un score de malveillance local aux objets communicants en - fonction d'un résultat de la surveillance ; - une classification des objets communicants dans une catégorie de confiance, en fonction d'une comparaison (28) du score de malveillance local et d'un seuil de confiance local associé à la catégorie de confiance.

Description

® RÉPUBLIQUE FRANÇAISE
INSTITUT NATIONAL DE LA PROPRIÉTÉ INDUSTRIELLE © N° de publication : 3 060 164 (à n’utiliser que pour les commandes de reproduction)
©) N° d’enregistrement national : 16 62319
COURBEVOIE © Int Cl8 : G 06 F21/57 (2017.01), G 06 F21/46, H 04 L 12/22
DEMANDE DE BREVET D'INVENTION A1
©) Date de dépôt : 12.12.16. ©) Priorité : ©) Demandeur(s) : ORANGE Société anonyme — FR.
@ Inventeur(s) : MEUNIER BENOIT et BOUVET ERIC.
©) Date de mise à la disposition du public de la demande : 15.06.18 Bulletin 18/24.
©) Liste des documents cités dans le rapport de recherche préliminaire : Se reporter à la fin du présent fascicule
(© Références à d’autres documents nationaux apparentés : ©) Titulaire(s) : ORANGE Société anonyme.
©) Demande(s) d’extension : ® Mandataire(s) : CABINET PATRICE VIDON.
GESTION D'UN RESEAU DE COMMUNICATION LOCAL PAR CLASSIFICATION D'OBJETS COMMUNICANTS EN CATEGORIES DE CONFIANCE, EN FONCTION D'UN SCORE DE MALVEILLANCE.
FR 3 060 164 - A1 (b7) L'invention concerne un procédé de gestion d'un réseau de communication local (40ί-40ο) comprenant une pluralité d'objets communicants (11-17; 21) aptes à être connectés au réseau et un serveur de configuration de paramètres d'accès des objets communicants au réseau. Un tel procédé comprend:
- une surveillance (25) de données émises par les objets communicants;
- une affectation (27) d'un score de malveillance local aux objets communicants en
- fonction d'un résultat de la surveillance ;
- une classification des objets communicants dans une catégorie de confiance, en fonction d'une comparaison (28) du score de malveillance local et d'un seuil de confiance local associé à la catégorie de confiance.
22 21
Gestion d'un réseau de communication local par classification d'objets communicants en catégories de confiance, en fonction d'un score de malveillance.
1. Domaine de l'invention
Le domaine de l'invention est celui des réseaux de communication locaux, notamment, mais non exclusivement, des réseaux de communication domestiques, comprenant une passerelle d'accès et une pluralité d'objets communicants, tels que des ordinateurs, tablettes, téléphones intelligents (en anglais « smartphones »), mais également des caméras de type webcams, des stations météo, des capteurs, des thermostats, etc.
Plus précisément, l'invention concerne la gestion d'une politique de sécurité au sein d'un tel réseau de communication local.
2. Art antérieur et ses inconvénients
Actuellement, lorsqu'un objet communicant est connecté dans un réseau de communication, et souhaite échanger des données sur ce réseau, il lui est nécessaire d'obtenir certains paramètres de configuration, et notamment une adresse IP (pour l'anglais « Internet Protocol »). Le protocole de configuration automatique le plus couramment utilisé pour ce faire est le protocole DHCP (pour l'anglais « Dynamic Host Configuration Protocol », protocole de configuration dynamique des hôtes).
Classiquement, l'objet communicant diffuse sur le réseau un datagramme DHCP DISCOVER. A réception, un serveur DHCP, présent par exemple dans la passerelle d'accès au réseau, envoie en réponse à l'objet communicant une offre DHCP OFFER, s'il est en mesure de proposer une adresse sur le réseau auquel appartient l'objet communicant. Une telle offre DHCP comporte l'adresse IP du serveur, ainsi que l'adresse IP et le masque de sous-réseau qu'il propose à l'objet communicant.
S'il retient cette offre, l'objet communicant diffuse sur le réseau un datagramme de requête DHCP (DHCP REQUEST), qui comporte l'adresse IP du serveur et celle qui vient de lui être proposée. Elle a pour effet, notamment, de demander au serveur DHCP l'assignation de cette adresse, et l'envoi éventuel des valeurs de certains paramètres.
Le serveur DHCP élabore un datagramme d'accusé de réception (DHCP ACK pour acknowledgement) qui assigne à l'objet communicant l'adresse IP et son masque de sous-réseau, la durée du bail de cette adresse, et éventuellement d'autres paramètres, parmi lesquels l'adresse IP de la passerelle par défaut, et les adresses IP des serveurs DNS.
Le serveur DHCP, qui est le plus souvent intégré dans la passerelle d'accès au réseau local (la passerelle résidentielle dans le cas d'un réseau domestique), alloue ainsi des paramètres de configuration, de même nature et de même portée, à tous les objets communicants du réseau qui en font la demande, leur permettant, d'une part, d'accéder aux ressources et données du réseau local, et d'autre part, d'accéder au réseau mondial Internet.
Si ceci posait peu de problèmes à la genèse des réseaux locaux, lorsque seuls un ou deux ordinateurs personnels de type PC étaient présents sur le réseau, la multiplication du nombre d'objets communicants, de tous types, et de toutes provenances, pose à cette approche des problèmes de sécurité.
En effet, le risque est accru que l'un de ces objets communicants présente une ou plusieurs failles de sécurité, susceptibles de permettre à un individu malveillant de pénétrer sur le réseau local, par exemple par installation sur l'objet communicant d'un logiciel malveillant (en anglais « malware »), en vue d'y opérer des activités malveillantes, telles que du vol de données, ou une attaque de déni de service par exemple.
L'ajout par un utilisateur d'un objet communicant sur un réseau de communication local, qu'il soit connecté en mode filaire par un câble Ethernet®, ou sans fil sur un réseau de type Wi-Fi en mode WPA2 (pour « Wi-Fi Protected Access 2 »), garantit, en règle générale, que cet objet communicant a été volontairement connecté par l'administrateur du réseau.
Cependant, cet administrateur ou utilisateur peut ne pas avoir connaissance de l'existence de failles de sécurité sur cet objet communicant, et ce d'autant plus que ces failles de sécurité sont associées à une version donnée de logiciel embarqué sur l'objet communicant. Ainsi, un objet a priori fiable peut cesser de l'être, suite à une mise à jour de son firmware (pour l'anglais « logiciel embarqué »), sans que l'utilisateur ne s'en rende compte.
Il existe donc un besoin d'une technique de gestion des réseaux de communication locaux qui ne présente pas ces inconvénients de l'art antérieur, et permettre d'accroître leur sécurité visà-vis d'objets communicants susceptibles de présenter une faille de sécurité.
3. Exposé de l'invention
L'invention répond à ce besoin en proposant un procédé de gestion d'un réseau de communication local comprenant une pluralité d'objets communicants aptes à être connectés audit réseau et un serveur de configuration de paramètres d'accès desdits objets communicants audit réseau.
Selon l'invention, un tel procédé comprend :
une surveillance de données émises par lesdits objets communicants ;
une affectation d'un score de malveillance local auxdits objets communicants en fonction d'un résultat de ladite surveillance ;
une classification desdits objets communicants dans une catégorie de confiance, en fonction d'une comparaison dudit score de malveillance local et d'un seuil de confiance local associé à ladite catégorie de confiance.
Ainsi, l'invention repose sur une approche nouvelle et inventive de la gestion de la sécurité des réseaux de communication locaux, et notamment des réseaux domestiques, auxquels accèdent de multiples objets communicants de fiabilités diverses.
En effet, l'invention propose de mettre en place une surveillance du trafic de données émis par les objets communicants présents sur un réseau local, que ce soit en interne au sein du réseau, ou vers un réseau de communication externe de type Internet auquel le réseau de communication local est relié par une passerelle d'accès. Une telle surveillance peut être effectuée par exemple par une sonde, qui peut être intégrée dans un routeur du réseau, tel que la passerelle résidentielle dans le cas d'un réseau domestique.
Une telle surveillance permet de détecter d'éventuels comportements douteux des objets communicants, et de leur affecter en conséquence un score de malveillance. En fonction de la valeur de ce score, il est alors possible de classer les objets communicants dans une catégorie de confiance adaptée. Le résultat de ce classement peut être mémorisé au sein du réseau de communication, par exemple dans une passerelle d'accès au réseau, afin d'être aisément accessible aux équipements du réseau local. Ainsi, par mise en place d'une simple surveillance des données échangées, il est possible de vérifier si l'objet communicant connecté au réseau est fiable, et ainsi d'accroître la sécurité du réseau.
Par objet communicant, on entend ici, et dans l'ensemble de ce document, aussi bien un objet physique apte à communiquer numériquement sur le réseau local, en vue d'un échange de données, qu'une application logicielle s'appuyant sur une machine virtuelle ou un container, associée à un objet physique.
Selon un mode de réalisation, la surveillance est apte à détecter au moins une activité malveillante d'un des objets communicants et/ou au moins une configuration à risque de l'objet communicant, et le score de malveillance local affecté est calculé par sommation de poids de malveillance associés à la ou les activité(s) malveillante(s) et/ou à la ou les configuration(s) à risque détectées.
Ainsi, pour accroître la sécurité du réseau local, on cherche à surveiller non seulement les activités malveillantes des objets communicants, mais aussi les potentielles failles de sécurité de ces objets, telles que des configurations de ces objets susceptibles de les rendre vulnérables à des attaques (par exemple, une absence de personnalisation de données d'identification telles que le login (identifiant d'ouverture de session) et le mot de passe, qui seraient maintenues dans leur configuration par défaut).
Un poids de malveillance peut être affecté à chaque activité malveillante potentiellement détectable, ou à chaque configuration à risque. Ces poids peuvent être paramétrés par défaut pour le réseau local. Ils peuvent aussi évoluer au cours du temps, par exemple en fonction de la fréquence de l'occurrence de l'activité détectée, en fonction d'un paramétrage spécifique réalisé par l'administrateur du réseau, ou encore en fonction d'informations reçues d'un fournisseur d'accès internet.
A la première connexion d'un objet communicant dans le réseau local, son score de malveillance est par exemple initialisé à zéro. A chaque nouvelle activité malveillante ou configuration à risque détectée, ce score de malveillance est incrémenté du poids de l'activité ou de la configuration détectée. Au fur et à mesure de l'augmentation de ce score de malveillance, il franchit certains seuils de confiance, qui font basculer l'objet communicant d'une catégorie de confiance à une autre.
En effet, selon un mode de réalisation, la catégorie de confiance appartient à un ensemble d'au moins deux catégories de confiance, comprenant :
une catégorie d'objets communicants de confiance ; une catégorie d'objets communicants non fiables.
Par exemple, un objet communicant peut appartenir à une catégorie d'objets de confiance, mais basculer dans la catégorie des objets non fiables, dès que son score de malveillance atteint un certain niveau. Ainsi, par simple surveillance du trafic échangé par un objet communicant, on peut mettre en évidence un comportement malveillant, et ainsi classer un objet communicant a priori de confiance, et perçu comme tel par l'administrateur du réseau, dans une catégorie d'objets communicants non fiables. On accroît ainsi la sécurité du réseau de communication par rapport aux techniques antérieures.
Selon un mode de réalisation, l'ensemble d'au moins deux catégories de confiance comprend également au moins une catégorie d'objets communicants insuffisamment fiables.
Une telle catégorie peut être assimilée à une catégorie d'objets communicants « en quarantaine », qui nécessitent par exemple de subir une mise à jour de leur logiciel embarqué (en anglais « firmware ») pour y corriger une faille de sécurité récemment détectée ou une opération de maintenance (par exemple une mise à jour des paramètres d'identification, tels qu'un mot de passe).
En effet, un tel score de malveillance est associé à un objet communicant et à la version du logiciel qu'il embarque. Une mise à jour de ce logiciel embarqué peut entraîner une remise à zéro du score de malveillance associé, ou une décrémentation de ce score d'un poids prédéterminé, en fonction de la nature et de l'importance de la mise à jour.
Une telle catégorie d'objets insuffisamment fiables peut être associée à un score de malveillance de niveau intermédiaire.
Ainsi, un objet communicant de la catégorie des objets communicants de confiance peut être classé dans la catégorie des objets communicants insuffisamment fiables, lorsque le score de malveillance qui lui est associé franchit le seuil intermédiaire associé à la catégorie des objets communicants insuffisamment fiables. Ce score de malveillance intermédiaire peut être atteint lorsqu'on détecte qu'une mise à jour du firmware ou une opération de maintenance est nécessaire. Dès que la mise à jour ou l'opération de maintenance est effectuée, le score de malveillance peut être réinitialisé à zéro, et l'objet communicant peut réintégrer la catégorie des objets communicants de confiance.
Selon un mode de réalisation, un tel procédé comprend une adaptation d'une offre d'accès à des ressources dudit réseau par lesdits objets communicants, en fonction de ladite catégorie de confiance dans laquelle ils sont classés.
Il est ainsi possible d'allouer des droits d'accès différents aux objets communicants, en fonction de la catégorie de confiance à laquelle ils appartiennent. Notamment, il est possible de mettre en place plusieurs sous-réseaux, présentant des politiques de sécurité différentes, au sein du réseau de communication local.
Par exemple, les équipements appartenant à la catégorie des objets communicants non fiables peuvent avoir des droits d'accès restreints par rapport aux objets communicants de confiance, et être cloisonnés dans un sous-réseau, sans possibilité d'accéder au reste du réseau de communication local : on réduit ainsi leur pouvoir de nuisance, et on évite leur accès à des données sensibles ou protégées (pas de possibilité pour l'objet potentiellement malveillant de « sniffer » le réseau local).
De même, un équipement appartenant à la catégorie des objets communicants insuffisamment fiables peut par exemple se voir refuser tout droit d'accès au réseau de communication local tant qu'il n'a pas procédé à une mise à jour requise de son logiciel embarqué. En variante, si cette mise à jour doit viser à corriger une faille de sécurité détectée sur l'un de ses ports de communication, il est aussi possible de bloquer ce port jusqu'à ce que la mise à jour ait été effectuée.
Selon un mode de réalisation, un tel procédé comprend une transmission du score de malveillance local affecté à un des objets communicants à un serveur de certification de l'objet communicant.
En effet, si la classification des objets communicants en catégories de confiance est très importante au niveau du réseau local, en ce qu'elle permet d'en accroître la sécurité en adaptant les droits d'accès des objets aux ressources du réseau, en fonction de la confiance qui leur est accordée, elle présente également un intérêt important au niveau global, à l'échelle d'un fournisseur d'accès internet par exemple.
Ainsi, une activité a priori peu malveillante, associée à un poids de malveillance relativement faible, peu sembler anodine, de façon isolée, à l'échelle d'un réseau de communication local. En revanche, lorsqu'un opérateur de réseau, ou un fournisseur d'accès internet, reçoit, au niveau d'un serveur de certification d'objets communicants, une information, sous la forme de scores de malveillance en provenance d'une multitude de réseaux de communication locaux, selon laquelle cette activité malveillante a priori peu dangereuse est en fait fréquente et se produit dans de nombreux réseaux locaux, il est en mesure de mieux évaluer les risques encourus, et d'identifier cette activité comme effectivement dangereuse.
Ainsi, en corollaire de ce procédé de gestion d'un réseau de communication local, un mode de réalisation de la présente invention concerne également un procédé de certification d'au moins un objet communicant, apte à être connecté à des réseaux de communication locaux, par l'intermédiaire de serveurs de configuration de paramètres d'accès dudit objet communicant auxdits réseaux locaux. Un tel procédé de certification comprend :
une réception, en provenance d'au moins un des réseaux de communication locaux, d'au moins un score de malveillance local affecté à l'objet communicant au niveau du ou des réseau(s) local(aux) ;
une affectation d'un niveau de confiance global à l'objet communicant en fonction du ou des score(s) de malveillance local(aux) reçu(s) ;
une transmission aux serveurs de configuration de paramètres d'accès d'une requête de classification de l'objet communicant dans une catégorie de confiance, en fonction d'une comparaison du niveau de confiance global et d'un seuil de confiance global associé à la catégorie de confiance.
En d'autres termes, lorsqu'un serveur de certification d'objets communicants reçoit, pour un même type d'objets communicants (par exemple une tablette d'une certaine marque, équipée d'une certaine version de logiciel embarqué), une multiplicité de scores de malveillance, en provenance d'une multiplicité de réseaux locaux, qui reflètent tous une activité malveillante détectée, il peut en déduire un niveau de confiance global à affecter à ce type d'objet communicant et sa version de firmware. Ce niveau de confiance peut être par exemple simplement obtenu par sommation des scores de malveillance locaux reçus en provenance des réseaux locaux. Il peut également être calculé en appliquant un coefficient multiplicatif à la somme des scores de malveillance, en fonction de la fréquence de détection d'une activité malveillante sur ce type d'objet communicant. D'autres modes de détermination sont bien sûr également envisageables. Notamment ce niveau de confiance peut être inversement proportionnel à une somme pondérée des scores de malveillance par exemple.
Quelle que soit la méthode employée pour déterminer ce niveau de confiance global, l'esprit de cette caractéristique est de permettre au serveur de certification d'objets communicants d'alerter les serveurs de configuration de paramètres d'accès (par exemple, les serveurs DHCP ou les passerelles résidentielles qui les intègrent) des réseaux de communication locaux qu'un objet communicant doit changer de catégorie de confiance, au niveau du réseau local.
Par exemple, un objet communicant peut être classé, au niveau d'un ensemble de réseaux locaux, dans la catégorie des objets communicants de confiance, car le score de malveillance qui lui est associé est relativement faible. Cependant, la vision globale dont dispose l'opérateur ou le fournisseur d'accès, en charge de ce serveur de certification, lui permet d'identifier, au vu de la fréquence des activités malveillantes détectées sur un ensemble d'objets communicants d'un même type et d'une même version de firmware, qu'il existe un risque de sécurité, sur tous ces objets. Il envoie alors une information aux serveurs de configuration de paramètres d'accès de cet ensemble de réseaux locaux, pour requérir la classification de cet objet dans la catégorie des objets non fiables.
On accroît ainsi encore la sécurité de ces réseaux de communication locaux, par mutualisation de la connaissance des scores de malveillance locaux affectés aux objets dans chacun des réseaux locaux.
Un mode de réalisation de la présente invention concerne également un produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de gestion d'un réseau de communication local, ou d'un procédé de certification d'objets communicants, tels que décrits précédemment, lorsqu'il est exécuté par un processeur.
Un mode de réalisation de la présente invention vise également un support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de gestion d'un réseau de communication local selon l'invention tel que décrit ci-dessous, ou du procédé de certification d'objets communicants selon l'invention tel que décrit ci-dessus.
Un tel support d'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. 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 une clé USB ou un disque dur.
D'autre part, un tel support 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 radio ou par d'autres moyens, de sorte que le programme d'ordinateur qu'il contient est exécutable à distance. Le programme selon l'invention peut être en particulier téléchargé sur un réseau par exemple le réseau Internet.
Alternativement, le support d'enregistrement peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de contrôle d'affichage précité.
L'invention concerne également un serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, et une passerelle d'accès à un réseau de communication présentant en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document en relation avec le procédé de gestion d'un réseau de communication local.
Notamment, un tel serveur de configuration comprend un processeur apte à mettre en oeuvre le procédé décrit précédemment, et la passerelle d'accès, par exemple une passerelle résidentielle de type Livebox®, intègre un serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, par exemple un serveur DHCP.
Le serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, la passerelle d'accès et le programme d'ordinateur correspondants précités présentent au moins les mêmes avantages que ceux conférés par le procédé de gestion d'un réseau de communication local selon la présente invention.
En outre, dans un mode de réalisation, l'invention concerne également un serveur de certification d'au moins un objet communicant présentant en combinaison tout ou partie des caractéristiques exposées dans l'ensemble de ce document en relation avec le procédé de certification d'objets communicants décrit ci-avant. Notamment, un tel serveur de certification comprend un processeur apte à mettre en oeuvre le procédé de certification d'objets communicants décrit précédemment.
4. Liste des figures
D'autres buts, caractéristiques et avantages de l'invention apparaîtront plus clairement à la lecture de la description suivante, donnée à titre de simple exemple illustratif, et non limitatif, en relation avec les figures, parmi lesquelles :
la figure 1 présente une vue schématique d'un réseau local de communication et des différents objets communicants qui y sont connectés, selon un mode de réalisation de l'invention;
la figure 2 présente sous forme de logigramme les différentes étapes du procédé de gestion selon un mode de réalisation de l'invention;
la figure 3 propose un schéma synoptique d'un serveur DHCP ou d'une passerelle d'accès mettant en oeuvre le procédé de la figure 2 ;
la figure 4 présente sous forme de logigramme les différentes étapes du procédé de certification d'objets communicants selon un mode de réalisation de l'invention;
la figure 5 propose un schéma synoptique d'un serveur de certification d'objets communicants mettant en oeuvre le procédé de la figure 4.
5. Description détaillée de modes de réalisation de l'invention
Le principe général de l'invention repose sur la classification, en différentes catégories de confiance, des objets communicants susceptibles d'être connectés dans un réseau de communication local, en fonction d'un score de malveillance qui leur est affecté, résultant d'une surveillance des données qu'ils échangent sur le réseau.
On s'attache plus en détail dans la suite de ce document à décrire la mise en oeuvre d'un mode de réalisation de l'invention dans le cadre d'un réseau domestique, chez un utilisateur particulier. L'invention s'applique bien sûr également à tout autre type de réseau de communication local (LAN, pour « Local Area Network »), auquel une pluralité d'équipements de communication sont connectés.
Dans un tel réseau domestique, représenté schématiquement sur la figure 1, une passerelle résidentielle HGW référencée 10 permet de relier un réseau de communication local et un réseau étendu tel que le réseau Internet (non représenté). Une telle passerelle résidentielle HGW 10 intègre un serveur DHCP : elle effectue le routage des paquets de données sur le réseau, et peut également jouer le rôle de pare-feu, de proxy, de relais DNS (pour l'anglais « Domain Name Server»), de fournisseur de services IGD (pour l'anglais «Internet Gateway Device», dispositif de passerelle Internet)...
Le serveur DHCP peut bien sûr également être dissocié de la passerelle résidentielle HGW 10, dans un autre mode de réalisation.
Dans l'exemple de la figure 1, de nombreux équipements sont présents sur le réseau local, à savoir :
un téléphone intelligent (ou « smartphone ») 11 ;
un ordinateur portable 12 ;
un ordinateur de type PC 13 ;
une tablette 14 ;
une station météo 15 ;
une webcam 16 ;
un thermostat 17.
Cette liste n'est bien sûr pas exhaustive, et de nombreux autres objets communicants peuvent être présents sur le réseau local de l'utilisateur.
Ces objets communicants peuvent être reliés au réseau par voie filaire (câble Ethernet, port USB (pour l'anglais « Universal Serial Bus »)...) ou sans fil (Wi-Fi®, Bluetooth®, ZigBee). Ils comprennent tous types d'objets physiques, aptes à communiquer numériquement sur le réseau local, en vue d'un échange de données. Ils comprennent également les applications logicielles associées à certains objets connectés non IP (« Internet Protocol »), fonctionnant sur des technologies sans fil tels que BLE (pour « Bluetooth® Low Energy »), Z-wave®, Thread®, etc.
En effet, l'utilisation de tels objets communicants requiert le plus souvent l'installation d'une application de gestion sur une passerelle d'accès au réseau de communication local. Une telle application s'appuie sur une machine virtuelle, ou un conteneur, à qui le serveur de configuration de paramètres d'accès (serveur DHCP) fournit une adresse IP. De tels objets communicants qui ne sont pas naturellement compatibles avec le protocole IP nécessitent la mise en oeuvre d'une passerelle loT vers IP et/ou du protocole « 6LowPan ».
Ainsi, dans la suite, on désigne par objet communicant, aussi bien les objets physiques connectés au réseau que les applications logicielles « virtualisées » associées à certains de ces objets.
De tels objets communicants peuvent être désignés par l'acronyme loT, pour l'anglais « Internet of Things », en français « Internet des objets ».
Parmi les objets communicants de la figure 1, on peut imaginer que le téléphone intelligent 11 et la tablette 14 aient été fournis à l'utilisateur par un Fournisseur d'Accès Internet (FAI), qui a également fourni à l'utilisateur l'équipement de terminaison de réseau que constitue la passerelle résidentielle HGW 10. De ce fait, le fournisseur d'accès connaît ces équipements 11, 14, et peut en garantir la fiabilité. A l'inverse, d'autres objets communicants comme la webcam 16 ou la station météo 15 peuvent provenir d'autres sources et d'autres provenances : le fournisseur d'accès ne dispose a priori d'aucun contrôle sur l'existence de potentielles failles de sécurité sur ces objets communicants, ni sur la possibilité de procéder à une mise à jour des logiciels qu'ils embarquent (« firmware »), en cas de détection d'une éventuelle faille de sécurité.
II est donc important de pouvoir classer ces différents objets communicants référencés 11 à 17 dans des catégories de confiance appropriées, afin notamment d'adapter les droits alloués à ces différents objets par le serveur DHCP embarqué dans la passerelle résidentielle HGW 10, et ce, afin d'améliorer la sécurité du réseau local vis-à-vis d'éventuelles attaques malveillantes.
Pour ce faire, un mode de réalisation de l'invention repose sur le logigramme de la figure
2.
Un objet communicant loT 21 (par exemple l'ordinateur portable 12 de la figure 1), présent sur le réseau domestique, est dépourvu d'adresse IP, mais souhaite accéder aux ressources du réseau, ou au réseau Internet. Selon le mécanisme connu associé au protocole de configuration dynamique d'hôtes DHCP, il envoie alors une requête DHCP 23 aux serveurs DHCP présents sur le réseau local.
Dans l'exemple du réseau de la figure 1, un unique serveur DHCP est présent sur le réseau local, par exemple intégré dans la passerelle résidentielle HGW 10. A l'issue d'un échange de datagrammes DHCP entre l'objet communicant 21 et le serveur DHCP intégré dans la passerelle résidentielle HGW 10, ce dernier envoie à l'objet communicant 21 un datagramme d'affectation d'adresse IP DHCPpack 24i qui assigne au client 21 l'adresse IP et son masque de sous-réseau, la durée du bail de cette adresse, et éventuellement d'autres paramètres, tels que l'adresse IP de la passerelle 10, et les adresses IP des serveurs DNS (pour « Domain Name Server »).
En l'espèce, l'adresse IP indiquée dans le datagramme 24i DHCPpack(IPTRUsT), correspond à une adresse IP d'un sous-réseau réservé aux objets communicants de confiance, qui offre à ces derniers des droits et un accès étendus aux ressources du réseau local.
En effet, selon un premier mode de réalisation, on considère que, par défaut, tous les objets communicants sont, lors de leur première connexion au réseau de communication local, classés dans la catégorie des objets communicants de confiance.
Selon une variante, qui fait l'objet d'une demande de brevet français déposée le même jour que la présente demande de brevet, par le même demandeur, cette classification dans la catégorie des objets communicants de confiance, résulte d'une authentification de l'objet communicant 21 auprès du serveur DHCP, par exemple au moyen du certificat C.
Ainsi, les échanges de requête DHCP 23 et de réponse 24i comprennent en fait les étapes suivantes, non représentées sur la figure 2, par souci de simplification :
l'objet communicant loT 21 envoie en mode de diffusion (« broadcast ») un datagramme DHCP DISCOVER qui s'adresse aux serveurs DHCP présents sur le réseau local. Ce datagramme comporte notamment l'adresse physique (MAC pour Media Access Control) de l'IoT 21 ; s'il est en mesure de proposer une adresse sur le réseau local, le serveur DHCP intégré dans la passerelle HGW 10 envoie alors une offre DHCP (DHCP OFFER) à l'attention de l'objet communicant loT 21, identifié par son adresse physique. Cette offre comporte l'adresse IP du serveur 10, ainsi que l'adresse IP et le masque de sous-réseau qu'il propose à l'IoT 21. Elle comprend également un challenge, par exemple sous la forme d'une chaîne unique aléatoire, que l'objet communicant 21 va devoir signer au moyen d'une clé privée de certification KPR, s'il dispose d'une telle clé. Un tel challenge est par exemple inséré par le serveur 10 dans un champ d'option du protocole DHCP ;
à réception, si l'objet communicant loT 21 dispose d'une clé privée de certification KPR, il diffuse sur le réseau un datagramme de requête DHCP (DHCP REQUEST), auquel il a ajouté un drapeau (en anglais « flag ») d'acceptation du challenge. Ce datagramme comporte l'adresse IP du serveur 10 et celle qui vient d'être proposée à l'objet communicant loT 21. Elle a pour effet de demander au serveur 10, l'assignation de cette adresse et l'envoi éventuel des valeurs de certains paramètres ; l'objet communicant loT 21 envoie ensuite au serveur 10 la résolution du challenge qui lui a été adressé. Cette résolution correspond à la chaîne aléatoire reçue signée par ΙΊοΤ 21 au moyen de la clé privée KPR; à réception, le serveur 10 vérifie cette signature au moyen de la clé publique KPU, associée à l'objet communicant loT 21, et à la version du logiciel qu'il embarque. Cette clé publique KPU est par exemple mémorisée dans la passerelle résidentielle HGW 10, en association avec un identifiant de l'objet communicant loT 21, et un identifiant d'une version de firmware ;
après vérification par le serveur DHCP 10 que la résolution du challenge est exacte, ce dernier élabore un datagramme d'accusé de réception 24i (DHCP PACK(IPtrust)} qui assigne au client 21 l'adresse IP et son masque de sous-réseau, la durée du bail de cette adresse, et éventuellement d'autres paramètres, tels que l'adresse IP de la passerelle 10, et les adresses IP des serveurs DNS (pour « Domain Name Server »). En l'espèce, l'adresse IP indiquée dans le datagramme 24i (DHCP PACK(IPTRUST)), correspond à une adresse IP du sous-réseau des objets communicants de confiance, qui offre à ces derniers des droits et un accès étendus aux ressources du réseau local.
En cas d'absence de clé privée de certification, ou si cette clé de certification a été révoquée, l'authentification de l'objet communicant 21 échoue, et l'objet communicant n'est alors pas classé dans la catégorie des objets communicants de confiance, mais dans une autre catégorie, telle que par exemple la catégorie des objets non fiables ou insuffisamment fiables ou...
On se place dans la suite dans l'hypothèse d'un objet communicant loT 21 qui a été classé dans la catégorie des objets communicants de confiance, soit par défaut, soit à l'issue d'un mécanisme d'authentification, par exemple à base de certificat C, comme décrit ci-dessus.
Une sonde S référencée 22 surveille les différents trafics au sein du réseau de la figure 1, tant de l'intérieur du réseau local vers le réseau externe situé au-delà de la passerelle résidentielle HGW 10, qu'en interne au sein de ce réseau local, par exemple entre objets communicants. Une telle sonde S 22 est par exemple intégrée dans un routeur du réseau, par exemple au sein de la passerelle résidentielle HGW 10. Pour assurer une surveillance efficace, il est souhaitable que la sonde S 22 soit présente sur chaque interface physique de la passerelle résidentielle HGW 10 (ETHO, ETH1, Wi-Fi-AP0, etc.)
Bien sûr, la sonde peut être disposée en tout autre point du réseau, dès lors qu'elle peut intercepter tout trafic au sein du réseau, et échanger avec le serveur de configuration DHCP.
Une telle sonde S 22 surveille ainsi les données échangées par l'objet communicant 21, et inclut plusieurs mécanismes de détection d'activités malveillantes, parmi lesquelles :
l'usurpation d'adresse IP par « ARP spoofing » (pour l'anglais « parodie d'ARP », où le sigle
ARP désigne le protocole « Address Resolution Protocol »), qui permet à un attaquant de détourner des flux de communication transitant entre un équipement cible et une passerelle, afin d'écouter, modifier, ou encore bloquer certains paquets réseaux ; la saturation par SYN flood (attaque informatique visant à atteindre un déni de service, qui s'applique dans le cadre du protocole TCP et consiste à envoyer une succession de requêtes SYN (pour « Synchronize ») vers la cible ;
l'accès à des URL (pour l'anglais « Uniform Resource Locator », en français « localisateur uniforme de ressource ») internet classifiés comme malveillants ;
le scan des ports par SYN/ACK (portsentry), qui concsiste à envoyer des paquets IP forgés de manière à trouver des ports ouverts sur la cible du scan sans ouvrir une session TCP complète ;
la détection d'attaque sur service WEB, consistant à sniffer les requêtes http de manière à détecter une attaque sur l'authentification (« bruteforce ») ou l'injection de commandes automatisées (CRLF pour « Carriage Return Line Feed », retour chariot saut de ligne) ; la détection de tentative de login SSH (pour « Secure Shell »), de manière à détecter les tentatives de connexion trop rapides qui pourraient signifier une attaque de type « bruteforce » (consistant à essayer tous les mots de passe possibles un à un) ;
l'audit de l'objet communicant loT 21 pour vérifier l'exposition des ports d'écoute, c'est-àdire scanner les services ouverts en analysant la réponse sur l'IoT de manière à identifier la version du service et vérifier si cette version ne contient pas une faille de sécurité.
A détection d'une tentative d'attaque ATT. ou d'une activité malveillante 25, la sonde S 22 incrémente ΊΊ un score de malveillance SC|Ot,c associé à l'objet communicant 21, et, le cas échéant, au certificat C qu'il a utilisé pour s'authentifier, ou à la version de son firmware.
A l'initialisation du système, par exemple lors de la première affectation d'une adresse IP par le serveur DHCP à l'objet communicant loT 21 au sein du réseau local, le score de malveillance est initialisé à zéro : SC|Ot,c=0.
Chaque activité malveillante, ou chaque configuration à risque de l'objet communicant 21 se voit affecter un poids de malveillance. Ce poids peut être proposé comme configuration par défaut par le fournisseur d'accès internet, et être mémorisé dans la sonde S 22 ou dans la passerelle résidentielle HGW 10. II peut également être mis à jour ou adapté aux particularités du réseau local et des objets communicants qui y sont connectés par l'administrateur de ce réseau. Comme on le verra par la suite, ces poids peuvent également être modifiés par le fournisseur d'accès internet ou l'opérateur, en fonction de données globales relatives aux activités malveillantes collectées dans une pluralité de réseaux locaux.
Ainsi, si la sonde S 22 détecte par exemple, lors de l'étape référencée 25, que l'objet communicant loT 21 présente une configuration à risque, parce que son utilisateur a maintenu ses paramètres de configuration (identifiant d'accès et mot de passe) par défaut et a omis de les personnaliser, il lui affecte un score de malveillance, par exemple SC|Ot,c=10.
En effet, cette configuration par défaut peut constituer une faille de sécurité, en ce sens qu'un individu malveillant peut aisément se connecter à l'objet communicant loT 21 pour en prendre le contrôle.
De même, si la sonde S 22 détecte par exemple, lors de l'étape référencée 25, que l'objet communicant loT 21 tente d'accéder à des URL (pour l'anglais « Uniform Resource Locator », en français « localisateur uniforme de ressource ») internet classifiés comme malveillants, il lui affecte un score de malveillance, par exemple SC|oT,c=50, si cette activité est considérée comme potentiellement plus dangereuse que la configuration à risque évoquée ci-dessus.
Sur détection d'une activité malveillante ou assimilée 25, la sonde S 22 peut adresser à l'objet communicant loT 21 une requête d'audit AUDIT REQ. 26, visant à vérifier la version du logiciel embarqué sur l'objet communicant loT 21, et le cas échéant à lui proposer une opération de mise à jour de son firmware, ou de maintenance (modification des login/mot de passe dans l'exemple ci-dessus).
Si la sonde S22 détecte d'abord une configuration à risque de l'objet communicant loT 21, qui fait passer son score de malveillance à SC|oT,c=10, puis une tentative d'accès à des URL malveillantes, associées à un poids de malveillance de 50, il incrémenté le score de malveillance à SC|oT,c=10+50=60 (étape référencée 27).
Au fur et à mesure de ces incrémentations, la sonde S 22 compare le score de malveillance local affecté à l'objet communicant loT 21 à un ou plusieurs seuils de confiance locaux TH, au cours d'une étape référencé 28.
Par exemple, la catégorie des objets communicants de confiance est réservée aux objets communicants dont le score de malveillance est inférieur à TH=10; la catégorie des objets communicants non fiables regroupe tous les objets communicants présentant un score de malveillance supérieur à un seuil de confiance local TH=50 ; les objets communicants dont le score de malveillance est compris entre TH= 10 et TH= 50 sont classés dans la catégorie des objets communicants insuffisamment fiables, qui doivent par exemple être mis en quarantaine, dans l'attente d'une mise à jour de leur logiciel embarqué.
Lorsque, lors de l'étape de comparaison 28, la sonde S 22 détecte que le score de malveillance de l'objet communicant loT 21 a franchi le seuil de confiance local TH= 50 associé à la catégorie des objets communicants non fiables, elle en informe, au cours d'une étape référencée 29, le serveur DHCP intégré dans la passerelle résidentielle HGW 10. Cette information peut prendre la forme d'une requête de révocation du certificat C (REQ. (loT, C)) associé à l'objet communicant 21 et à la version de son logiciel embarqué, qui devra par exemple intervenir à l'occasion du prochain renouvellement de bail DHCP.
A réception, la passerelle résidentielle HGW 10 met à jour les données de classification en catégorie de confiance précédemment mémorisées pour l'objet communicant loT 21, pour enregistrer le basculement de ce dernier dans la catégorie des objets communicants non fiables.
Lorsque l'objet communicant loT 21 demande le renouvellement 30 de son bail DHCP (DHCPiease(C)), le serveur DHCP de la passerelle résidentielle HGW 10 assigne au client 21 une nouvelle adresse IP dans un datagramme 242 (DHCP PACK(IPUNTrust.)}, qui correspond cette fois à une adresse IP du sous-réseau des objets communicants non fiables, qui offre à ces derniers des droits d'accès restreints aux ressources du réseau local. Par exemple, l'accès est limité au réseau étendu internet, sans possibilité d'accéder aux ressources internes du réseau local, et aux autres objets communicants du réseau local.
En variante, la requête de révocation 29 peut forcer sans délai le renouvellement du bail DHCP de l'objet communicant 21, pour le basculer plus rapidement dans la catégorie des objets communicants non fiables, sans attendre l'échéance naturelle de la demande de renouvellement 30 du bail DHCP.
Ainsi, la sécurité du réseau local est accrue, grâce à la détection, par la sonde S 22, d'activités potentiellement malveillantes des objets communicants 21, à la classification qui en découle de ces objets communicants en catégories de confiance, et au contrôle de l'accès au réseau conséquent pour ces objets 21.
On peut en effet proposer que le serveur DHCP et la passerelle résidentielle HGW 10 opèrent les restrictions d'accès suivantes pour les objets communicants de la catégorie des objets non fiables :
limiter le routage vers les autres équipements du réseau local ;
limiter l'accès internet de ces objets communicants 21 avec un relais DNS limité à une liste blanche de noms de domaines ;
limiter l'accès internet avec filtrage des ports TCP/UDP (pour « Transmission Control Protocol/ User Datagram Protocol ») ; interdire l'accès aux services de configuration, tels que par exemple UPnPIGD (pour « Universal Plug and Play - Internet Gateway Device »).
Les scores de malveillance des objets communicants loT 21 peuvent être réinitialisés à zéro, par exemple après mise à jour de leur logiciel embarqué, ou à l'issue d'une phase d'authentification réussie auprès du serveur DHCP (comme décrit ci-avant à titre de variante des étapes 23 et 24i de la figure 2).
On présente désormais, en relation avec la figure 3, la structure matérielle d'une passerelle résidentielle HGW 10 selon un mode de réalisation de l'invention, dans lequel le serveur DHCP et la sonde S 22 sont tous deux intégrés dans la passerelle.
Le terme sonde peut correspondre aussi bien à un composant logiciel qu'à un composant matériel ou un ensemble de composants matériels et logiciels, un composant logiciel correspondant lui-même à un ou plusieurs programmes ou sous-programmes d'ordinateur ou de manière plus générale à tout élément d'un programme apte à mettre en oeuvre une fonction ou un ensemble de fonctions.
Plus généralement, une telle passerelle résidentielle HGW comprend une mémoire vive 33 (par exemple une mémoire RAM), une unité de traitement 32 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur, représentatif de la sonde de surveillance S 22, stocké dans une mémoire morte 31 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 33 avant d'être exécutées par le processeur de l'unité de traitement 32. La mémoire vive 33 contient notamment une table de mémorisation des scores de malveillance affectés aux différents objets communicants 21 du réseau local, ainsi que la catégorie de confiance dans laquelle ils sont classés. Le processeur de l'unité de traitement 32 pilote un calculateur de scores de malveillance, un comparateur de ces scores aux seuils de confiance locaux associés aux différentes catégories de confiance, ainsi que la génération de requêtes de révocation de certificats vers le serveur DHCP conformément au logigramme de la figure 2.
La figure 3 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser la passerelle résidentielle HGW, afin qu'elle effectue les étapes du procédé détaillé cidessus, en relation avec la figure 2 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où la passerelle résidentielle HGW est réalisée avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CDROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.
Les différents modes de réalisation ont été décrits ci-avant en relation avec une passerelle résidentielle de type Livebox®, mais peuvent plus généralement être mis en oeuvre dans toutes les passerelles ou routeurs...
On présente désormais, en relation avec les figures 4 et 5, un mode de réalisation du procédé et du serveur de certification d'objets communicants selon la présente invention.
En effet, on s'est attaché ci-avant à décrire en détail le principe de la classification d'objets communicants en catégories de confiance au sein d'un unique réseau local. Cependant, le résultat de cette classification locale peut être avantageusement transmis à un serveur de certification d'objets communicants, géré par exemple par l'opérateur ou le fournisseur d'accès au réseau étendu internet auquel est relié le réseau local par l'intermédiaire de la passerelle HGW
10.
On considère ainsi plusieurs réseaux locaux référencés 40i, 402 et 403 similaires à celui décrit précédemment en relation avec la figure 1. Chacun de ces réseaux locaux 40i à 403 met en oeuvre le procédé de gestion décrit ci-avant en relation avec le logigramme de la figure 2, et calcule les scores de malveillance des objets communicants 21 qui lui sont connectés, sur la base d'une surveillance des données qu'ils échangent.
Ces scores sont transmis par la passerelle résidentielle HGW 10 à un serveur de certification d'objets communicants, par exemple à échéances régulières, ou à chaque modification d'un score de malveillance d'un objet communicant loT 21. Ainsi, au cours d'une étape référencée 41, le serveur de certification reçoit, en provenance des différents réseaux locaux 40i à 403, les scores de malveillance locaux d'un objet communicant loT 21, associé à un certificat C (RX(SCioTC))·
Sur la base de ces différents scores de malveillance locaux, le serveur de certification peut déterminer, pour cet objet communicant 21 doté d'un certificat C (par exemple la webcam 16, équipé de la version de logiciel embarqué 4.3), un niveau de confiance global NIV|oT,c 42, inversement proportionnel aux scores de malveillance locaux. Ce niveau de confiance global NIV|ot,c 42 peut être par exemple calculé comme l'inverse de la somme des scores de malveillance locaux reçus des différents réseaux locaux 40i à 403, ou l'inverse d'une sommation pondérée, ou encore en appliquant à cette somme un coefficient multiplicatif proportionnel au nombre de réseaux de communication locaux ayant remonté un score de malveillance non nul pour cet objet.
En effet, une activité a priori peu malveillante, donc associée à un poids de malveillance relativement faible, peut s'avérer dangereuse si elle est répétée de manière fréquente dans une pluralité de réseaux locaux.
Au cours d'une étape référencée 43, le serveur de certification compare le niveau de confiance global NIV|oT,c 42 qu'il a déterminé pour l'objet communicant 21, sur la base des scores locaux remontés par les réseaux locaux 40i à 403 à un ou plusieurs seuils de confiance global(aux) THconf/ associés, au niveau global de l'opérateur ou du fournisseur d'accès internet, aux différentes catégories de confiance.
Si le niveau de confiance global NIV|oT,c 42 pour l'objet communicant 21 reste supérieur ou égal au seuil de confiance global associé à la catégorie des objets communicants de confiance, le serveur de certification n'entreprend aucune démarche. Il continue à traiter les scores de malveillance reçus des différents réseaux locaux, et à mettre à jour le niveau de confiance global NIV|qt,c 42 de l'objet communicant 21.
Si en revanche le niveau de confiance global NIV|Ot,c 42 pour l'objet communicant 21 devient inférieur au seuil de confiance global THConf associé à la catégorie des objets communicants de confiance, le serveur de certification transmet (étape référencée 44) aux passerelles résidentielles HGW 10 des différents réseaux locaux 40i à 403 une requête de classification de l'objet communicant loT 21 dans la catégorie des objets communicants non fiables (ou insuffisamment fiables, en fonction du niveau de confiance global de cet objet).
Une telle requête 44 peut consister en une requête de révocation du certificat C associé à l'objet communicant 21, similaire à la requête REQ (loT, C) transmise par la sonde S 22 à la passerelle au cours de l'étape référencée 29 de la figure 2.
Ainsi, à réception, la passerelle résidentielle HGW 10i à 103 de chacun des réseaux locaux 40i à 403 met à jour les données de classification en catégorie de confiance précédemment mémorisées pour l'objet communicant loT 21, pour enregistrer le basculement de ce dernier dans la catégorie des objets communicants non fiables. Au prochain renouvellement de bail DHCP (soit forcé, soit à échéance classique), le serveur DHCP de la passerelle résidentielle HGW 10i à 103 assigne au client 21 une nouvelle adresse IP (DHCP PACK(IPUNTrust.)}, qui correspond à une adresse IP du sous-réseau des objets communicants non fiables, qui offre à ces derniers des droits d'accès restreints aux ressources du réseau local.
Une telle requête 44 de basculement d'un objet communicant dans la catégorie des objets communicants non fiables est de préférence envoyée par le serveur de certification à tous les réseaux locaux avec lesquels il est en communication, y compris ceux qui n'auraient pas fait remonter au serveur de certification un score de malveillance non nul pour l'objet communicant considéré. Ainsi, si aucune activité malveillante suspecte n'a encore été détectée pour un objet communicant au sein d'un réseau local, mais que la vision globale qu'a l'opérateur des activités de ce type d'objet, dans sa version de firmware, lui permet de déterminer qu'il est potentiellement dangereux, il en informe également ce réseau local, afin qu'il puisse se prémunir d'une éventuelle faille de sécurité, avant même son occurrence effective. La sécurité du réseau local est ainsi fortement accrue, grâce à la mutualisation des informations de surveillance de l'objet dans l'ensemble des réseaux locaux.
La figure 5 illustre un exemple de structure matérielle d'un serveur de certification d'objets communicants 50 selon un mode de réalisation de l'invention.
Un tel serveur de certification 50 comprend une mémoire vive 53 (par exemple une mémoire RAM), une unité de traitement 52 équipée par exemple d'un processeur, et pilotée par un programme d'ordinateur, stocké dans une mémoire morte 51 (par exemple une mémoire ROM ou un disque dur). A l'initialisation, les instructions de code du programme d'ordinateur sont par exemple chargées dans la mémoire vive 53 avant d'être exécutées par le processeur de l'unité de traitement 52. La mémoire vive 53 contient notamment une table de mémorisation des niveaux de confiance globaux affectés aux différents objets communicants 21 en fonction des scores de malveillance locaux reçus en provenance des différents réseaux de communication locaux. Le processeur de l'unité de traitement 52 pilote le calculateur de niveaux de confiance globaux, le comparateur de ces niveaux aux seuils de confiance globaux associés aux différentes catégories de confiance, ainsi que la génération de requêtes de révocation de certificats vers les passerelles résidentielles des différents réseaux locaux conformément au logigramme de la figure 4.
La figure 5 illustre seulement une manière particulière, parmi plusieurs possibles, de réaliser le serveur de certification 50, afin qu'il effectue les étapes du procédé détaillé ci-dessus, en relation avec la figure 4 (dans l'un quelconque des différents modes de réalisation, ou dans une combinaison de ces modes de réalisation). En effet, ces étapes peuvent être réalisées indifféremment sur une machine de calcul reprogrammable (un ordinateur PC, un processeur DSP ou un microcontrôleur) exécutant un programme comprenant une séquence d'instructions, ou sur une machine de calcul dédiée (par exemple un ensemble de portes logiques comme un FPGA ou un ASIC, ou tout autre module matériel).
Dans le cas où le serveur de certification 50 est réalisé avec une machine de calcul reprogrammable, le programme correspondant (c'est-à-dire la séquence d'instructions) pourra être stocké dans un médium de stockage amovible (tel que par exemple une disquette, un CDROM ou un DVD-ROM) ou non, ce médium de stockage étant lisible partiellement ou totalement par un ordinateur ou un processeur.

Claims (14)

  1. REVENDICATIONS
    1. Procédé de gestion d'un réseau de communication local (40i-403) comprenant une pluralité d'objets communicants (11-17; 21) aptes à être connectés audit réseau et un serveur (10) de configuration de paramètres d'accès desdits objets communicants audit réseau, caractérisé en ce qu'il comprend :
    une surveillance (25) de données émises par lesdits objets communicants ; une affectation d'un score de malveillance local (27) auxdits objets communicants en fonction d'un résultat de ladite surveillance ;
    une classification desdits objets communicants dans une catégorie de confiance, en fonction d'une comparaison (28) dudit score de malveillance local et d'un seuil de confiance local associé à ladite catégorie de confiance.
  2. 2. Procédé selon la revendication 1, caractérisé en ce que ladite surveillance est apte à détecter au moins une activité malveillante d'un desdits objets communicants et/ou au moins une configuration à risque dudit objet communicant, et en ce que ledit score de malveillance local affecté est calculé par sommation de poids de malveillance associés à ladite au moins une activité malveillante et/ou à ladite au moins une configuration à risque détectées.
  3. 3. Procédé selon l'une quelconque des revendications 1 et 2, caractérisé en ce que ladite catégorie de confiance appartient à un ensemble d'au moins deux catégories de confiance, comprenant :
    une catégorie d'objets communicants de confiance ; une catégorie d'objets communicants non fiables.
  4. 4. Procédé de gestion d'un réseau de communication local selon la revendication 3, caractérisé en ce que ledit ensemble d'au moins deux catégories de confiance comprend également au moins une catégorie d'objets communicants insuffisamment fiables.
  5. 5. Procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 1 à 4, caractérisé en ce qu'il comprend une adaptation (242) d'une offre d'accès à des ressources dudit réseau par lesdits objets communicants, en fonction de ladite catégorie de confiance dans laquelle ils sont classés.
  6. 6. Procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 1 à 5, caractérisé en ce qu'il comprend une transmission dudit score de malveillance local affecté à un desdits objets communicants à un serveur de certification (50) dudit objet communicant.
  7. 7. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé selon l'une quelconque des revendications 1 à 6, lorsqu'il est exécuté par un processeur.
  8. 8. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de gestion d'un réseau de communication local selon l'une quelconque des revendications 1 à 6.
  9. 9. Serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local, caractérisé en ce qu'il comprend un processeur apte à mettre en oeuvre le procédé selon l'une quelconque des revendications 1 à 6.
  10. 10. Passerelle (10) d'accès à un réseau de communication, caractérisée en ce qu'elle comprend un serveur de configuration de paramètres d'accès d'un objet communicant à un réseau de communication local selon la revendication 9.
  11. 11. Procédé de certification d'au moins un objet communicant, apte à être connecté à des réseaux de communication locaux (40i-403), par l'intermédiaire de serveurs de configuration de paramètres d'accès dudit objet communicant auxdits réseaux locaux, caractérisé en ce qu'il comprend :
    une réception (41), en provenance d'au moins un desdits réseaux de communication locaux (40i-403), d'au moins un score de malveillance local affecté audit objet communicant au niveau dudit au moins un réseau local ;
    une affectation (42) d'un niveau de confiance global audit objet communicant en fonction dudit au moins un score de malveillance local reçu ;
    une transmission (44) auxdits serveurs de configuration de paramètres d'accès d'une requête de classification dudit objet communicant dans une catégorie de confiance, en fonction d'une comparaison (43) dudit niveau de confiance global et d'un seuil de confiance global associé à ladite catégorie de confiance.
  12. 12. Produit programme d'ordinateur comprenant des instructions de code de programme pour la mise en oeuvre d'un procédé de certification d'au moins un objet communicant selon la revendication 11, lorsqu'il est exécuté par un processeur.
  13. 13. Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions de code de programme pour l'exécution des étapes du procédé de certification d'au moins un objet communicant selon la revendication
    11.
  14. 14. Serveur de certification (50) d'au moins un objet communicant, caractérisé en ce qu'il comprend un processeur apte à mettre en oeuvre le procédé selon la revendication 11.
    1/3
FR1662319A 2016-12-12 2016-12-12 Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance. Active FR3060164B1 (fr)

Priority Applications (2)

Application Number Priority Date Filing Date Title
FR1662319A FR3060164B1 (fr) 2016-12-12 2016-12-12 Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance.
PCT/FR2017/053339 WO2018109304A1 (fr) 2016-12-12 2017-12-01 Gestion d'un réseau de communication local par classification d'objets communicants en catégories de confiance, en fonction d'un score de malveillance

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1662319 2016-12-12
FR1662319A FR3060164B1 (fr) 2016-12-12 2016-12-12 Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance.

Publications (2)

Publication Number Publication Date
FR3060164A1 true FR3060164A1 (fr) 2018-06-15
FR3060164B1 FR3060164B1 (fr) 2019-10-04

Family

ID=58401725

Family Applications (1)

Application Number Title Priority Date Filing Date
FR1662319A Active FR3060164B1 (fr) 2016-12-12 2016-12-12 Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance.

Country Status (2)

Country Link
FR (1) FR3060164B1 (fr)
WO (1) WO2018109304A1 (fr)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN112689167A (zh) * 2020-12-18 2021-04-20 杭州迪普科技股份有限公司 一种网络摄像机的变更检测方法及装置

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8776168B1 (en) * 2009-10-29 2014-07-08 Symantec Corporation Applying security policy based on behaviorally-derived user risk profiles
US20140244834A1 (en) * 2013-02-25 2014-08-28 Qualcomm Incorporated Methods to discover, configure, and leverage relationships in internet of things (iot) networks
US20150074390A1 (en) * 2013-09-10 2015-03-12 Opera Software Asa Method and device for classifying risk level in user agent by combining multiple evaluations
US20150135277A1 (en) * 2013-11-13 2015-05-14 Futurewei Technologies, Inc. Methods for Generating and Using Trust Blueprints in Security Architectures
WO2016209589A1 (fr) * 2015-06-23 2016-12-29 Symantec Corporation Routeur basé sur une sécurisation d'internet des objets sur réseaux locaux

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8776168B1 (en) * 2009-10-29 2014-07-08 Symantec Corporation Applying security policy based on behaviorally-derived user risk profiles
US20140244834A1 (en) * 2013-02-25 2014-08-28 Qualcomm Incorporated Methods to discover, configure, and leverage relationships in internet of things (iot) networks
US20150074390A1 (en) * 2013-09-10 2015-03-12 Opera Software Asa Method and device for classifying risk level in user agent by combining multiple evaluations
US20150135277A1 (en) * 2013-11-13 2015-05-14 Futurewei Technologies, Inc. Methods for Generating and Using Trust Blueprints in Security Architectures
WO2016209589A1 (fr) * 2015-06-23 2016-12-29 Symantec Corporation Routeur basé sur une sécurisation d'internet des objets sur réseaux locaux

Also Published As

Publication number Publication date
FR3060164B1 (fr) 2019-10-04
WO2018109304A1 (fr) 2018-06-21

Similar Documents

Publication Publication Date Title
US9515888B2 (en) Wireless local area network gateway configuration
US8839442B2 (en) System and method for enabling remote registry service security audits
CA2563422C (fr) Systemes et procedes de gestion de reseau
US8935742B2 (en) Authentication in a globally distributed infrastructure for secure content management
US7966650B2 (en) Dynamic internet address assignment based on user identity and policy compliance
US11140180B2 (en) Guard system for automatic network flow controls for internet of things (IoT) devices
JP2018525935A (ja) インターネットに接続可能なデバイスを用いた安全な通信
US9392019B2 (en) Managing cyber attacks through change of network address
CA2516880A1 (fr) Systeme et methode pour surveiller le trafic sur le reseau
Metongnon et al. Beyond telnet: Prevalence of iot protocols in telescope and honeypot measurements
Kumar et al. Review on security and privacy concerns in Internet of Things
FR3079380A1 (fr) Gestion securitaire d'un reseau de communication local comprenant au moins un objet communicant.
US7987255B2 (en) Distributed denial of service congestion recovery using split horizon DNS
Thapa Mitigating Threats in IoT Network Using Device Isolation
EP3556151A1 (fr) Procédé de contrôle d'un signal radio émis par une passerelle, passerelle et programme d'ordinateur correspondants
FR3060164B1 (fr) Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance, en fonction d'un score de malveillance.
FR3079709A1 (fr) Procede de connexion sans fil d'un objet communicant a un reseau de communication local, programme d'ordinateur et equipement d'acces correspondant.
FR3060163B1 (fr) Gestion d'un reseau de communication local par classification d'objets communicants en categories de confiance.
FR3105486A1 (fr) Procédé de détection d’un comportement malveillant dans un réseau de communication, dispositif, équipement d’accès audit réseau, procédé de détection d’une attaque distribuée dans ledit réseau, dispositif, équipement nœud et programmes d’ordinateur correspondants
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
Angadi et al. Penetration Testing: Smart Home IoT Devices
US11539741B2 (en) Systems and methods for preventing, through machine learning and access filtering, distributed denial of service (“DDoS”) attacks originating from IoT devices
US20190357052A1 (en) System and method for analyzing properties within a real time or recorded transmissions
EP4376455A1 (fr) Filtrage d'accès d'un objet connecté à un réseau de communication local
Šarac Cyber Security and Domain Name Systems Deploy and Protect Network With DNS Sinkhole Blackhole

Legal Events

Date Code Title Description
PLFP Fee payment

Year of fee payment: 2

PLSC Publication of the preliminary search report

Effective date: 20180615

PLFP Fee payment

Year of fee payment: 3

PLFP Fee payment

Year of fee payment: 4

PLFP Fee payment

Year of fee payment: 5

PLFP Fee payment

Year of fee payment: 6

PLFP Fee payment

Year of fee payment: 7

PLFP Fee payment

Year of fee payment: 8