FR3135337A1 - Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers - Google Patents

Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers Download PDF

Info

Publication number
FR3135337A1
FR3135337A1 FR2204382A FR2204382A FR3135337A1 FR 3135337 A1 FR3135337 A1 FR 3135337A1 FR 2204382 A FR2204382 A FR 2204382A FR 2204382 A FR2204382 A FR 2204382A FR 3135337 A1 FR3135337 A1 FR 3135337A1
Authority
FR
France
Prior art keywords
network
interest
party
toxic
flows
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.)
Pending
Application number
FR2204382A
Other languages
English (en)
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.)
Serenicity
Original Assignee
Serenicity
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 Serenicity filed Critical Serenicity
Priority to FR2204382A priority Critical patent/FR3135337A1/fr
Priority to FR2205294A priority patent/FR3135335A1/fr
Priority to FR2303672A priority patent/FR3135336A1/fr
Publication of FR3135337A1 publication Critical patent/FR3135337A1/fr
Pending legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F21/00—Security arrangements for protecting computers, components thereof, programs or data against unauthorised activity
    • G06F21/50—Monitoring users, programs or devices to maintain the integrity of platforms, e.g. of processors, firmware or operating systems
    • G06F21/55—Detecting local intrusion or implementing counter-measures
    • G06F21/554—Detecting local intrusion or implementing counter-measures involving event detection and direct action
    • 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/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • 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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/08—Access security
    • H04W12/088—Access security using filters or firewalls
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04W—WIRELESS COMMUNICATION NETWORKS
    • H04W12/00—Security arrangements; Authentication; Protecting privacy or anonymity
    • H04W12/12—Detection or prevention of fraud
    • H04W12/121—Wireless intrusion detection systems [WIDS]; Wireless intrusion prevention systems [WIPS]

Landscapes

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

Abstract

L’invention propose de détecter les flux toxiques générés sur chaque réseau tiers connecté au réseau d’intérêt et d’analyser la nature des flux toxiques détectés afin de transmettre uniquement une alerte à un administrateur du réseau d’intérêt lorsque des flux toxiques détectés sont potentiellement préjudiciables pour le réseau d’intérêt.

Description

