Brevet FR2867003A1 — publié le 20050902

PROCEDE DE TRAITEMENT D'UN FLUX DE DONNEES TRAVERSANT UN DISPOSITIF PLACE EN COUPURE SUR UN RESEAU INFORMATIQUE Préambule de la description Domaine concerné, problème posé La présente invention concerne un procédé et un système pour le traitement d'un flux de données traversant un 5 dispositif placé en coupure sur un réseau informatique. Art antérieur La sécurité des réseaux informatique devient de plus en plus nécessaire et importante aussi bien pour les entreprises que pour les particuliers. En effet, le développement rapide de l'Internat multiplie les champs d'application et d'utilisation des réseaux informatiques, accroissant par là même l'importance des données échangées et stockées. Bien que présentant nombre d'avantages, la démocratisation massive de l'Internet, due à sa popularité, entraîne inévitablement un phénomène de criminalité informatique, grandissant à l'instar des enjeux stratégiques du réseau des réseaux. Ainsi l'interconnexion des réseaux d'entreprises, des réseaux domestiques et de l'Internet conduit à un besoin croissant de sécurité pour se prémunir, non seulement de l'ensemble des attaques existantes mais également des attaques futures qui se développent extrêmement rapidement. Les menaces pesant aussi bien sur les particuliers que sur les entreprises sont légions, parmi elles citons l'endommagement des systèmes informatisés, le vol d'informations confidentielles ou privées, l'usurpation d'identité à des fins illégales, les attaques visant au déni de services et l'espionnage industriel. Les solutions de sécurité se sont développées autour des problèmes liés aux interconnections de réseaux, essentiellement entre les réseaux d'entreprises et l'Internet. Ces solutions proposent d'autoriser ou d'interdire le cheminement du trafic réseau les traversant en s'appuyant en premier lieu sur des règles de filtrage de ce trafic. Les règles sont basées sur l'architecture des réseaux actuels, qui suivent le modèle OSI (Open Systems Interconnection, ISO/IEC 7498-1: 1994) et plus particulièrement l'une de ses implémentations: TCP/IP (Transmission Control Protocol/Internet Protocol, RFC 791 et 793). Ce sont les couches réseau (IP) et transport (TCP) qui sont analysées le plus souvent dans les solutions de sécurité. En effet, dans un réseau suivant l'architecture TCP/IP, la couche IP permet entre autre d'identifier de manière unique un système informatisé grâce à une adresse réseau (adresse IP) et la couche TCP permet entre autre d'identifier l'application destinataire ou émettrice des données au sein du système informatisé grâce à une adresse système (port TCP). Ainsi, le quadruplet adresse IP du système émetteur, port TCP de l'application émettrice, adresse IP du système récepteur, port TCP de l'application réceptrice définit totalement un lien de communication réseau. Dès lors, il devient possible d'autoriser ou d'interdire les communications réseau en fonction de certains critères liés aux adresses IP et aux ports TCP. Afin de normaliser l'accès aux services les plus utilisés (comme le service Web ou le service de messagerie électronique), l'autorité officielle nommée IANA (Internet Assigned Numbers Authority) est chargée de définir et de maintenir une liste des ports connus utilisés pour certains services réseau. Ainsi, l'IANA recommande un port donné pour chaque application désireuse de rendre un service particulier (serveur Web ou courriel, par exemple). Par exemple, la consultation de page Web s'effectue en contactant un serveur Web émettant et recevant ses données sur le port HTTP 80 . L'émission de messages électroniques (courriel) s'effectue en contactant un serveur mail émettant et recevant ses données sur le port 25 . Ces conventions ont permis de normaliser l'accès aux services Internet et donc d'accélérer leur implémentation par les développeurs et leur adoption par les utilisateurs. Les systèmes actuels d'écluses (communément appelées "firewall" dans le jargon informaticien IEEE COMMUNICATIONS MAGAZINE., Vol. 32 N 9 September 1994, page 50 à 57, S.M. BELLOVIN ET AL 'NETWORK FIREWALLS') permettent, conformément à une politique de sécurité composée de règles de filtrage, d'autoriser ou non l'accès à certains services réseau en fondant leur décision sur les numéros de port TCP. Cependant même si l'IANA est chargé de l'assignation des ports, les conventions qu'elle fixe ne restent que des recommandations: rien n'empêche les développeurs d'applications d'utiliser des ports référencés par l'IANA pour d'autres applications que celles pour lesquelles elles avaient été référencées. Il apparaît même un phénomène plus frauduleux qui consiste à utiliser les ports de services très utilisés comme le port HTTP 80 ou les ports de messagerie électronique. Ces services sont les plus utilisés sur le Web en entreprise, car ils permettent la communication par courriel et la recherche d'informations sur l'ensemble du réseau Internet. Afin d'autoriser l'accès à ces services, l'écluse doit être configurée pour laisser passer tous les flux de communication à destination des ports usuels. Il est alors tentant pour un éditeur de logiciels grand public, désireux d'être adopté par un maximum de personnes, de passer par ces ports usuels ouverts sur presque toutes les écluses du monde, et ce, afin d'être le moins possible limité par les logiciels de sécurité réseau tels que les écluses. On peut entre autre citer les logiciels de discussion (communément appelés chats ) ou autres logiciels de messageries instantanées qui désirent créer une communauté d'utilisateurs de plus en plus large afin de pouvoir faire des bénéfices sur les publicités présentées par ces applications. Ces applications coûtent cher aux entreprises car les employés utilisent de plus en plus les ressources réseau de leur entreprise à des fins personnelles. En outre, au-delà de ces considérations financières, il existe un nouveau risque de piratage. En effet les pirates utilisent de plus en plus fréquemment les services Web et de messageries pour déployer leurs virus, chevaux de Troie et autres attaques. Il en va de même pour les logiciels de partage de données (appelés couramment logiciels de Peer To Peer), qui ouvrent la porte aux pirates et mettent en danger une société dans le cas, par exemple, où un de ces employés utiliserait un tel service pour distribuer des fichiers confidentiels. L'obsolescence des solutions actuelles de sécurité est proche car de plus en plus d'applications passent par les ports autorisés pour un autre service, violant la convention qu'à un port est associé un service. Ainsi, de par les limitations des méthodes proposées, aucune solution actuelle de sécurité réseau n'est capable d'identifier efficacement les services transitant dans les flux réseau, et donc de proposer une sécurisation performante adaptée aux menaces de demain. L'invention, objet du présent brevet, permet de résoudre les problèmes évoqués précédemment sans présenter les inconvénients de l'art antérieur. Elle pallie les problèmes et les limitations des technologies existantes en proposant une solution innovante. Solution Procédé L'invention concerne un procédé de traitement d'un flux de données traversant un dispositif placé en coupure dans 35 un réseau informatique. Le procédé comprend: - une étape d'analyse, consistant, pour le dispositif, à reconnaître et/ou à analyser simultanément, conformément à une politique de sécurité, un protocole applicatif structurant une couche applicative du flux de données, - une étape de modification, consistant, pour le dispositif à modifier, en fonction de la politique de sécurité et/ou des résultats de l'étape d'analyse, au moins une partie de la couche applicative contenue dans le flux de données. De préférence, selon l'invention les étapes d'analyse et de modification comprennent: - la sous étape, pour le dispositif de mettre en oeuvre un logiciel, associé à des modules, et appliquant la politique de sécurité, la sous étape de sélectionner des modules déterminés parmi les modules, conformément à la politique de sécurité. De préférence, selon l'invention les modules réalisent au moins une des actions suivantes décoder, coder, déchiffrer, chiffrer, décompresser, compresser, sur au moins une partie des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention les modules effectuent l'étape d'analyse au moyen d'une vérification de conformité de la couche applicative à au moins une grammaire. De préférence, selon l'invention les modules effectuent l'étape d'analyse et/ou l'étape de modification sur au moins une partie des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention les modules effectuent l'étape d'analyse et/ou l'étape de modification sur l'intégralité des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention le procédé comprend en outre: - l'étape pour les modules de communiquer entre eux, - l'étape pour les modules de communiquer avec le logiciel. De préférence, selon l'invention le procédé comprend en outre: - l'étape de remplacer au moins une partie du protocole applicatif par un autre protocole applicatif. De préférence, selon l'invention le procédé comprend en outre: - l'étape de hiérarchiser les modules afin de minimiser les ressources informatiques, notamment l'espace mémoire et le temps de calcul, nécessaires au traitement du flux de données. Système L'invention concerne aussi un système de traitement 15 d'un flux de données traversant un dispositif placé en coupure dans un réseau informatique. Le dispositif comprend: - des moyens d'analyse réalisant une analyse permettant de reconnaître et/ou d'analyser simultanément, conformément à une politique de sécurité, un protocole applicatif structurant une couche applicative du flux de données, - des moyens de traitement informatique permettant de réaliser au moins une modification en fonction de ladite politique de sécurité et/ou des résultats de ladite analyse, d'au moins une partie de la couche applicative contenue dans le flux de données. De préférence, selon l'invention, les moyens d'analyse et les moyens de traitement informatique mettant en oeuvre un logiciel, associé à des modules, permettent: - d'appliquer la politique de sécurité, - de sélectionner des modules déterminés parmi les modules, conformément à la politique de sécurité. De préférence, selon l'invention, les modules permettent de réaliser au moins l'une des actions suivantes: 35 décoder, coder, déchiffrer, chiffrer, décompresser, compresser, au moins une partie des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention, les modules permettent de réaliser l'analyse au moyen d'une vérification de conformité de la couche applicative à au moins une grammaire. De préférence, selon l'invention, les modules effectuent l'analyse et/ou la modification sur au moins une partie des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention, les modules effectuent l'analyse et/ou la modification sur l'intégralité des données de la couche applicative contenue dans le flux de données. De préférence, selon l'invention, les modules 15 possèdent des moyens de communication permettant aux modules de communiquer entre eux et avec le logiciel. De préférence, selon l'invention, les moyens de traitement informatique permettent en outre de remplacer au moins une partie du protocole applicatif par un autre protocole applicatif. De préférence, selon l'invention, les moyens de traitement informatique et/ou les moyens d'analyse permettent en outre d'établir une hiérarchie des modules afin de minimiser les ressources informatiques, notamment l'espace mémoire et le temps de calcul, nécessaires au traitement du flux de données. Description détaillée Le système, objet de la présente invention, permet de réaliser parfaitement toutes les fonctionnalités du procédé décrit précédemment. Afin de mieux faire comprendre l'invention, différents exemples vont être décrits. Ces exemples donnent, à titre purement illustratif, des modes de réalisation possibles, modes auxquels ne se limite pas l'invention. La figure 1 représente le schéma général du dispositif 35 ainsi que son interconnexion dans un réseau informatique. Le dispositif D est placé en coupure d'un réseau R informatique quelconque: il peut s'agir d'Internet, d'un réseau Intranet, d'un réseau domestique ou bien de seulement deux postes reliés entre eux. On entend par coupure la séparation physique du réseau R en deux sous réseaux reliés entre eux à l'aide du dispositif D. Ainsi tout le flux de données FD transitant d'un sous réseau à destination de l'autre sous réseau doit traverser le dispositif D. Le dispositif D permet d'analyser en détails le flux applicatif transitant sur le réseau. Toute communication sur un réseau informatique est structurée suivant le modèle OSI organisé en couches comme suit: Niveau 7 Couche application Niveau 6 Couche présentation Niveau 5: Couche session Niveau 4: Couche transport Niveau 3 Couche réseau Niveau 2 Couche liaison de données Niveau 1 Couche physique Ainsi on retrouve du niveau 5 au niveau 7 l'ensemble des données de la couche applicative CA. Ces données contiennent l'ensemble des informations nécessaires aux applications communicant sur le réseau pour fonctionner et se comprendre. Les communications au niveau applicatif sont régies par des règles que l'on appelle protocoles applicatifs et qui permettent aux applications de comprendre le flux de données. Les protocoles applicatifs PA sont nombreux et l'enjeu pour le dispositif D est de pouvoir les reconnaître. L'analyse du dispositif D est commandée par une politique de sécurité PS avec laquelle il est en communication permanente au travers d'un logiciel L mis en oeuvre par les moyens de traitement informatique MTI, logiciel L qui orchestre l'ensemble des fonctions du dispositif. Ainsi en fonction de l'analyse effectuée, le dispositif D pourra approfondir ou non son analyse suivant ce que lui demande la politique de sécurité PS. Cette politique de sécurité peut être aussi bien dans le dispositif lui-même ou bien être distante, ceci ne restreint pas le cadre de notre invention. Ainsi que décrit ci-après, Le dispositif permet d'appliquer une politique de sécurité PS extrêmement fine, autorisant ou interdisant pour chaque utilisateur du dispositif D, l'utilisation d'une application réseau définie. On peut donc différencier l'accès au réseau Internet pour de simples recherches avec un navigateur Web et l'accès au réseau Internet pour le partage de fichiers et ceci même si le port des deux services est le même. Lors de la mise en route du dispositif D, le logiciel L analyse la politique de sécurité afin de connaître l'ensemble des protocoles sur lesquels la politique de sécurité PS impose des règles. A l'aide de ces informations, les moyens de traitement informatique MTI et les moyens d'analyse MA, mettant en uvre le logiciel L, sélectionnent des modules M de détection et d'analyse de protocole applicatif. Ces modules M exécutent leur tâche à l'intérieur du dispositif D et sont commandés par le dispositif lui-même par l'intermédiaire du logiciel L. Ces modules peuvent faire partie intégrante du dispositif ou bien être déportés hors du dispositif D, dans un tel cas le dispositif D nécessite un accès à l'ensemble des modules M qu'il a à disposition pour pouvoir les télécharger et les exécuter. Les modules M se chargent de la reconnaissance et de l'analyse du protocole, qui s'opèrent simultanément, afin d'en déduire chacun des éléments qui le constitue. Le mécanisme de reconnaissance et d'analyse des composants du protocole applicatif peut être effectué au travers d'une recherche de conformité à une grammaire. Une fois la sélection des modules effectuée, le logiciel L peut hiérarchiser les différents modules sélectionnés afin d'optimiser les traitements. En effet les modules M sont complémentaires dans la reconnaissance et la détection des protocoles applicatifs car ceux-ci sont très souvent imbriqués les uns dans les autres comme le montre l'exemple suivant: Lorsqu'on navigue sur des pages Internet, le protocole de communication employé est le HTTP . Ce protocole applicatif permet de demander des fichiers (textes, images, sons ou documents HTML). Le dispositif va analyser la couche applicative du flux de données pour en déduire le protocole applicatif (HTTP) et comprendre l'ensemble des données applicatives du protocole. Ainsi il connaîtra l'adresse du document demandé et les différentes options relatives à cette demande (protocole HTTP, RFC 2616). Suivant le document demandé, le dispositif pourra demander une analyse supplémentaire, mais le module de détection et d'analyse du protocole HTTP ne pourra poursuivre l'analyse du fichier demandé. En effet, suivant le fichier, d'autres modules spécialisés devront être appelés. Dans le cas d'une page Html, page classique d'un site Internet, le document est composé de plusieurs entités: du texte formaté à l'aide du langage HTML, ce dernier langage faisant lui-même appel à des langages plus évolués pour permettre de créer des pages dynamiques à l'aide de langages comme Java Script ou à l'aide de feuilles de style. Le dispositif pourra donc hiérarchiser les modules http , HTML , Java Script , Feuille de style . Ainsi le module http pourra appeler le module HTML qui pourra à son tour appeler les modules Java Script et Feuille de style . L'ensemble des résultats des modules M est communiqué au logiciel L qui peut en fonction de la politique de sécurité PS prendre les actions nécessaires à la sécurisation du flux. De même les modules peuvent communiquer entre eux, ceci permettant de partager l'ensemble des informations relatives au flux facilitant ainsi les différentes recherches et analyses. L'ensemble des communications entre les modules et le logiciel L est bidirectionnel, c'est à dire que lorsqu'un ordre est envoyé, la réponse peut être soit reçue immédiatement car l'information est déjà disponible, soit reçue plus tard une fois l'action nécessaire effectuée. Ainsi les communications peuvent être gérées par un système d'interruption, afin de permettre dans les cas critiques d'accélérer la transmission d'informations. Cependant le système de communication par statut, c'est-àdire par demande du statut des différentes informations (disponible ou non), reste disponible. Il est donc possible de faire des demandes du type informer le logiciel L dès qu'un protocole est identifié, ou qu'un composant est reconnu dans le flux ou bien du type l'adresse du site demandée est-elle déjà présente dans le flux ? Si oui la donner, sinon continuer l'analyse . Les communications peuvent être de différentes natures, cela peut être l'activation d'un module M sur une partie du flux, la demande d'une information à un des modules sur l'analyse en cours ou bien une demande d'action sur le flux. En effet les modules M sont capables d'agir sur le flux et sont même les acteurs principaux de la modification du flux. Lors de l'analyse et de la reconnaissance des différents protocoles applicatifs du flux, les modules M enregistrent, simultanément au cours de l'étape de reconnaissance et d'analyse, l'emplacement de chaque élément du protocole et sont donc capables d'accéder à ces informations très rapidement, que ce soit pour consultation ou pour modification. Les modules offrent donc au logiciel L, en plus de la détection des protocoles, des fonctions d'accès aux informations du protocole reconnu, ainsi que des fonctions de modification des éléments du protocole. Les fonctions de modification du protocole sont découpées en deux familles; la première permet la modification du contenu de chaque champ composant le protocole, par exemple on peut changer dans une requête HTTP pour une page Web l'adresse du site désiré et ainsi changer www.interdit.com en www.autorisé.com; la deuxième famille permet de rajouter, de modifier ou de supprimer des champs protocolaires, on peut donc par exemple supprimer des options que l'on considère comme dangereuses (dans le cas de http l'ensemble des données utilisateurs, souvent données en options, qui permettent de connaître les logiciels utilisés par l'utilisateur ainsi que l'ensemble des pages visitées!), ou bien ajouter des options supplémentaires au protocole pour mieux définir les limites de l'application que l'on essaie de protéger. Les fonctionnalités des modules M sont cependant plus étendues encore. En effet de nombreux protocoles sont compressés, ou codés ou bien même chiffrés. Il existe donc des modules M dédiés à la gestion de ces cas particuliers qui décodent, déchiffrent et décompressent les données du flux applicatif. Dans le cas de ces modules, il est clair que la hiérarchisation et la communication entre modules permettent l'activation de modules M sur un flux pré traité (le flux décodé, déchiffré ou décompressé) pour pousser l'analyse encore plus loin. Il est alors possible d'analyser un fichier joint à un courriel qui serait compressé et qui pourrait contenir des fichiers infectés. Lorsque des modifications ont lieu dans le flux prétraité , le ou les modules de prétraitement ont en charge la modification du flux réel pour y inclure les modifications du flux pré traité . Ces modules sont informés qu'ils doivent réadapter le flux en cours par la fin de traitement de chacun de leurs sous modules. Par exemple pour un courriel contenant un fichier compressé au format ZIP , le module de compression/décompression ZIP appellera suivant les fichiers présents dans l'archive des modules d'analyse de fichiers exécutables, ou de fichier de Scripts ou de fichiers images; lorsque l'ensemble des modules appelés par le module de compression/décompression aura fini ses tâches, le module de compression/décompression pourra recompresser le flux en tenant compte des modifications effectuées sur le flux décompressé. L'ensemble des traitements précédemment décrits est effectué sur l'intégralité du flux. Cependant la politique de sécurité peut décider d'arrêter les traitements et la reconnaissance protocolaire sur une connexion en cours, si elle possède des règles lui certifiant que la connexion ne nécessite pas d'analyse supplémentaire. Le logiciel L peut donc activer ou désactiver dynamiquement chacun des modules M tout au long du flux. REVENDICATIONS 1. Procédé de traitement d'un flux de données (FD) traversant un dispositif (D) placé en coupure dans un réseau informatique (R); ledit procédé comprenant: - une étape d'analyse, consistant, pour ledit dispositif (D), à reconnaître et/ou à analyser simultanément, conformément à une politique de sécurité (PS), un protocole applicatif (PA) structurant une couche applicative (CA) dudit flux de données (FD), - une étape de modification, consistant, pour ledit dispositif à modifier, en fonction de ladite politique de sécurité (PS) et/ou des résultats de ladite étape d'analyse, au moins une partie de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 2. Procédé selon la revendication 1; lesdites étapes d'analyse et de modification comprenant: - la sous étape, pour ledit dispositif (D) de mettre en oeuvre un logiciel (L), associé à des modules (M), et appliquant ladite politique de sécurité (PS), - la sous étape de sélectionner des modules (M) déterminés parmi lesdits modules (M), conformément à la politique de sécurité (PS). 3. Procédé selon la revendication 2; lesdits modules (M) réalisant au moins une des actions suivantes: décoder, coder, déchiffrer, chiffrer, décompresser, compresser, sur au moins une partie des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 4. Procédé selon l'une quelconque des revendications 2 ou 3; lesdits modules (M) effectuant ladite étape d'analyse au moyen d'une vérification de conformité de ladite couche applicative (CA) à au moins une grammaire. 5. Procédé selon l'une quelconque des revendications 2 à 4; lesdits modules (M) effectuant ladite étape d'analyse et/ou ladite étape de modification sur au moins une partie des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 6. Procédé selon l'une quelconque des revendications 2 à 4; lesdits modules (M) effectuant ladite étape d'analyse et/ou ladite étape de modification sur l'intégralité des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 7. Procédé selon l'une quelconque des revendications 2 à 6; ledit procédé comprenant en outre - l'étape pour lesdits modules (M) de communiquer 15 entre eux, - l'étape pour lesdits modules (M) de communiquer avec ledit logiciel (L). 8. Procédé selon l'une quelconque des revendications 2 20 à 7; ledit procédé comprenant en outre - l'étape de remplacer au moins une partie dudit protocole applicatif (PA) par un autre protocole applicatif. 9. Procédé selon l'une quelconque des revendications 2 25 à 8; ledit procédé comprenant en outre - l'étape de hiérarchiser lesdits modules (M) afin de minimiser les ressources informatiques, notamment l'espace mémoire et le temps de calcul, nécessaires audit traitement dudit flux de données (FD). Système 10. Système de traitement d'un flux de données (FD) traversant un dispositif (D) placé en coupure dans un réseau 35 informatique (R); ledit dispositif comprenant: - des moyens d'analyse (MA) réalisant une analyse permettant de reconnaître et/ou d'analyser simultanément, conformément à une politique de sécurité, un protocole applicatif (PA) structurant une couche applicative (CA) dudit flux de données (FD), - des moyens de traitement informatique (MTI) permettant de réaliser au moins une modification, en fonction de ladite politique de sécurité (PS) et/ou des résultats de ladite analyse, d'au moins une partie de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 11. Système selon la revendication 10; lesdits moyens d'analyse (MA) et lesdits moyens de traitement informatique (MTI) mettant en oeuvre un logiciel (L), associé à des modules (M), permettant: - d'appliquer ladite politique de sécurité (PS), - de sélectionner des modules (M) déterminés parmi lesdits modules (M), conformément à ladite politique de sécurité (PS). 12. Système selon la revendication 11; lesdits modules (M) permettant de réaliser au moins l'une des actions suivantes: décoder, coder, déchiffrer, chiffrer, décompresser, compresser, au moins une partie des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 13. Système selon l'une quelconque des revendications 11 ou 12; lesdits modules (M) permettant de réaliser ladite analyse au moyen d'une vérification de conformité de ladite couche applicative (CA) à au moins une grammaire. 14. Système selon l'une quelconque des revendications 11 à 13; lesdits modules (M) effectuant ladite analyse et/ou ladite modification sur au moins une partie des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 15. Système selon l'une quelconque des revendications 11 à 13; lesdits modules (M) effectuant ladite analyse et/ou ladite modification sur l'intégralité des données de ladite couche applicative (CA) contenue dans ledit flux de données (FD). 16. Système selon l'une quelconque des revendications 11 à 15; lesdits modules (M) possédant des moyens de communication permettant auxdits modules (M) de communiquer entre eux et avec ledit logiciel (L). 17. Système selon l'une quelconque des revendications 11 à 16; lesdits moyens de traitement informatique (MTI) permettant en outre de remplacer au moins une partie dudit protocole applicatif (PA) par un autre protocole applicatif. 18. Système selon l'une quelconque des revendications 11 à 17; lesdits moyens de traitement informatique (MTI) et/ou lesdits moyens d'analyse (MA) permettant en outre d'établir une hiérarchie desdits modules (M) afin de minimiser les ressources informatiques, notamment l'espace mémoire et le temps de calcul, nécessaires audit traitement dudit flux de données (FD). 15