FR 2910659 A1 20080627 FR 0655762 A 20061221 1 Procédé de protection contre au moins une intrusion dans un système informatique La présente invention a pour objet un procédé de protection contre au moins une intrusion dans un système informatique. Le domaine de l'invention est celui de la protection des systèmes informatiques et en particulier celui de la protection des systèmes informatiques ouverts. Ici on appelle système informatique ouvert un système ayant au moins un accès via un réseau public de type WAN (Wide Area Network, pour réseau étendu), par exemple le réseau Internet, ou RAS (Remote Access Service, service d'accès distant), par exemple un centre d'appel fonctionnant en mode répondeur vocal. Par opposition les réseaux fermés sont, par exemple, les LAN (Local Area Network, pour réseau local). Encore plus particulièrement le domaine de l'invention est celui de la protection des systèmes informatiques ouverts vers lesquels on peut envoyer une requête de mise à jour du système. Un but de l'invention est de supprimer les intrusions frauduleuses dans les systèmes informatiques ouverts. Un autre but de l'invention est de protéger les systèmes informatiques 20 en temps adapté. Un temps adapté est un temps compatible avec l'usage fait par un utilisateur du système informatique. Dans l'état de la technique on connaît des systèmes informatiques ouverts permettant à un prestataire de service de fournir une interface d'administration de service à ses abonnés, ou aux tiers en général. Ces 25 interfaces permettent en particulier de saisir des renseignement personnels en vu de la fourniture d'un service à la personne ayant effectuée la saisie pour souscrire le service. On note ici que la saisie est réalisée soit directement par le tiers, ou via un interlocuteur, mandaté par le prestataire, qui est en vis-à-vis du tiers et qui effectue les saisies sous la diction du tiers. 30 Dans ces cas de figures le tiers peut déclarer/saisir n'importe quelle information qui sera traité de manière prédéfinie par le système informatique. Cela pose des problèmes dans le cas où la mise à jour du système d'information entraîne des traitements ultérieurs comme par exemple une prestation de service, une facturation, la production d'un bien, la livraison 35 d'un bien, etc. la liste n'étant pas exhaustive. 2910659 2 Dans l'état de la technique on connaît des prestataires de services qui mettent en oeuvre une division anti-fraude. Une telle division est constituée de moyens humains qui analysent au cas par cas des dossiers qui sont soumis à la dite division anti-fraude. Les problèmes liés à ce mode de 5 fonctionnement sont au moins la sélection des dossiers, la capacité de traitement de la division anti-fraude et la rapidité de traitement d'un dossier par la division anti-fraude. Un tel traitement des requêtes frauduleuses est inutilisable dans le cas d'une relation directe avec un client. En effet le client qui s'est déplacé 10 vers un "point de vente" s'attend à un traitement rapide de sa requête, et les personnes derrière lui attendent les mêmes services. Des moyens de traitement humain sont donc inadaptés à ce genre de situation. Pour répondre à ce cas de figure on connaît des systèmes de traitements automatisés mais qui sont stricts et prévisibles. Par stricts on 15 entend que les conditions de validations sont peut nombreuses, simples et appliquées unilatéralement sans possibilité d'y déroger. Une possibilité existe parfois d'y déroger en appelant, au cas par cas, la division anti-fraude qui doit alors fournir une réponse dans un laps de temps très court. La contrainte de devoir fournir cette réponse nuit par ailleurs au travail d'analyse de la division anti-fraude qui ne peut pas se consacrer pleinement à l'étude de la fraude mais doit alors aussi s'occuper de la gestion client. Le manque de souplesse du système anti-fraude conduit à refuser des requêtes non frauduleuses plutôt que de risquer d'accepter des requêtes frauduleuses, ou au contraire accepter des requêtes frauduleuses plutôt que de risquer de refuser des requêtes valides. L'effet de la lutte contre la fraude a donc des effets néfastes visibles sur le traitement d'une requête de mise à jour. Les tests de validité d'une requête de l'état de la technique sont, de plus, connus ce qui les rend prévisibles et donc plus faciles à déjouer pour un fraudeur 'professionnel'. Les stratégies de l'état de la technique pénalisent donc les prestataires et leurs clients honnêtes tout en favorisant dans une certaine mesure l'activité des fraudeurs. L'invention résout ces problèmes en automatisant et en systématisant 35 des tests réalisés sur une requête de mise à jour avant sa prise en compte 2910659 3 par un système informatique. Ces tests sont planifiés dans le temps et non prédictibles car dépendant en partie du hasard dans le choix des tests effectués. Ces tests sont de plus adaptés à l'origine de la requête selon que cette origine implique une réponse rapide ou une réponse pouvant être 5 différée. L'invention a donc pour objet un procédé de protection contre au moins une intrusion dans un système informatique, intrusion réalisée via au moins une requête de mise à jour d'une base de données dudit système informatique, ledit procédé de protection comportant une étape de validation 10 de la requête, procédé caractérisé en ce que l'étape de validation comporte les étapes suivantes mises en oeuvre par un dispositif de validation : - enregistrement de la requête de mise à jour dans une table de travail, - production et enregistrement dans une table de règles d'une liste 15 planifiée de règles relatives à la requête et que doit valider la requête pour être déclarée valide, - évaluation planifiée des règles présentes dans la table de règles pour produire une réponse à la requête de mise à jour, - prise en compte de la requête de mise à jour en fonction de 20 l'évaluation des règles. Dans une variante le procédé selon l'invention est aussi caractérisé en ce que la réponse à une requête de mise à jour est parmi le groupe de réponses formé d'au moins : - mise à jour acceptee, 25 - mise à jour refusée, et - demande d'au moins une garantie supplémentaire. Dans une variante le procédé selon l'invention est aussi caractérisé en ce que l'une des règles produites fixe un délai maximal pour la production d'une réponse à la requête de mise à jour. 30 Dans une variante le procédé selon l'invention est aussi caractérisé en ce qu'une requête de mise à jour refusée est enregistrée dans une base de données de requêtes frauduleuses. Dans une variante le procédé selon l'invention est aussi caractérisé en ce qu'il comporte une étape préliminaire d'évaluation de similarité avec des requêtes frauduleuses connues dans la base de données de requêtes 2910659 4 frauduleuses, un degré de similarité élevé avec au moins l'une de ces requêtes connues conduisant à un rejet de la requête. Dans une variante le procédé selon l'invention est aussi caractérisé en ce que l'évaluation d'une règles a pour résultat l'enregistrement d'au moins 5 une nouvelle règle dans la table de règles, la nouvelle règle étant relative à la même requête de mise à jour que la règle dont l'évaluation a conduit à l'enregistrement de la nouvelle règle. Dans une variante le procédé selon l'invention est aussi en ce que l'évaluation d'une règle a pour effet la modification d'une estimation chiffrée 10 de risque associée à la requête de mise à jour liée à la règle évaluée, l'estimation devant être correctement située relativement à un seuil prédéterminé pour que la requête soit acceptée. Dans une variante le procédé selon l'invention est aussi caractérisé en ce qu'au moins une règle de la liste de règles est choisie aléatoirement parmi 15 des règles applicables à la requête de mise à jour. Dans une variante le procédé selon l'invention est aussi caractérisé en ce que l'évaluation d'une règle provoque l'émission d'une requête d'interrogation vers un système tiers, la prise en compte de la réponse à cette requête d'interrogation faisant partie de l'évaluation de la règle. 20 Dans une variante le procédé selon l'invention est aussi caractérisé en ce qu'il comporte une étape de production et d'enregistrement de statistiques relatives à au moins une caractéristique de la requête, ces statistiques étant utilisées par les règles servant à l'évaluation de la requête de mise à jour. L'invention sera mieux comprise à la lecture de la description qui suit 25 et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatifs de l'invention. Les figures montrent: Figure 1 : une illustration de moyens supportant la mise en oeuvre de l'invention. Figure 2 : une illustrations d'étapes du procédé selon l'invention. 30 La figure 1 montre un dispositif 101 serveur de protection d'un système informatique. Le serveur 101 est connecté à un réseau 102 ouvert, par exemple le réseau Internet. Par construction d'une architecture réseau le serveur 101 est un point de passage obligé pour toutes les requêtes de mise à jour du système informatique protégé par le serveur 101. Le serveur 101 35 est donc assimilable à un pare-feu informatique. On le désigne ici comme un 2910659 5 serveur par souci de clarté, car il traite des requêtes issues d'une pluralité d'utilisateurs sur un réseau. Le serveur 101 comporte un microprocesseur 102 et une mémoire de programme 103 communiquant via un bus 104. Lorsque l'on prête une action 5 à un dispositif, cette action est en fait réalisée par un microprocesseur du dispositif commandé par des codes instructions enregistrés dans une mémoire de programme du dispositif. Par extension on prête aussi des action à des applications. Cela correspond à tout ou partie des codes instructions de l'application mis en oeuvre par le microprocesseur du 10 dispositif dans une mémoire de programme duquel l'application est enregistrée. Le serveur 101 comporte aussi une mémoire 105 de travail pour l'enregistrement des requêtes de mise à jour en cours de traitement, c'est-à-dire les requêtes devant être validées ou invalidées par le procédé selon 15 l'invention. La mémoire 105 est donc une table comportant une ligne par requête. Chaque ligne permet d'associer au moins la requête 105.1 à un identifiant 105.2 et à un score 105.3. Dans la pratique on associe aussi à la requête de mise à jour une date de prise en compte par le serveur 101. Cette date est celle à laquelle la requête de mise à jour a été enregistrée dans la 20 mémoire 105. Le serveur 101 comporte aussi une mémoire 106 de règles de validation applicables à une requête de mise à jour. La mémoire 106 est alors une table permettant d'associer une règle à un identifiant de règle. Une règle est un ensemble d'instructions à appliquer à tout ou partie d'une 25 requête de mise à jour à valider. Les règles sont essentiellement, mais de manière non limitative, de différentes natures parmi: - règles de traitement des informations connues par le serveur 101 via les différentes mémoire auxquelles il a accès, 30 -règles d'interrogation de systèmes externes pour accroître les connaissance du serveur 101, et - règles de communication pour mettre à jour un système informatique et/ou communiquer le résultat d'un traitement. Le serveur 101 comporte aussi une table 107 permettant d'associer 35 une date 107.1 à un identifiant 107.2 de requête de mise à jour et à un 2910659 6 identifiant 107.3 de règle de validation. La mémoire 107 permet donc de définir une liste planifiée de règles de la mémoire 106 à appliquer aux requêtes de la mémoire 105. Par planifiée on entend ici que l'information de date est traitée par un ordonnanceur c'est-à-dire un programme apte à lancer 5 l'exécution d'une tâche à une date donnée. Ici une tâche est l'application d'une règle à une requête de mise à jour. L'association entre les deux se fait via la mémoire 107. La mémoire 107 comporte aussi une colonne 107.4 permettant de stocker le résultat du traitement d'une règle. Cela permet, entre autres, aux règles planifiées de dépendre les unes des autres via leur 10 résultat. Le serveur 101 comporte aussi une mémoire 108 qui une est une base de données de requêtes de mise à jour qui ont été, ou doivent être, considérées comme frauduleuses par le dispositif selon l'invention. Cette mémoire est mise à jour dynamiquement par le procédé selon l'invention 15 selon le résultat du traitement d'une requête de mise à jour. Le serveur 101 comporte aussi des circuits 109 interface lui permettant de recevoir des requêtes de mise à jour. Ces circuits 109, ou d'autres, lui permettent aussi de communiquer avec le système informatique que le serveur 101 protège. 20 Le serveur 101 comporte aussi une mémoire 110 pour y enregistrer des statistiques sur les requêtes de mise à jour reçues. Ces statistiques sont par exemple des fréquences géographiques ou des fréquences horaires. Une fréquence géographique est, par exemple, le nombre de requêtes de mise à jour reçue d'un domaine Internet particulier, ou d'une adresse IP 25 particulière, ou d'une adresse postale particulière etc, la liste n'étant pas exhaustive. Les requêtes de mise à jour peuvent aussi être analysées selon leurs caractéristiques. Une fréquence horaire est, par exemple, le nombre de requêtes ayant une caractéristique donnée reçues par tranche horaire. Les statistiques géographiques et horaires peuvent être cumulées: nombre de 30 requêtes provenant de tel endroit durant telle tranche horaire. On note ici que la mémoire 110 est, dans une variante, une mémoire permettant d'enregistrer toutes les requêtes de mise à jour reçues par le serveur 101. Dans ce cas les statistiques sont obtenues par des requêtes de type SQL effectuées sur cette mémoire 110 qui est vue comme une base de données 35 de requêtes de mise à jour. Dans une autre variante préférée, ces 2910659 7 statistiques sont obtenues à partir du contenu de la mémoire 107. Le serveur 101 comporte aussi, de manière classique, une horloge 111 servant pour la planification des tâches décrites par la mémoire 107. Les éléments 105 à 111 sont interconnectés par le bus 104. 5 La mémoire 103 comporte plusieurs zones, chacune de ces zones comportant des codes instructions correspondant à la mise en oeuvre d'une fonction. Parmi ces zones on cite au moins celles intéressant le plus directement l'invention. La mémoire 103 comporte: - une zone 103.1 comportant des codes instructions pour 10 l'enregistrement d'une requête de mise à jour dans la mémoire 105 de travail, - une zone 103.2 comportant des codes instructions pour la détermination d'une similitude entre des requêtes de mise à jour, - une zone 103.3 comportant des codes instructions pour la production d'une liste de règles que doit valider une requête de mise à jour avant d'être 15 prise en compte, - une zone 103.4 comportant des codes instructions pour l'évaluation des règles que doit valider une requête de mise à jour, - une zone 103.5 comportant des codes instructions pour la prise en compte d'une réponse à une requête d'interrogation d'un système externe. 20 La figure 1 montre aussi que le serveur 101 est connecté au réseau 102 auquel sont aussi connectés une pluralité de terminaux de natures diverses. Parmi ces divers terminaux certains sont, soit aptes à émettre une requête de mise à jour vers le serveur 101, soit apte à répondre à une requête du serveur 101. 25 Pour l'illustration d'une mise en oeuvre de l'invention on choisit comme exemple d'application un service de souscription d'un abonnement à un prestataire de services. La figure 2 montre une étape 201 de production d'une demande de souscription. In fine, une demande de souscription est une requête de mise à 30 jour d'une base de données du prestataire de service. Pour la description une souscription est modélisée par un message électronique. La représentation électronique d'une souscription est donc assimilable à un message électronique comportant les champs suivants: - identifiant idMe du medium utilisé pour la souscription, selon qu'il 35 s'agit d'une souscription en ligne (sans interlocuteur humain) ou en point de 2910659 8 vente (avec un interlocuteur humain), - la cas échéant l'adresse/identifiant idPV du point de vente et un identifiant idV du vendeur, - nom et prénom du souscripteur, 5 - adresse postale du souscripteur, - date de naissance du souscripteur, - un identifiant d'un mode de paiement, par exemple numéro de carte bleue, numéro de RIB, - un identifiant idO de l'offre souscrite, 10 - un identifiant idMo du mobile choisi, c'est-à-dire en fait une information permettant l'évaluation du coût financier de la souscription pour le prestataire de service, on l'aura compris on considère ici un prestataire de téléphonie mobile, - date et heure de la souscription, 15 -adresse électronique du souscripteur. Un tel message est produit à partir d'un terminal proposant un ou plusieurs masques de saisies. Une fois les saisies validées le message est envoyé vers le serveur 101 via le réseau 102. Le terminal produisant la requête Req de mise à jour est aussi appelé système requérant. 20 Dans une étape 202 le serveur 101 reçoit une requête de mise à jour d'un système informatique qu'il protège. Il s'agit par exemple de la requête Req produite à l'étape 201. Dans l'étape 202 le serveur 101 enregistre la requête Req dans la mémoire 105. Le serveur 101 crée donc une nouvelle ligne dans la mémoire 25 105, cette ligne, et plus particulièrement la partie 105.1 de la ligne, comportant autant de champs renseignés que de champs existant dans la requête Req. Dans la pratique la colonne 105.1 est préformatées en fonction de la structure attendue d'une requête de mise à jour. La colonne 105.1 comporte donc autant de sous-colonnes, ou champs si on considère une 30 ligne, que la plus complexe des requêtes de mise à jour comporte de champs. Un champ de la requête Req qui ne serait pas prévu est tout simplement ignoré, ou une requête comportant un tel champ est tout simplement ignorée. Cette nouvelle ligne comporte aussi un champ 105.3 score et un 35 champ 105.2 identifiant. A la création on considère que le score d'une 2910659 9 requête est nul. Le champ identifiant est, par exemple, un compteur de requêtes qui augmente d'une unité à chaque nouvelle requête de mise à jour reçue par le serveur 101. Dans une variante de l'invention le serveur 101 met à jour la mémoire 5 110 de statistiques en fonction des caractéristiques de la requête Req. Le serveur 101 passe alors à une étape 203 de recherche de cas similaires à la requête Req qui vient d'être reçue. Cette recherche de similarité se fait par les valeurs des champs de la requête Req et relativement aux requêtes enregistrées dans la mémoire 108. A cette fin la 10 mémoire 108 a la même structure que la colonne 105.1 de la mémoire 105. Les paramètres de cette recherche sont fixés à l'avance et peuvent porter sur un ou plusieurs critères. Par exemple une nouvelle requête est similaire à une ou plusieurs des requêtes de la mémoire 108 - si les champs nom et prénom de la nouvelle requête coïncident avec 15 les champs nom et prénom d'une requête enregistrée dans la mémoire 108, et/ou - si le champ adresse postale ou le champ adresse mail de la nouvelle requête coïncide avec respectivement le champ adresse postale ou le champ adresse mail d'une requête enregistrée dans la mémoire 108, et/ou 20 - si le champ moyen de paiement de la nouvelle requête coïncide avec le champ moyen de paiement d'une requête enregistrée dans la mémoire 108.... La liste des critères possibles n'est pas limitative. Il peut y avoir évaluation d'un ou plusieurs critères. 25 Si le résultat de l'étape 203 est qu'il existe une similarité entre la nouvelle requête et au moins une requête de la mémoire 108 alors le serveur passe à une étape 204 de fin de traitement de la nouvelle requête. Sinon le serveur 101 passe à une étape 205 de détermination d'une stratégie de validation de la requête de mise à jour. 30 Dans l'étape 204 le serveur 101 effectue au moins deux actions : - mise à jour dans une étape 206 de la mémoire 108 en y enregistrant la requête Req qui sert alors de requête de référence pour déterminer la similarité des requêtes à venir avec les requêtes jugées frauduleuses, et - l'émission, dans une étape 207, d'une réponse négative vers le 35 système requérant c'est-à-dire vers le système ayant servi à produire la 2910659 10 requête Req à l'étape 201. Une telle réponse négative signifie qu'en l'état de la requête, la mise à jour correspondant à la requête ne peut pas être effectuée. Dans l'étape 205 le serveur 101 met à jour la mémoire 107 en fonction 5 au moins du médium utilisé pour produire la requête Req. Ici on distingue principalement deux média: -Internet, et - point de vente. Dans le cas d'Internet, le medium est synonyme d'un enregistrement 10 qui ne requiert pas de réponse temps réel. La personne ayant produit la requête sait qu'elle doit s'attendre à un délai de livraison, ne serait ce que du fait qu'il faut lui envoyer un colis. Dans le cas du point de vente le medium est synonyme d'un enregistrement qui requiert une réponse temps réel. En effet une personne 15 qui s'est déplacée vers un point de vente s'attend à repartir avec le service qu'elle est venue chercher activé. Dans la pratique les règles appliquées à une requête sont les mêmes, il s'agit de règles de base que le prestataire souhaite voir validées avant de fournir le service sauf: 20 - pour la règle provoquant la réponse du serveur 101 au système requérant. Le délai varie en effet selon le medium. Ce délai est court dans le cas du point de vente, de l'ordre de la minute. Ce délai peut être bien plus long dans le cas d'Internet, de l'ordre du jour. Cette règle fixe un délai maximum de réponse sur la validité de la requête de mise à jour : 25 pour des règles spécifique au medium, - pour une ou plusieurs règles choisies au hasard parmi celles disponibles dans la mémoire 106 mais différentes des règles de base, - pour des règles spécifiques au medium. Les règles pour la requête Req sont donc extraites de la mémoire 106 30 en fonction d'un scénario prédéfini de validation. Les règles extraites sont enregistrées, par référence à leur identifiant, dans la mémoire 107. Chacune de ces références de règle est associée à l'identifiant de la requête Req, à une date d'évaluation et à un champ de résultat d'évaluation. La figure 2 montre aussi une étape 208 d'ordonnancement. L'étape 35 208 est une tâche 208 permanente exécutée par le serveur 101. Cette tâche 2910659 11 208 parcourt régulièrement la mémoire 107 à la recherche de lignes dont la date est inférieure à la date donnée par l'horloge 111 et dont le champ réponse (107.4) indique que la règle n'a pas été évaluée. Pour toutes ces lignes la tâche 208 effectue l'évaluation de la règle identifiée par la ligne. 5 La tâche 208 assure aussi le rôle de 'collecteur d'ordure'. Cela signifie que la tâche 208 gère le vieillissement des requêtes de mise à jour. Si une requête devient trop vieille, plus d'une semaine, alors la tâche 108 nettoie les mémoires 105 et 107 afin d'en supprimer les lignes relatives à cette requête trop vieille. Cette suppression est accompagnée, si la réponse n'a pas déjà 10 été donnée, d'une réponse au système requérant du type "données insuffisante pour prendre en compte la requête". L'évaluation d'une règle d'interrogation d'un système externe comporte au moins les étapes suivantes: - production d'une requête d'interrogation comportant au moins: 15 - un identifiant de la requête de mise à jour, - un identifiant de la règle, - une requête d'interrogation pour le système externe, - émission de la requête vers le système externe. Le système externe est, par exemple, le système Preventel, FIANET 20 ou Coface, Ima liste n'étant pas exhaustive. Un système externe est aussi le système requérant. Un système externe est aussi un système de facturation / gestion de contentieux. D'une manière générale, un système externe est un système qui n'est pas celui protégé par le serveur 101. Les règles de traitement prennent en compte, sur stimulation d'un 25 événement de modification des données sur une requête de mise à jour ou sur une stimulation temporelle le traitement des informations connues pour la requête. Une stimulation d'un événement est, par exemple, une réponse d'un système externe. L'évaluation d'une règle de traitement provoque, par exemple : 30 - modification du score de la requête, et/ou - modification de la planification des règles à évaluer pour la requête par modification de date, ajout de règle ou suppression de règles, et/ou - modifier le score de requête de la mémoire 105 présentant des similitudes avec la requête Req. 35 Les règles de traitements portent sur tout ou partie des données 2910659 12 propre à la requête. Une règle de traitement plus évoluée prend aussi en compte les données relatives aux autres requêtes présentes dans la mémoire 105. Une règle de traitement type ressemble au pseudo code suivant: 5 SI (critère) ALORS (score = score +/- S) Le critère porte sur une ou plusieurs données connues. Il est du type: - nom inscrit chez Preventel, ou - code postal inconnu, ou - trop d'impayés... 10 la liste n'étant pas exhaustive. Une règle de traitement peut aussi être du type SI (critère) ALORS (créer nouvelle règle (identifiant règle)) Une réponse d'un système externe comporte des informations pour identifier la ligne de la mémoire 107 ayant provoqué l'interrogation du 15 système externe, c'est-à-dire les moyens d'identifier la requête à laquelle la réponse se rapporte. Dans l'exemple choisi ces moyens sont un identifiant de requête et un identifiant de règle. Dans la pratique il pourrait s'agir d'une caractéristique d'une requête de mise à jour, nom, adresse ou autre, permettant d'associer la réponse du système externe à une ou plusieurs 20 requêtes de mise à jour. Dans l'exemple choisi les résultats des évaluations des règles sont enregistrés dans la mémoire 107 dans la ligne correspondant à la règle et à la requête de mise à jour. Dans une autre mise en oeuvre ces résultats peuvent être stockés dans la mémoire 105 dans la ligne correspondant à la 25 requête de mise à jour concernée. Il suffit que la mémoire 105 comporte autant de colonnes supplémentaires que de règles évaluables, ou plus simplement que le résultat soit stocké associé à un identifiant de règle. Le but est que les résultats de l'évaluation des règles soient disponibles pour les règles à venir. 30 Les règles d'interrogations mettent donc à jours les informations relatives à une requête de mise à jour. Les règles de traitement utilisent ces informations pour modifier le/les scores et/ou les traitements ultérieurs d'une/plusieurs requêtes de la mémoire 105. La figure 2 via la représentation de la tâche 208 illustre ce processus. 35 La figure 2 montre en effet une étape 208.1 d'attente dans laquelle la tâche 2910659 13 208 scrute la mémoire 107 pour y détecter les actions/lignes dont la date d'exécution est antérieure à la date courante, c'est l'étape 208.2. Si le test de l'étape 208.2 est positif, c'est-àdire si il y a une action à exécuter alors la tâche 208 passe à une action 208.3 d'exécution de l'action, c'est-à-dire de 5 réalisation des instructions de la règle de la ligne que la tâche 208 a détectée à l'étape 208.2. Cette action est, comme précédemment décrit une action de traitement ou une action d'interrogation. S'il s'agit d'une action d'interrogation celle-ci sera suivie d'une étape 10 209 de prise en compte de la réponse suite à la réception d'un message de réponse du système distant interrogé. Cette prise en compte est la mise à jour des donnéesrelatives à la requête Req et l'exécution d'une règle de traitement pour traiter cette réponse. Dans une étape 210 suivant l'étape 209, la tâche 208 exécute donc 15 une étape de modifucation de l'estimation du risque dans laquelle la nouvelle donnée est prise en compte. Cette exécution provoque la modification du score de la requête Req. La règle de traitement peut aussi prévoir une modification de la stratégie de validation. Dans ce cas la tâche 208 exécute une étape 211 de mise à jour de la mémoire 107. 20 Dans l'étape 211 la tâche 208 modifie, ou crée, une ou des lignes dans la mémoire 107 pour prendre en compte le résultat du traitement. Une fois les traitements terminés, la tâche 208 revient dans son état d'attente. Si l'action détectée à l'étape 208.2 est une action de traitement alors 25 la tâche 208 effectue les étapes 210 et 211 selon les codes instructions décrivant l'action à exécuter. Dans la pratique une règle évaluée et ayant produit un résultat est effacée de la mémoire 107. A un moment du traitement la tâche 208 détecte une règle de 30 communication dans la mémoire 107. Une règle de communication est une règle qui émet une réponse vers le système requérant. La réponse est, dans notre exemple parmi les trois suivantes: - requête acceptée, - requête refusée, ou 35 - demande de garantie supplémentaire. 2910659 14 Cette réponse dépend du score de la requête de mise à jour. S'il est supérieur à un premier seuil S1, alors la réponse est une demande de garantie supplémentaire, s'il est supérieur à un deuxième seuil S2, tel que S2 > S1, la réponse est requête refusée. Sinon la réponse est requête acceptée. 5 Dans notre exemple plus le score est bas, plus la requête a de chance d'être jugée acceptable. Il est possible de mettre en oeuvre l'invention sur le principe inverse, c'est-à-dire qu'il faille le score le plus élevé possible pour que la requête soit acceptée. Avec l'invention le délai de réponse du serveur 101 dépend du 10 medium utilisé pour soumettre la requête. Mais les requête de mise à jour restent dans la mémoire 107 même après que le serveur 101 ait répondu au système requérant. Cela signifie que leur score évolue, jusqu'à ce que la requête soit sortie de la mémoire 107 par le mécanisme de "collecte d'ordures". Au moment où une requête est sortie de la mémoire 107 par ce 15 mécanisme le score "final" de la requête est analysé pour déterminer s'il y a lieu d'enregistrer cette requête dans la mémoire 108. Cela est particulièrement intéressant dans les cas suivants : - requêtes multiples et successives d'une même personne mal intentionnée parcourant plusieurs points de vente dans la journée, 20 - requêtes multiples et successives d'une même personne mal intentionnée à partir d'Internet même si ces requêtes sont espacées dans le temps car dans ce cas le serveur s'accorde plus de temps pour répondre à la requête. Dans ces deux cas le serveur 101 qui prend la décision de 25 classification de la requête de mise à jour a encore à sa disposition l'ensemble des requête et garde donc la possibilité d'agir sur une grande partie de la fraude liée à la personne malintentionnée. La mémoire 107 permet aussi de détecter des flots de demande similaires reçues sur un faible intervalle de temps, par exemple moins de 30 deux jours, et de provoquer une demande de garanties supplémentaires pour ces demandes si elle sont issues d'Internet. Le procédé selon l'invention permet aussi de lever simplement, via une règle d'interrogation d'un système de facturation, le problème lié au rejet systématique du énième abonnement, celui de trop, lié à une même adresse 35 de facturation. En effet si le client est bon payeur, le traitement de la réponse 2910659 15 de la règle d'interrogation n'augmentera pas le score de la requête de mise à jour pour la souscription du énième abonnement. De manière évidente le fait d'émettre une réponse positive vers le système requérant provoque aussi la mise à jour du système informatique 5 protégé par le serveur 101. REVENDICATIONS 1- Procédé de protection contre au moins une intrusion dans un système informatique, intrusion réalisée via au moins une requête de mise à jour d'une base de données dudit système informatique, ledit procédé de protection comportant une étape de validation de la requête, procédé caractérisé en ce que l'étape de validation comporte les étapes suivantes mises en oeuvre par un dispositif de validation : - enregistrement (202) de la requête de mise à jour dans une table de 10 travail, - production et enregistrement (205) dans une table de règles d'une liste planifiée de règles relatives à la requête et que doit valider la requête pour être déclarée valide, - évaluation planifiée (208) des règles présentes dans la table de 15 règles pour produire une réponse à la requête de mise à jour, - prise en compte (208) de la requête de mise à jour en fonction de l'évaluation des règles. 2 - Procédé selon la revendication 1, caractérisé en ce que la réponse à une requête de mise à jour est parmi le groupe de réponse formé d'au 20 moins : - mise à jour acceptee, - mise à jour refusée, et - demande d'au moins une garantie supplémentaire. 3 - Procédé selon l'une des revendications 1 ou 2, caractérisé en ce 25 que l'une des règles produites fixe un délai maximal pour la production d'une réponse à la requête de mise à jour. 4 - Procédé selon l'une des revendications 1 à 3, caractérisé en ce qu'une requête de mise à jour refusée est enregistrée (206) dans une base de données de requêtes frauduleuses. 30 5 - Procédé selon la revendication 4, caractérisé en ce qu'il comporte une étape préliminaire d'évaluation de similarité (203) avec des requêtes frauduleuses connues dans la base de données de requête frauduleuse, un degré de similarité élevé avec au moins l'une de ces requêtes connues conduisant à un rejet de la requête. 35 6 - Procédé selon l'une des revendications 1 à 5, caractérisé en ce 2910659 17 que l'évaluation d'une règle a pour résultat l'enregistrement (211) d'au moins une nouvelle règle dans la table de règles, la nouvelle règle étant relative à la même requête de mise à jour que la règle dont l'évaluation a conduit à l'enregistrement de la nouvelle règle. 5 7 - Procédé selon l'une des revendications 1 à 6, caractérisé en ce que l'évaluation d'une règle a pour effet la modification (210) d'une estimation chiffrée de risque associée à la requête de mise à jour liée à la règle évaluée, l'estimation devant être correctement située relativement à un seuil prédéterminé pour que la requête soit acceptée. 8 - Procédé selon l'une des revendications 1 à 7, caractérisé en ce qu'au moins une règle de la liste de règles est choisie aléatoirement parmi des règles applicables à la requête de mise à jour. 9 - Procédé selon l'une des revendications 1 à 8, caractérisé en ce que l'évaluation d'une règle provoque l'émission d'une requête d'interrogation vers un système tiers, la prise en compte de la réponse à cette requête d'interrogation faisant partie de l'évaluation de la règle. 10 - Procédé selon l'une des revendications 1 à 9, caractérisé en ce qu'il comporte une étape de production et d'enregistrement de statistiques relatives à au moins une caractéristique de la requête, ces statistiques étant utilisées par les règles servant à l'évaluation de la requête de mise à jour.