METHODE D’ANALYSE DU RISQUE INFORMATIQUE D’UN RESEAU D’INTERET LIE AUX ECHANGES AVEC AU MOINS UN RESEAU TIERS
L’invention concerne une méthode permettant de détecter les risques informatiques qui pourraient être engendrés sur un réseau d’intérêt en raison des flux réseau échangés entre ce réseau d’intérêt et au moins un réseau tier, dont on ne connait pas nécessairement le niveau de sécurité informatique. Par exemple, le réseau d’intérêt peut correspondre à un réseau d’une société, d’une administration ou d’une université, et le réseau tiers peut correspondre au réseau d’un sous-traitant direct ou indirect, ou un organisme collaborant avec la société, l’administration ou l’université.
De nos jours, un grand nombre d’organismes ont désormais une politique efficace de sécurité informatique. Cependant, d’autre organismes n’ont pas toujours les moyens financiers, l'intérêt ou même la motivation d'assurer une sécurité informatique minimum. Or, la collaboration croissante des organismes impose un grand nombre d’échanges entre les sociétés, les administrations ou encore les universités. Lors de ces échanges, les organismes utilisant une politique de sécurité informatique stricte sont inquiets de la résilience des systèmes d’information de leurs sous-traitants ou collaborateurs face aux attaques informatiques.
Dans le cadre de l’invention, il est possible de distinguer deux types de réseaux, le réseau d’intérêt et les réseaux tiers. Le réseau d’intérêt correspond typiquement au réseau d’un organisme utilisant une politique de sécurité informatique stricte et pour lequel un administrateur réseau souhaite estimer le risque informatique lié aux échanges avec des réseaux externes, appelés réseaux tiers. Ces réseaux tiers correspondent classiquement à des réseaux informatiques de sous-traitants, directs ou indirects ou de collaborateurs.
Pour analyser un risque informatique d’un réseau, la société SERENICITY propose des dispositifs appelés «Detoxio», «Probio» et «Cymealog» intégrants un organe de supervision des flux réseau entrants et sortants de chaque périphérique depuis et vers Internet. Tel que décrit dans le brevet FR2006068, en comparant les adresses IP des flux réseau avec une base de données comportant une liste d’adresses IP toxiques, il est possible de détecter des flux réseau toxiques.
Cette base de données comportant une liste d’adresses IP toxiques peut être obtenue par une solution de captation d’adresses IP par des serveurs leurres, tel que décrit dans le brevet FR 1852752.
Ensuite, un score de vulnérabilité de chaque périphérique est calculé en appliquant un facteur de dix aux flux toxiques sortants par rapport aux flux toxiques entrants. Ce score de vulnérabilité permet d’identifier et de classer le risque informatique lié à chaque périphérique d’un réseau.
Cette innovation pourrait être déployée directement sur tous les réseaux tiers connectés à un réseau d’intérêt afin qu’un administrateur du réseau d’intérêt puisse vérifier que les réseaux tiers présentent un risque informatique limité. Cependant, avec cette solution, l’administrateur du réseau d’intérêt recevrait un grand nombre d’alertes, notamment lorsque le réseau d’intérêt est connecté à plusieurs réseaux tiers.
Le problème technique de l’invention consiste donc à fournir une alerte à un administrateur d’un réseau d’intérêt concernant le risque informatique lié à au moins un réseau tiers connecté au réseau d’intérêt, tout en limitant le nombre d’alertes et sans dégrader la pertinence des alertes.
Pour résoudre ce problème technique, l’invention propose de détecter les flux toxiques générés sur chaque réseau tiers connecté au réseau d’intérêt et d’analyser la nature des flux toxiques détectés afin de transmettre uniquement une alerte à un administrateur du réseau d’intérêt lorsque des flux toxiques détectés sont potentiellement préjudiciables pour le réseau d’intérêt.
Par exemple, si un réseau tiers subit une attaque par déni de service de son site Internet, ce type d'attaque informatique est préjudiciable pour les activités commerciales du réseau tier, mais ne remet pas en cause la sécurité informatique du réseau d’intérêt.
Au contraire, si le réseau tiers subit une attaque par prise de contrôle à distance d'un poste et que ce poste est couramment utilisé pour échanger des informations avec le réseau d’intérêt, ce type d'attaque peut présenter un risque informatique préjudiciable pour le réseau d’intérêt.
Pour limiter un tel risque informatique, un administrateur du réseau d’intérêt peut imposer aux administrateurs des réseaux tiers de lui transmettre, ou de transmettre à un tiers de confiance comme SERENICITY, les flux réseau captés par leurs pare-feu. Ces pare-feu sont classiquement appelés «firewall» dans la littérature anglo-saxonne.
L’invention propose d’analyser les flux réseau captés par les pare-feu des réseaux tiers, de détecter les flux toxiques parmi l’ensemble de ces flux réseau et la nature des échanges associés à ces flux toxiques afin de détecter les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt.
Ainsi, l’invention permet d’alerter un administrateur du réseau d’intérêt dans le cas où une attaque informatique détectée sur un réseau tiers peut atteindre à la sécurité du réseau d’intérêt.
Au sens de l’invention, un flux toxique correspond à un flux provenant ou à destination d'une adresse IP toxique, c'est-à-dire d'une adresse IP référencée dans une base de données et associée à un pirate informatique ou présentant un risque de vulnérabilité fort. Cette base de données est classiquement constituée et mise à jour régulièrement par des acteurs de la sécurité informatique. Elle peut être téléchargée périodiquement et stockée en interne ou consultée sur une plateforme externe. Cette base de données est préférentiellement obtenue par des serveurs leurres permettant de capter des adresses IP toxiques, tel que décrit dans le brevet FR 1852752.
La illustre un exemple d’architecture réseau dans lequel l’invention peut être implémentée. Dans cet exemple, plusieurs réseaux20,30,40et50communiquent entre eux. Plus précisément, le réseau20échange des flux réseau11aavec les réseaux30et40alors que le réseau50échange des flux réseau11bavec le réseau40. Le réseau20peut correspondre au réseau d’une grande société, alors que les réseaux30et40sont les réseaux de sous-traitants directs de cette grande société, et que le réseau50est un réseau d’un sous-traitant indirect. Au sens de l’invention, le réseau20correspond au réseau d’intérêt alors que les réseaux30,40et50sont des réseaux tiers, directs ou indirects.
Par exemple, le réseau tiers30peut correspondre au réseau d’un prestataire en charge de gérer les différentes imprimantes du réseau d’intérêt20, notamment pour déployer à distance les mises à jour de celles-ci.
Pour ce faire, le prestataire utilise un serveur31du réseau tiers30pour se connecter à un périphérique2 4du réseau d’intérêt20. L’invention vise notamment à vérifier qu’une attaque informatique réalisée sur le réseau tiers30ne puisse entraîner une vulnérabilité du réseau d’intérêt20par l’intermédiaire des flux réseau existants11aentre le réseau tiers30et le réseau d’intérêt20.
Le réseau tiers40peut correspondre au réseau d’un prestataire en charge de la gestion des postes téléphoniques25des différents bureaux du réseau d’intérêt20.
Pour ce faire, le prestataire utilise un serveur41du réseau tiers40pour se connecter aux postes téléphoniques2 5du réseau d’intérêt20. L’invention vise également à vérifier qu’une attaque informatique réalisée sur le réseau tiers40ne puisse entraîner une vulnérabilité du réseau d’intérêt20par l’intermédiaire des flux réseau existants11aentre le réseau tiers40et le réseau d’intérêt20.
Le réseau tiers50peut correspondre au réseau d’un prestataire en charge de la gestion de systèmes de climatisation44connectés du réseau tiers40. Pour ce faire, des flux réseau11bsont générés entre un serveur51du réseau tiers50et les systèmes de climatisation44du réseau tiers40. En ce qui concerne les réseaux tiers indirects, l’invention peut également être implémentée pour vérifier qu’une attaque informatique réalisée sur le réseau tiers50ne puisse entraîner une vulnérabilité du réseau tiers40et propager la vulnérabilité sur le réseau d’intérêt20, par l’intermédiaire des flux réseau11 aet11 b.
Par ailleurs, chaque réseau tiers30,40et50est protégé par un pare-feu dédié32,42et52, géré classiquement par plusieurs administrateurs réseau distincts. Ces pare-feu32,42et52intègrent des fichiers de contrôle33,43,53permettant de retracer un historique des flux réseau11a,11btraversant le pare-feu. Ces fichiers de contrôle33,43,53sont également appelés « logs » dans la littérature anglo-saxonne.
Tel qu’illustré sur la , les pare-feu32,42, et52des réseaux tiers30,40,50sont en outre configurés pour transmettre les fichiers de contrôle33,43,53. Ces fichiers de contrôle33,43,53peuvent être transmis à un administrateur du réseau d’intérêt20ou à un tiers de confiance. Pour ce faire, un message sécurisé directe12apeut être transmis entre les pare-feu32,42et un organe d’analyse61d’un réseau60du tiers de confiance.
Pour le réseau tiers indirect50, le pare-feu52peut être configuré pour transmettre le fichier de contrôle53directement au tiers de confiance60, ou indirectement en passant par un administrateur du réseau tiers40auquel il est connecté.
Dans l’exemple de la , un message sécurisé12best transmis entre le pare-feu52et un organe d’analyse61d’un réseau60du tiers de confiance en passant par le réseau tiers40.
Plus précisément, cet organe d’analyse61parcours les fichiers de contrôle33,43,53, détecte des flux toxiques parmi l’ensemble des flux réseau présents dans ces fichiers de contrôle33,43,53et recherche la nature des échanges associés à ces flux toxiques afin de détecter les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt20. Lorsqu’au moins un flux toxique potentiellement préjudiciable pour le réseau d’intérêt20est détecté, l’organe d’analyse61génère une alerte13à destination d’un administrateur du réseau d’intérêt20. Cette alerte13peut contenir des informations contextualisées en fonction des besoins de l’administrateur du réseau d’intérêt20.
Un exemple de mise en place de la méthode d’analyse du risque informatique est décrit en référence à la . Dans une première étape10 0, le tiers de confiance ou un administrateur du réseau d’intérêt20récupère les flux réseau captés par au moins un pare-feu32,4 2,5 2appartenant à un réseau tiers30,40,50, par exemple en recevant les fichiers de contrôle33,43,53des pare-feu3 2,4 2,5 2. Ces fichiers de contrôle33,43,53contiennent classiquement un ensemble de flux réseau avec, pour chaque flux réseau, au moins :
- une adresse IP de provenance ;
- une adresse IP de destination ;
-un sens de trafic du flux ;
- un type de port utilisé pour la connexion ; et
- un horodatage du flux réseau, typiquement la date et l’heure de début et de fin du flux réseau.
Lorsque les flux réseau des réseaux tiers sont récupérés, chaque adresse IP de destination et de provenance est comparée, une à une, à la base de données comprenant les adresses IP toxiques64, dans une étape101. Chaque flux réseau lié à une adresse IP toxique est alors stocké dans un fichier de flux toxique63intégrant, pour chaque période de temps, par exemple pour chaque jour ou pour chaque heure, l’ensemble des flux toxiques.
Ensuite, dans une étape102, l’identification de la nature du risque est effectuée pour détecter si chaque flux toxique présente un risque pour la sécurité informatique du réseau d’intérêt20ou simplement pour la sécurité informatique d’un réseau tiers30,40,50.
Pour ce faire, l’organe d’analyse61tente de caractériser chaque type d’attaque informatique sur la base de scénarii utilisant des informations obtenues à partir des flux toxiques détectés.
Par exemple, une attaque de type « force brute » peut être caractérisée lorsque plusieurs flux toxiques sont détectés dans des intervalles de temps très proches, typiquement si la même adresse IP toxique à communiqué avec la même adresse IP attaquée plus de deux cent fois dans la même journée.
De plus, les heures d’attaques peuvent être utilisées comme indice pour caractériser les attaques de type « compromission », par exemple la compromission d’un système de fermeture de porte. Typiquement, si une adresse IP toxique communique avec un système de fermeture de porte en dehors des heures habituelles, alors l’organe d’analyse61peut catégoriser une attaque de type « compromission ».
Il est également possible d’utiliser des informations connues sur l’adresse IP toxique détectée, telles que le type d’attaque généralement associées à cette adresse IP toxique détectée. Ces informations peuvent être intégrées dans la base de données d’adresses IP toxiques ou accessibles sur un serveur externe. Par exemple, s’il est connu que l’adresse IP toxique détectée est basée sur un complexe militaire, il est possible de caractériser le type d’attaque informatique comme une attaque de type « militaire ». Selon un autre exemple, s’il est connu que l’adresse IP toxique détectée héberge un nœud du réseau Tor, permettant d’accéder au réseau internet connu sous le nom de «DarkNet», alors il est possible de caractériser le type d’attaque informatique comme une attaque de type « masquée ».
Selon un autre exemple, s’il est connu que l’adresse IP toxique détectée héberge un serveur de commande et contrôle d’un programme malveillant de chiffrement de données, également connu sous les termes «command-and-control» » dans la littérature anglo-saxonne, alors il est possible de caractériser le type d’attaque informatique comme une attaque de type « command center ».
Par ailleurs, les ports utilisés pour les attaques peuvent également permettre de caractériser le type d’attaque. Typiquement, le port TCP/IP « 22 » correspond au port SSH, ou «Secure Shell» dans la littérature anglo-saxonne.
Ce port « 22 » est utilisé pour prendre le contrôle des machines distantes. Ainsi, si un pirate informatique arrive à prendre le contrôle d’un périphérique d’un réseau tiers30,40,50, il est possible de caractériser le type d’attaque informatique comme une attaque de type « cheval de Troie ».Ainsi, un grand nombre de scenarii peuvent être implémentés pour caractériser chaque type d’attaque informatique.
A l’aide de cette caractérisation, un grand nombre d’attaques informatiques peuvent être supprimées du fichier de flux toxiques63car elles ne sont pas potentiellement préjudiciables pour le réseau d’intérêt20.
Pour les flux toxiques potentiellement préjudiciables pour le réseau d’intérêt20, une alerte13peut être transmisse à l’administrateur du réseau d’intérêt20, dans une étape103. Pour limiter le nombre d’alertes reçues, l’administrateur du réseau d’intérêt20peut avoir une interface permettant de sélectionner les types d’attaque, par exemple « force brute », « compromission », « militaire », « masquée », « command center » et « cheval de Troie », pour lesquelles il souhaite recevoir une alerte13.
Ainsi, si une attaque de type « force brute » est caractérisée dans l’étape102et que l’administrateur ne souhaite pas recevoir ce type d’information, alors aucune alerte ne sera transmise à l’administrateur du réseau d’intérêt20.
Cette alerte13peut prendre différentes formes en fonction des besoins de l’administrateur du réseau d’intérêt20. Par exemple, l’alerte13peut être affichée sur une carte en utilisant la géolocalisation de l’adresse IP toxique détectée, de l’adresse IP attaquée ou encore d’une adresse IP du réseau d’intérêt20qui a communiqué avec l’adresse IP attaquée. En outre, chaque alerte13peut présenter une forme différente en fonction de la nature de l’attaque.
Ainsi, à la réception de l’alerte13, l’administrateur du réseau d’intérêt20peut facilement voir les réseaux tiers30,40,50directement ou indirectement attaqués, le type d’attaque que ces réseaux ont subi et le sens de trafique du flux de ces attaques.
Pour conclure, l’invention permet de fournir une alerte13à un administrateur d’un réseau d’intérêt20concernant le risque informatique lié à au moins un réseau tiers30,40,50connecté directement ou indirectement au réseau d’intérêt20. Par ailleurs, l’invention propose également de limiter les informations transmises à l’administrateur du réseau d’intérêt20afin de lui transmettre uniquement des alertes13pertinentes. En recevant une ou plusieurs adresses IP du réseau d’intérêt20pour lesquelles il existe un risque informatique, l’administrateur peut agir en conséquence. Par exemple, il peut mener des investigations et éventuellement déconnecter un périphérique du réseau.

Claims (1)

  1. [néant]
FR2204382A 2022-05-09 2022-05-09 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers Pending FR3135337A1 (fr)

Priority Applications (3)

Application Number Priority Date Filing Date Title
FR2204382A FR3135337A1 (fr) 2022-05-09 2022-05-09 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
FR2205294A FR3135335A1 (fr) 2022-05-09 2022-06-01 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
FR2303672A FR3135336A1 (fr) 2022-05-09 2023-04-13 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR2204382A FR3135337A1 (fr) 2022-05-09 2022-05-09 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
FR2204382 2022-05-09

Publications (1)

Publication Number Publication Date
FR3135337A1 true FR3135337A1 (fr) 2023-11-10

Family

ID=88649305

Family Applications (2)

Application Number Title Priority Date Filing Date
FR2204382A Pending FR3135337A1 (fr) 2022-05-09 2022-05-09 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
FR2205294A Pending FR3135335A1 (fr) 2022-05-09 2022-06-01 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers

Family Applications After (1)

Application Number Title Priority Date Filing Date
FR2205294A Pending FR3135335A1 (fr) 2022-05-09 2022-06-01 Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers

Country Status (1)

Country Link
FR (2) FR3135337A1 (fr)

Also Published As

Publication number Publication date
FR3135335A1 (fr) 2023-11-10

Similar Documents

Publication Publication Date Title
US20230216880A1 (en) Network appliance for vulnerability assessment auditing over multiple networks
JP7250703B2 (ja) 相関関係駆動型脅威の評価と修復
US8572733B1 (en) System and method for active data collection in a network security system
US7325252B2 (en) Network security testing
US10505959B1 (en) System and method directed to behavioral profiling services
Nawrocki et al. Uncovering vulnerable industrial control systems from the internet core
EP2215801A2 (fr) Procede de securisation d'un canal bidirectionnel de communication et dispositif de mise en oeuvre du procede.
EP1733539A1 (fr) Dispositif et procede de detection et de prevention d intrus ion dans un reseau informatique
WO2010076470A1 (fr) Systeme d'adaptation pour interception legale dans differents reseaux de telecommunications
WO2011083226A1 (fr) Procédé de détection d'un détournement de ressources informatiques
FR2888695A1 (fr) Detection d'une intrusion par detournement de paquets de donnees dans un reseau de telecommunication
FR3135337A1 (fr) Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
EP3205068B1 (fr) Procede d'ajustement dynamique d'un niveau de verbosite d'un composant d'un reseau de communications
FR3135336A1 (fr) Methode d’analyse du risque informatique d’un reseau d’interet lie aux echanges avec au moins un reseau tiers
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
FR3111443A1 (fr) Dispositif d’analyse du risque informatique d’un ensemble de périphériques connectés sur un réseau
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
EP4184868A1 (fr) Technologie de déception basée sur le cloud utilisant la confiance zéro pour identifier les renseignements sur les menaces, la télémétrie et les tactiques et techniques émergentes des adversaires
EP2773067B1 (fr) Procédé de fiabilisation de la génération de messages d'alerte sur un réseau synchronisé de données
US20240114036A1 (en) Systems and methods for identifying security requirements in a ztna system
EP3035639B1 (fr) Procédé de détection de balayage de ports non-autorisé dans un réseau informatique, produit programme d'ordinateur et dispositif associés
Cukier et al. A Comparison between Internal and External Malicious Traffic
WO2006066315A1 (fr) Systeme de surveillance d'un reseau de communications, procede et appareil correspondants
Samalekas Network Forensics: Following the Digital Trail in a Virtual Environment
FR3127352A1 (fr) Dispositif de gestion temporelle de transfert de trames de données d’un émetteur vers au moins un récepteur