Method for monitoring data traffic in a communication system

Abstract

The invention relates to a method for monitoring data traffic between clients and servers, implemented by a monitoring device, comprising: collecting observation data of current traffic between clients and servers; performing, using an automatic traffic anomaly detection module, named M6, an analysis of at least a portion of the collected current observation data specifically corresponding to the O6 type of observation angle specific to traffic between a single given group of clients and a single given group of servers; performing, using another separate automatic traffic anomaly detection module, M7, an analysis of at least a portion of the collected current observation data specifically corresponding to the O7 type of observation angle specific to traffic between all given clients and all given servers. Figure for the abstract: Fig. 2

Description

Title of the invention: Method for monitoring data traffic in a communication system technical field

[0001] The invention lies in the field of cybersecurity and the monitoring of data transmission networks. More specifically, it relates to anomaly detection techniques based on traffic analysis in a client / server type communication system. Previous technique

[0002] Effectively monitoring client-server interactions can prove difficult. First, user behavior (from client devices) is heterogeneous and can also vary over time, making it doubly difficult to detect a genuine deviation without triggering false alarms, since establishing a "normal" behavior profile for all users is therefore complex and imprecise. On the other hand, implementing a per-user monitoring system capable of tracking and understanding individual behavior to detect any anomaly proves extremely costly in terms of computing power (and time), especially when the number of users is high.

[0003] The same problem arises with regard to the resources made available by the servers. Monitoring how a resource is used by all users does not easily allow for the detection of anomalies, as it can be used in different ways depending on each user's needs. Furthermore, changes in how a user uses a resource do not necessarily mean there is an anomaly, but simply that their usage pattern has changed while remaining within normal limits. Taking this change into account for all users using the resource risks making anomaly detection difficult and prone to false alarms. Moreover, monitoring per resource can also be very costly, as it requires analyzing all interactions with each resource in detail, which can quickly become unmanageable for a large number of resources.

[0004] Document CN116781431 proposes a solution in which each API (Application Programming Interface) call is considered a data point, with the various characteristics of the API call (traffic value, time, source IP address, destination IP address, destination port, frequency, etc.) being the dimensions of that point. Clustering analysis aims to group similar points together and determine a "normal" behavior for a cluster. It is envisaged that this solution will be applied. separately on different aspects of traffic such as individual APIs, user accounts (in terms of APIs called and frequency of calls), parameters of requests sent to each API (the data sent in the requests such as user IDs, dates, amounts, etc., depending on the function of the API), which allows us to establish references of normal behavior specific to each of these levels.

[0005] Despite its advantages, the solution according to CN116781431 nevertheless has several drawbacks. CN116781431 applies point clustering by considering APIs, user accounts, and request parameters separately. This can reveal trends but does not take into account the relationships between these aspects, nor does it allow for a comprehensive consideration of the heterogeneity of behaviors. In particular, anomalies resulting from specific user / API combinations may thus go undetected.

[0006] For example, considering an application with several APIs and many users, each user may have their own way of interacting with each API: - a user A calls API 1 very frequently, but never uses API 2; - a user B calls API 1 and API 2, usually in a balanced way, but sometimes API 2 more frequently; - A user C rarely calls API 1, but when they do, they send unusual parameters.

[0007] Thus: - if user A suddenly starts calling API 2 frequently, it is probably abnormal for that user, even if it does not seem abnormal for API 2 in general, because user B sometimes calls it frequently; - If user C calls API 1 with unusual parameters, this is suspicious, even if the call frequency seems normal for that user.

[0008] These anomalies specific to certain user / API combinations can go unnoticed because they do not appear abnormal when each aspect is viewed in isolation. Furthermore, the method offers little flexibility in the granularity of the analysis, focusing on only one aspect at a time that combines the three parameters: (API, account, parameter). It does not allow monitoring at intermediate levels such as groups of users or APIs with similar usage patterns.

[0009] There is therefore a need for an effective monitoring solution to detect anomalies and malicious users, to identify vulnerable resources, and which also allows for the optimization of monitoring according to the context while adapting to the different security needs and the processing resources available to perform this monitoring. Summary of the invention

[0010] To this end, according to a first aspect, the present invention describes a method for monitoring data traffic in a communication system between clients and servers,

[0011] according to which, in a prior phase, groups of clients and / or groups of servers having been defined, and several distinct modules among automatic traffic anomaly detection modules M1, M2, ..., M7, each distinct module Mi having been designed, in a prior phase, based on traffic observation data from a historical database specifically corresponding to a single respective type Oi of traffic observation angles among the following:

[0012] type 01 of observation angle specific to the traffic between a single given client and a single given server, the Ml module being adapted to detect anomalies specifically in this traffic;

[0013] type 02 of observation angle specific to the traffic between a single given client and a given group of servers, the M2 module being adapted to detect anomalies selectively in this traffic;

[0014] type 03 of observation angle specific to the traffic between a single given client and all the servers, the M3 module being adapted to detect anomalies specifically in this traffic;

[0015] type 04 of observation angle specific to the traffic between a single given group of clients and a single given server, the M4 module being adapted to detect anomalies selectively in this traffic;

[0016] type 05 of observation angle specific to the traffic between all clients and a single given server, the M5 module being adapted to detect anomalies specifically in this traffic;

[0017] type 06 of observation angle specific to the traffic between a single given group of clients and a single given group of servers, the M6 ​​module being adapted to detect anomalies specifically in this traffic;

[0018] type 07 of observation angle specific to the traffic between the given set of clients and the given set of servers, the M7 module being adapted to detect anomalies specifically in this traffic;

[0019] said method comprising the following steps implemented by an electronic data traffic monitoring device, in operational phase: - collect observational data on current traffic between clients and servers; - to perform, using one of said separate automatic traffic anomaly detection modules, named Mi, an analysis of at least part of the current observational data collected and specifically corresponding to the type Oi of observation angle considered; - to perform, using another of said separate automatic traffic anomaly detection modules, Mj, j^i, an analysis of at least part of the current observation data collected and corresponding specifically to the type Oj of observation angle considered.

[0020] The invention thus provides a solution for monitoring client-server interactions within a client-server ecosystem. It is based on observation angles, which are defined as specific analytical perspectives in data analysis. These observation angles range from a broader view, covering, for example, the entire network, to a more detailed view targeting specific client-server interactions. They are configured based on clusters of clients and servers exhibiting similar behaviors and characteristics. A dedicated anomaly detection model is obtained for each angle. The monitoring system can, for example, dynamically switch from one angle to another depending on the context and requirements, thus providing adaptive and optimized monitoring.The proposed approach makes it possible to effectively detect different types of anomalies and attacks, while also allowing, where necessary, adaptation to the context, in particular to the processing resources available to implement monitoring and the required level of security, to focus monitoring efforts on the most critical elements.

[0021] In embodiments, such a method will further comprise at least one of the following features:

[0022] - analysis by the Mj module for automatic traffic anomaly detection corresponding specifically to the type Oj of observation angle considered is triggered at the end of a first period of analysis by the Mi module for automatic detection of traffic anomalies corresponding specifically to the type Oi of observation angle;

[0023] - said triggering is performed based on at least one of the events among :

[0024] - an anomaly detected by the Mi module;

[0025] - a variation in the availability of processing resources available for implement traffic monitoring;

[0026] - a variation in a volume of traffic to be monitored;

[0027] - a variation in the level of security required in the system;

[0028] - N client groups having been defined and M server groups having been defined, said separate automatic detection modules comprise at least N x M M6 modules of type 06 with an observation angle specific to traffic between a single group of a given customer group from among the N customer groups and a unique given server group from among the M server groups, in which the (t+k)th module M6, named M6k, is adapted to detect an anomaly selectively between the given teme customer group, t = 1 to N, and the given keme server group from among the M server groups, k = 1 to M;

[0029] - said separate automatic detection modules further comprise at least an M7 automatic traffic anomaly detection module, i = 7, corresponding to type 07 of observation angle specific to the traffic between the given set of clients and the given set of servers;

[0030] - the current observation data supplied as input to the separate modules are relating to a common time interval and an anomaly is determined to be present or not based on said detection results provided over said common time interval by the separate modules;

[0031] - customer groups are determined according to statistical vectors descriptive statistics calculated for each client from historical baseline traffic observation data, characterizing its behavior; and server groups are determined based on descriptive statistics vectors calculated for each server from historical baseline traffic observation data characterizing how they are used by clients.

[0032] According to another aspect, the invention describes a device for monitoring data traffic in a communication system between clients and servers, according to which, groups of clients and / or groups of servers having been defined, said monitoring device comprises several distinct modules from among automatic traffic anomaly detection modules M1, M2, ..., M7, each distinct module Mi having been designed, in a prior phase, based on traffic observation data from a historical database specifically corresponding to a single respective type Oi of traffic observation angles from among the following:

[0033] type 01 of observation angle specific to the traffic between a single given client and a single given server, the Ml module being adapted to detect anomalies specifically in this traffic;

[0034] type 02 of observation angle specific to the traffic between a single given client and a given group of servers, the M2 module being adapted to detect anomalies selectively in this traffic;

[0035] type 03 of observation angle specific to the traffic between a single given client and all the servers, the M3 module being adapted to detect anomalies specifically in this traffic;

[0036] type 04 of observation angle specific to the traffic between a single given group of clients and a single given server, the M4 module being adapted to detect anomalies selectively in this traffic;

[0037] type 05 of observation angle specific to the traffic between all clients and a single given server, the M5 module being adapted to detect anomalies specifically in this traffic;

[0038] type 06 of observation angle specific to the traffic between a single given group of clients and a single given group of servers, the M6 ​​module being adapted to detect anomalies specifically in this traffic;

[0039] type 07 of observation angle specific to the traffic between the given set of clients and the given set of servers, the M7 module being adapted to detect anomalies specifically in this traffic;

[0040] in which said electronic data traffic monitoring device is adapted to collect observation data of current traffic between clients and servers;

[0041] said electronic data traffic monitoring device is adapted to perform, using one of said separate automatic traffic anomaly detection modules, named Mi, an analysis of at least a part of the current observation data collected and corresponding specifically to the type Oi of observation angle considered;

[0042] said electronic data traffic monitoring device is adapted to perform, using another of said separate automatic traffic anomaly detection modules, Mj, j^i, an analysis of at least a part of the current observation data collected and corresponding specifically to the type Oj of observation angle considered.

[0043] In embodiments, such a device is adapted to trigger the analysis by the automatic traffic anomaly detection module Mj specifically corresponding to the type Oj of observation angle considered at the end of a first period of analysis by the automatic traffic anomaly detection module Mi specifically corresponding to the type Oi of observation angle.

[0044] According to another aspect, the invention describes a computer program product intended to be stored in the memory of a traffic monitoring device and further comprising a microcomputer, said computer program comprising instructions which, when executed on the microcomputer, implement the steps of a process according to the first aspect of the invention.

[0045] The invention also describes a computer-readable recording medium for storing such a computer program. Such recording media may include a storage means, such as a ROM, for example a CD-ROM or a A microelectronic circuit ROM, or a magnetic recording medium, such as a USB flash drive or hard drive, can be used. Such recording media can be transmissible, such as an electrical or optical signal, which can be transmitted via an electrical or optical cable, by radio, or by other means, so that the computer program it contains can be executed remotely. Programs according to the invention can, in particular, be uploaded to a network, such as the Internet. Such recording media may include an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the aforementioned display control method. Brief description of the drawings

[0046] The invention will be better understood and other features, details and advantages will become clearer from the following description, given by way of non-limiting reason, and from the accompanying figures, given by way of example.

[0047] [Fig-1] Fig.1 schematically represents a communication system data implementing a traffic monitoring solution in one embodiment of the invention;

[0048] [Fig.2] The [Fig.2] is a flowchart of the steps of a method for detecting anomalies in an embodiment of the invention;

[0049] [Fig.3] Fig.3 represents the logs taken into account in a sample in an example embodiment of the invention.

[0050] Identical references may be used in different figures when they refer to identical or comparable elements. Description of the implementation methods

[0051] By way of example, in one embodiment of the invention, a client / server communication system 1 represented in [Fig.1] is considered, comprising a set of n clients, which are software applications 10 hosted (and running in) one or more electronic user terminals such as mobile phones, computers ... and adapted to allow their terminal users to consult the resources made available on servers (n typically is equal to or greater than 1, for example greater than 2).The proposed monitoring solution can of course be applied generally to all communications between clients and servers, beyond the specific context of APIs, but to illustrate its application, we will take the example of an API (Application Programming Interface) for online hotel bookings offering services for checking hotel room availability, booking rooms, paying for reservations, and cancelling / modifying reservations.

[0052] Some of the user terminals, and therefore the client applications on these terminals, are used by individuals, others by travel agencies, and still others by business partners.

[0053] An API is a set of rules, protocols and tools enabling communication between different computer systems. It defines the types of requests and data formats used to exchange information between a client (such as a software application 10, such as a web or mobile application on a user terminal) and a server.

[0054] The client applications 10 are thus adapted to exchange with, for example, a set of m entry points 30 (also called "endpoints") of the hotel booking system API (m typically is equal to or greater than 1, for example greater than 2). The endpoints are the specific entry points of the API, and are accessible via respective URLs.

[0055] Each endpoint is identified by a URL, corresponds to a particular functionality and accepts HTTP requests (GET, POST, PUT, DELETE, etc.) to perform associated actions on server resources that are assigned to these actions.

[0056] Here are some examples of API endpoints:

[0057] Hotel search endpoints:

[0058] GET / api / hotels / search: general hotel search

[0059] GET / api / hotels / search / by-location: search for hotels by location

[0060] GET / api / hotels / search / by-rating: search for hotels by rating

[0061] Reservation creation endpoints:

[0062] POST / api / reservations: create a new reservation

[0063] POST / api / reservations / group: create a reservation for a group

[0064] Reservation modification endpoints:

[0065] PUT / api / reservations: modify an existing reservation

[0066] PUT / api / reservations / {reservation_id] / add-room: add a room to a reservation

[0067] The communications considered here are the requests transmitted from client applications 10 running on user terminals to endpoints 30, as well as the responses to these requests sent by the latter via servers. They are carried out over communication networks comprising transport links that can be of various types: wired, wireless (Radio Frequency), or other. The exchanged data passes through a gateway module 20, in this case an API gateway, which analyzes this data traffic, deduces traffic observation data, and transmits it to a traffic monitoring device 40.

[0068] Two main objectives are targeted by the monitoring carried out by the traffic monitoring device 40:

[0069] - monitor the behavior of client applications in order to detect anomalies and identify malicious 'client' / user applications;

[0070] - monitor how endpoints are accessed by users to identify vulnerable endpoints and better secure them.

[0071] In the case considered, the monitoring device 40 is an electronic device comprising in particular an electronic control module 48 and an electronic module for determining the detection modules 50.

[0072] This observation data, which describes the exchanged traffic data, includes, for example, in the case under consideration, logs recording requests between users and resources. In other embodiments, the observation data includes, instead, IP packets circulating on the network, or any other type of data describing communications.

[0073] Figure 2 illustrates the steps of a method for detecting anomalies in communications implemented, for example, in communication system 1 in one embodiment of the invention. This method comprises two phases: a preliminary phase 100 and a production phase 200, both detailed below.

[0074] Preliminary phase

[0075] The main objective of this preliminary phase 100 is to:

[0076] - define observation angles of the exchanges to be monitored, including also the creation of groups (“clusters”) of 10 'client' applications with similar behaviors and groups (“clusters”) of endpoints being used in the same way, and

[0077] - prepare security solutions by defined observation angle.

[0078] The preliminary phase 100 includes a step 101 of collection, by the control module 48, of the data describing the communications and provided by the gateway 20. This collection is carried out, for example, in real time from the network or asynchronously, from a recorded history database.

[0079] In the case considered where this data is in the form of logs that record interactions, the specific information varies depending on the logging method used, but certain essential fields are generally present, including the following fields: - "Timestamp": timestamp of the request; - "http method": type of request (GET, POST, etc.); - "HTTP status code": server response (200, 404, etc.); - "Request duration": time taken by the server to complete the request ; - "Client IP address": identifying IP address, the user's terminal hosting the application from which the request originates; - “User-agent”: information about the browser or tool used by the customer ; - "Geolocation": geographical location of the user's terminal hosting the application from which the request originates; - “Client ID”: unique identifier for each client application; - “Request ID”: request identifier; - URL of the requested endpoint, identifying that endpoint.

[0080] Examples of logs and the contents of these fields are shown in the following table in which each row represents a record and the columns contain the information extracted from each interaction.

[0081] [Tables 1] HTTP status method i?i?ér request: P client User-agent ClisrtF URL itjndpgnt) 1022 U6S®. GET 28$ 250ms tS2.1881.13 Paris.. FR üser123 1622'095 POST «ætM 152 O 1, ! 1 FueiW&FO Lyon.FR user4ô6

[0082] In the case of using IP packets, the usable header fields include: - Source and destination IP addresses - Source and destination port numbers Protocol (TCP, UDP, ICMP...) - Package size Flags (SYN, ACK, FIN...) - TTL (Time-to-Live).

[0083] Other information can be extracted from the payload (payload data, i.e., the data to be transmitted, not header, control, or metadata data) if it is unencrypted. Furthermore, in one embodiment, the capture time is recorded at the time of packet capture, which is particularly useful when the packet header does not contain a timestamp field.

[0084] Still with reference to [Fig.2], in an optional step 102 implemented by the control module 48, this observation data is pre-processed and enriched with business expertise information, for example, by adding fields such as: - function of the endpoint 30 (for example in the case of the service considered here: search, booking...) - role of the user of the user terminal 10 (here for example individual, agency...) HTTP method family: read (GET, HEAD), write (POST, PUT), and delete (DELETE)... - family of status code (success, client error, server error...) indicated by the first digit of the status code (2xx for success, 4xx for client error, 5xx for server error).

[0085] Examples of enriched logs are shown in the following table.

[0086] [Tables2]

[0087] In a step 103, the determination block 50 then defines customer groups 10 and endpoint groups 30.

[0088] In one possible embodiment, client-side groups are defined according to the user role and server-side groups are constituted according to the endpoint function.

[0089] In the embodiment described below, however, the client-side groups grouping together clients (i.e. applications) 10 having similar behaviors and the server-side groups grouping together endpoints requested in the same way are each defined by exploiting the observation data collected in step 101, possibly enriched.

[0090] To determine the groups, a method based on time series is presented below, but other approaches are possible, such as the use of statistics calculated directly on all interactions (total number of interactions, number of resources requested, diversity of requests), the application dimensionality reduction techniques (PCA, t-SNE), density-based clustering (DBSCAN), etc.

[0091] To determine client-side groups, logs are separated by client ID, creating a mini-database for each client. Samples are then created by grouping logs by intervals (e.g., 10-second intervals). Each sample is then characterized by descriptive statistics (frequency, ratio, diversity, measures of central tendency and dispersion) calculated on one or more log fields independently of the recipient URLs. These measures are compiled into a multidimensional time series describing client behavior over time.

[0092] Example of a vector representing a sample for a customer:

[0093] [nb_requetes_10s: 5, ratio_GET_10s: 0.8, ratio_POST_10s: 0.2, diversity_endpoints_10s: 3]

[0094] Time series classification algorithms (of the K-means, DBSCAN, OPTICS, ... type) are then used to create customer groups 10 from these time series of vectors.

[0095] A similar process is applied with respect to endpoints, separating the logs by resource identifier (URL) instead of separating them by client ID, to create groups of 30 endpoints this time (without taking into account, in the calculation of statistics, the originating clients).

[0096] By way of example, it is assumed here that N customer groups 10 and M endpoint groups 30 have been created (in one embodiment, each customer belonging to only one group and each endpoint belonging to only one group).

[0097] The result of clustering based on observed data may differ from, for example, initial clustering based solely on business expertise. Indeed, the analysis of real data may reveal similarities or differences in behavior that were not obvious a priori. For example, two customers considered distinct based on business expertise might actually have very similar behavior on the system. Conversely, customers grouped in the same business category might exhibit very different usage patterns. Taking observed data into account for these groupings therefore makes it possible to refine and correct the initial view of customer and endpoint clusters.

[0098] In step 104, the determination block 50 selects from the LAngi_obs list the observation angle(s) that will be usable during the operational phase, either intermittently or continuously. This selection depends, for example, on the desired security levels or on constraints on the processing resources (CPU, memory) that will be available for monitoring.

[0099] The different types of observation angles are described below, each with its advantages and disadvantages, and allowing for the more or less effective detection of certain types of attacks and anomalies. The concept of observation angle defines what one wishes to monitor in detail and with precision in a system, because although observing all interactions between user terminals and resources (here, the endpoints), and then performing statistical analysis to detect anomalies may seem interesting, this approach remains crude and can lead to several problems.

[0100] Observation angle type O1: a client <-> an endpoint

[0101] Considering a given client among n clients and a given endpoint among m endpoints, this type of observation angle 01 focuses observation on "how this client (of type application) interacts with this endpoint." This observation angle allows for very fine and detailed monitoring of this client's interactions with this resource. It facilitates the detection of anomalies specific to a client or resource, such as SQL injection attempts or brute-force attacks. However, it can be very costly in terms of resources and computation time, especially for a large number of clients and resources.

[0102] In this case, there are therefore n*m ​​possible observation angles of type 01; they can all be selected at step 104 or only one or some of them (or even none when the type of observation angle 01 is not desired).

[0103] Observation angle type 02: one client <-> one group of endpoints

[0104] In an observation angle of type 02, it is specifically observed how a given client interacts with a given group of endpoints. This allows for more targeted monitoring of that client's interactions with a specific group of resources, such as endpoints related to authentication or payments. However, it is less precise than 01.

[0105] In this case, there are therefore n*M possible observation angles of type 02; they can all be selected at step 104 or one or only some of them (or even none when the type of observation angle 02 is not desired).

[0106] Observation angle type 03: one client <-> all endpoints

[0107] In an observation angle of type 03, it is specifically observed how a given client interacts with all endpoints combined. This approach provides an overview of a client's behavior on the system, which facilitates the detection of global anomalies. However, it is less precise than 01 and 02, and may miss anomalies specific to certain endpoints.

[0108] In the present case, there are therefore n possible observation angles of type 03; they can all be selected at step 104 or only some of them (or even none when the type of observation angle 03 is not desired).

[0109] Observation angle type 04: a group of clients <-> an endpoint

[0110] In an observation angle of type 04, it is specifically observed how a given group of clients interacts with a given endpoint. This type of observation angle 04 makes it possible to identify the endpoints most frequently used by a group of clients (or several groups of clients) and to detect abnormal usage patterns. For example, if a group of clients with a limited role in the system suddenly begins to access a specific endpoint intensively, this may indicate an attempt at unauthorized access or a security vulnerability being exploited by that group. It is less precise than 01, but more focused on resource protection than 02 and 03 (more so than on identifying malicious users).

[0111] In this case, there are therefore N*m possible observation angles of type 04; they can all be selected at step 104 or only some of them (or even none when the type of observation angle 04 is not desired).

[0112] Observation angle type 05: the set of clients <-> an endpoint

[0113] In an observation angle of type 05, it is specifically observed how all clients, as a whole, interact with a given endpoint. This provides an overview of the use of each resource by all clients and facilitates the detection of global anomalies, such as a sudden increase in the number of requests to a specific endpoint, which could indicate a targeted attack. However, it may miss anomalies specific to certain clients (and users) or groups of clients, as it is less precise than 04.

[0114] In the present case, there are therefore m possible observation angles of type 05; they can all be selected at step 104 or only one or some of them (or even none when the type of observation angle 05 is not desired).

[0115] Observation angle type 06: a group of clients <-> a group of endpoints

[0116] In an observation angle of type 06, it is specifically observed how a given group of clients interacts with a given group of endpoints. This type of observation angle offers a good compromise between granularity and performance, by focusing on coherent sets of clients (and therefore users, for example) and endpoints.

[0117] In this case, there are therefore N*M possible observation angles of type 06; they can all be selected at step 104 or only one or some of them (or even none when the type of observation angle 06 is not desired).

[0118] Observation angle type 07: all clients <-> all endpoints

[0119] In the 07 type observation angle, it is observed how all clients interact with all endpoints combined. This method provides an overview of the overall system behavior and facilitates the detection of anomalies. general threats, such as denial-of-service attacks, may miss many anomalies specific to certain clients, client groups, endpoints, or endpoint groups.

[0120] There is therefore only 1 observation angle of type 07, which is selected or not in step 104 depending on whether the type of observation angle 07 is desired or not).

[0121] In the example considered here, at step 104, all the observation angles of each type 01, 02, ..., 07 are selected.

[0122] In step 105, for each of the selected observation angles, the determination block 50 designs an anomaly detection module specifically adapted to that observation angle, based on observation data collected in step 101 and specifically corresponding to said respective observation angle. These dedicated detection models make it possible to characterize normal behavior in detail, learn subtle usage patterns, and effectively detect deviations, thus minimizing false alarms.

[0123] To create such a detection module, a specific observation database is created for each observation angle. Data relating to clients and endpoints not part of the observation angle are not included in it.

[0124] Typically, data samples are created specifically from observational data in the specific database by grouping logs into a sample by time interval (e.g., 10-second intervals). Each sample is then characterized by descriptive statistics (frequency, ratio, diversity, measures of central tendency and dispersion) calculated on one or more fields of the logs. These measurement vectors are assembled into a multidimensional time series describing the behavior over time of an interaction of either a customer with an endpoint (01), or a customer with a group of endpoints (02), or a customer with all endpoints (03), or a group of customers with an endpoint (04), or all customers with an endpoint (05), or a group of customers with a group of endpoints (06), or all customers with all endpoints (07).

[0125] In the case of a database specific to an observation angle of type 04 (a group of clients <-> an endpoint), a sample will group the logs from several clients of said group and from the single endpoint. In the case of a database specific to an observation angle of type 02 (a client <-> a group of endpoints), a sample will group logs relating to said single client, but to several endpoints of said group of endpoints.

[0126] And the detection module specifically adapted to an observation angle is created from the specifically constructed observation database, typically from statistical feature vectors. There are different techniques for designing the detection module, depending in particular on the detection method chosen: Artificial intelligence, statistics, expert rules, etc.). If the method used to distinguish between normal and abnormal behavior is based on AI (Artificial Intelligence), this phase will involve training a model by angle, using the specific database. If it relies on signature detection, it will be necessary to define these signatures, using the specific database. This will involve, for example, identifying statistical thresholds characterizing normal behavior (e.g., a threshold for the number of queries per sample, etc.). These thresholds will be used to detect significant deviations that may indicate abnormal activity.

[0127] If AI is used as a solution to distinguish normal behavior from suspicious behavior, the aim here is to prepare AI models adapted to each angle of observation. Statistical feature vectors from the observation data in the database specific to each angle are used to train and validate these monitoring models.

[0128] In such a case, for each observation angle considered, the determination module 50 is adapted to execute a supervised or unsupervised machine learning algorithm for an artificial intelligence model which, for any feature vector from the set of feature vectors characterizing an observation window of fixed size, teaches the model to determine whether the traffic observed over this window contains an anomaly. Anomaly detection is, for example, formulated as a classification problem.

[0129] In what follows, some recommendations are proposed and examples are described, to prepare AI models.

[0130] O1: a client <-> an endpoint

[0131] For this client-resource pair, an AI model can be designed to learn the characteristics of this interaction and detect anomalies. It is recommended that this model be consistent with the method used for cluster creation, thus ensuring continuity in the analysis.

[0132] Logs concerning the client-resource pair are processed and grouped into samples at a regular interval, for example every 10 seconds. Each sample is described by statistical characteristics calculated from all or part of the log fields, such as the number of requests between the client and the endpoint over that interval.

[0133] These samples are then aggregated into time series of a chosen duration, for example one minute, tracing the evolution of the number of requests between this customer and this endpoint. An AI model, supervised or unsupervised depending on the available data, is then trained on these time series to learn to recognize normal interaction patterns and detect anomalies.

[0134] 02: a client <-> a group of endpoints and 03: a client <-> all of the endpoints

[0135] For these angles, the approach is similar to that of 01, but with particular attention paid to how a client interacts with several endpoints (those in the group) or with all endpoints. Monitoring models should take into account not only the volume of interactions, but also the diversity of the endpoints involved, which may indicate specific usage patterns or abnormal behavior.

[0136] Thus, in one embodiment, similar to 01, samples are created at regular intervals, for example every 10 seconds. Each sample is described by statistics on the number of endpoints solicited, their diversity, and the diversity of their functions. These characteristics make it possible to capture richer information on the interactions between the client and the group of endpoints.

[0137] From these samples, time series are created. These time series represent the evolution of interaction characteristics over time. An AI model is then trained on these time series to learn the normal interaction patterns between the client and the group of endpoints. Once trained, the model is able to identify anomalies that deviate from these normal patterns.

[0138] 04: a group of clients <-> an endpoint and 05: the set of clients <-> a endpoint

[0139] These perspectives each examine how a given endpoint is accessed by a given group of clients (04) or by all clients (05). To analyze these interactions in depth, it is crucial to consider not only classic metrics such as the total number of requests and the diversity of HTTP methods used, but also detailed client characteristics.

[0140] Thus, after sampling, the description of each sample considered in relation to 'a group of customers <-> an endpoint' (and the same for each sample considered in relation to 'all customers <-> an endpoint') should include statistics on the customers who have used the endpoint in question, such as their number, their roles, their diversity, etc., in addition to the classic metrics used in 01. These samples are then aggregated into time series, to better observe trends and interaction patterns.

[0141] 06: a group of clients <-> a group of endpoints and 07: the set of clients <-> all endpoints

[0142] For these perspectives, it is essential to consider both customer characteristics (diversity, number, etc.) and endpoint characteristics (function, diversity) when describing the samples. This approach should allow for accurately characterize the interactions between each pair formed by a group of endpoints and a group of clients, as well as the interactions between all clients and all endpoints.

[0143] The number of detection models to be designed (equal to the number of specific databases to be created) depends on the chosen observation angle, the number of clients and endpoints, and the number of endpoint and client groups created. Here are two examples to illustrate this:

[0144] Example 1: n = 5 customers (divided into N = 2 groups) and m = 20 endpoints (divided into M = 5 groups).

[0145] [Tables3] Observation Angle Type Description Number of Models 01 Each client <-> each endpoint 100 models 02 Each client <-> each group of endpoints 25 models 03 Each client <-> all endpoints 5 models 04 Each group of clients <-> each endpoint 40 models 05 All clients <-> each endpoint 20 models 06 Each group of clients <-> each group of endpoints 10 models 07 All clients <-> all endpoints 1 model

[0146] At the end of step 105, the anomaly detection modules for each observation angle selected in step 104 are obtained and incorporated into the monitoring module 40.

[0147] In the present case, with reference to [Fig. 1], the monitoring module 40 comprises: - a block 41 of n*m type 01 detection modules, in which the detection module 41Lj implements the model Mlj.ji = 1 to n and j = 1 to m, and is adapted to specifically detect anomalies between the ith client and the jth endpoint; - a block 42 of n*M type 02 detection modules, in which the detection module 42; j implements the model M2,, i = 1 to n and j = 1 to M, and is adapted to specifically detect anomalies between the ith client and the jth group of endpoints; - a block 43 of n detection modules of type 03, in which the detection module 43; implements the model M3; i = 1 to n and is adapted to specifically detect anomalies between the ith client and the set of endpoints; - a block 44 of N*m type 04 detection modules, in which the detection module 44^ implements the M4 model, i=làNetj = làmest adapted to specifically detect anomalies between the ith group of clients and the jth endpoint; - a block 45 of m type 05 detection modules, in which the detection module 45j implements the M5j model j = 1 to 3 and is adapted to specifically detect anomalies between the set of clients and the jeme endpoint; - a block 46 of N*M type 06 detection modules, in which the detection module 46i j implements the M6 ​​model, , i = 1 to N and j = 1 to M, and is adapted to specifically detect anomalies between the ith group of clients and the jth group of endpoints; - a block 47, also called type 07 detection module 47, which implements the M7 model and is adapted to specifically detect anomalies between the set of clients and the set of endpoints.

[0148] Production launch phase

[0149] During production phase 200, steps 201 to 204 are implemented by the control module 48 on observation data which are provided in real time and continuously from the gateway 20.

[0150] In a step 201, these observation data are collected, and optionally enriched (as described for steps 101, 102).

[0151] In a step 202, which may have taken place before step 201, an observation angle or several observation angles are chosen from those in the LAngi_obs list from step 104.

[0152] In a step 203, the monitoring device 40 implements the monitoring using the anomaly detection module(s) corresponding to the observation angles chosen during the last implemented step 202. For example, it determines vectors of statistical characteristics for each chosen observation angle (in the same way as described for training the detection module dedicated to that observation angle) based on the current observation data collected in step 201 and provides them as input to the associated detection module, specifically designed to detect anomalies according to that observation angle.

[0153] At any time, a new step 202 can be triggered, modifying the chosen observation angle(s).

[0154] The choice of observation angle(s) during step 202 can be set by an operator of device 40, or be a choice set by default at startup by the module control module 48 of the operational phase, or be carried out by control module 48 depending on the context, in particular depending on one and / or the other of:

[0155] - an anomaly detected by a Mi detection module (or another module of detection at work) on an analyzed observation window;

[0156] - a variation in the availability of processing resources available for implement traffic monitoring;

[0157] - a variation in a volume of traffic to be monitored;

[0158] - a variation in the level of security required in the system.

[0159] A default choice is, for example, one of these:

[0160] - all the viewing angles of list L, or even

[0161] - the angle of type 07 only, or

[0162] - all 06 type observation angles, or even

[0163] - the 07 type angle and all 06 type observation angles.

[0164] With ready-to-use anomaly detection modules for each angle By observing the LAngi_obs list, it is possible to dynamically adapt the analytical approach according to the situation. This allows switching from one perspective to another based on various triggers or specific needs.

[0165] In practice, this means that all models can operate in parallel and that a decision can be made based on an alarm triggered by one of them or a combination of alarms. Alternatively, it is possible to start with a single viewpoint and then switch to one or more others as needed. It is even possible to challenge a model's decision by activating models from other viewpoints on the data already analyzed.

[0166] Examples of surveillance scenarios and associated observation angles:

[0167] High priority security scenario: when operations requiring increased security are planned, the most detailed observation angle, 01, will for example be activated, to ensure close monitoring of client-resource interactions.

[0168] Large flow scenario or unexpected peaks: if safety is not an immediate priority, but the system is experiencing intense or unusual activity, a more global analysis using the 07 observation angle may be sufficient to identify potential anomalies and will therefore be chosen.

[0169] Moderate flow scenario and moderate level of security: when the processing resources available to perform monitoring are sufficient and the required level of security is moderate, it is appropriate to use the intermediate observation angle 06 to maintain a balance between the accuracy of monitoring and the use of resources.

[0170] Vulnerable resource identification scenario: to target the most at-risk APIs, it is recommended to activate observation angles 04 and 05, which focus on interactions between clients and specific APIs.

[0171] Scenario for detecting malicious users: if the main objective is to identify potentially malicious customers / users, observation angles 02 and 03, which focus on individual customer behavior, should be preferred.

[0172] Anomaly detection scenario: in the event of anomaly detection, it may be advisable to switch to a finer angle of observation to understand the origin of the anomaly (the customer or group of customers concerned, the corresponding user (terminal)(s), the API or group of APIs involved, etc.).

[0173] These examples illustrate how different monitoring scenarios can be associated with one or more specific viewing angles, thus allowing the granularity of monitoring to be adapted according to the needs and priorities of the system.

[0174] The solution according to the invention is particularly suited to companies that manage large volumes of client-server interaction systems and for which security is a crucial issue. For those desiring maximum protection through thorough and meticulous analysis, our strategy proves ideal. It offers great flexibility, allowing for a shift from a global to a more detailed analysis at any time.

[0175] The multi-scale view of client-server interactions, offered by the different observation angles, allows for a deep understanding of behaviors. It enables predictive analytics and proactive security. The invention represents a break from traditional rigid and inflexible approaches, guaranteeing an optimal level of security at all times.

[0176] The proposed solution offers significant advantages through the use of multiple monitoring granularities. This enables finer and more relevant detection of anomalies and attacks, reducing false alarms and avoiding the cost of a one-to-one approach. In one embodiment, it also offers the ability to dynamically adapt the monitoring granularity according to the context, providing an additional degree of optimization in detection precision or efficiency in the use of available processing resources for monitoring.

[0177] The adaptive and multi-scale approach to surveillance dynamically uses the type of analysis method and adjusts the granularity according to available resources, the required level of security and the volume of data to be processed in real time.

[0178] Intelligent allocation of monitoring resources based on actual needs optimizes system efficiency and controls costs. The solution's flexibility guarantees rapid adaptation to evolving threats and uses for sustainable and cutting-edge security.

[0179] The applications are numerous, particularly in any system involving large-scale client-server interactions and having high and variable security requirements, such as web services, APIs, databases, messaging systems, monitoring and security of enterprise information systems, protection of critical infrastructure and industrial systems, intrusion detection for service providers and telecom operators, traffic monitoring for network optimization and sizing, etc. Beyond attack detection, it can also be used to identify malfunctions, causes of performance degradation, or suboptimal use of network resources. Its generic nature makes it easily adaptable to different application contexts requiring detailed and responsive time series analysis.

[0180] When adding new endpoints or clients, it is necessary to repeat the steps for representing user behavior with all endpoint resources using a time series. Then, this client must be identified and associated with the nearest client cluster. Similarly, when introducing a new endpoint, it is sufficient to integrate it into the nearest endpoint cluster.

[0181] Moreover, the distribution into groups on the client and server side is repeated regularly, in one embodiment, to adapt to changes in behavior.

[0182] Example of generating samples and feature vectors

[0183] As seen previously, in the preliminary phase 100 and the exploitation phase 200, the possibly enriched observation data are exploited in order to extract characteristic vectors (used for the design / operation of the anomaly detection modules).

[0184] To determine these characteristic vectors, in one embodiment, observation samples are first generated.

[0185] To this end, observational data relating to the same time interval of duration Te and corresponding to the same observation angle are grouped together to generate a sample of observations. The frequency Fe = 1 / Te governing this grouping, which is called the sampling frequency below, is chosen according to one or more criteria, for example such as:

[0186] - average frequency of requests;

[0187] - detection requirements: a sufficient frequency to quickly detect the anomalies;

[0188] - storage and processing constraints, for a balance between granularity and costs.

[0189] Each sample is then described by statistical characteristics calculated by the control module 48 from the observation data grouped over the time interval Te to generate this sample, such as: - Frequency metric(s) and ratio: absolute frequency, relative frequency, ratios... - diversity metric(s): distinct values, entropy, Gini indices / Simpson... - Metric(s) of central tendency and dispersion: quartiles, interquartile range, truncated mean... - distribution shape metric(s): asymmetry, kurtosis...

[0190] The definitions and uses of such metrics are well known. Not all of these metrics apply to all fields, depending on whether they are categorical or continuous in nature.

[0191] By way of example, the following statistical characteristics are calculated for a sample of logs over Te=10 seconds, determined for the calculation time t (therefore calculated selectively on the logs whose timestamp is in the range t and t+Te)

[0192] number of requests (in the range t and t+Te)

[0193] proportion of each HTTP method

[0194] quartiles of query durations

[0195] entropy of status codes

[0196] skewness coefficient of the query size distribution.

[0197] Considering IP packets this time, for example, the following statistical characteristics are calculated for a sample of packets over Te=10 seconds (s), determined for the calculation time t (therefore calculated selectively on packets transmitted in the range t and t+Te):

[0198] number of packets

[0199] average package size

[0200] Incoming / outgoing packet ratio

[0201] 90th percentile of inter-arrival time s

[0202] proportion of packets with SYN flag.

[0203] The control module 48 thus obtains a vector of features per sample.

[0204] An example of a feature vector per sample is given in the table Below, in the case of logs:

[0205] [Tables4] Start timestamp Number of requests % GET POST Q1 duration Median duration Q3 duration Entropy codes Skewness taiiies 1622146800 215 0.72 0.28 120ms 230ms 410ms 1.28 1.42

[0206] An example of a feature vector per sample is given in the table below in the case of IP packets:

[0207] [Tables5] Start Number of packets Size mpy. m / out ratio SOp inter-arrivals % SYN 162214G8Û0 12450 782 bytes 1.32 15ms 0.03

[0208] Another example of constructing a vector of characteristics of a sample

[0209] With reference to [Fig. 3] describing the successive logs corresponding to an angle Once the observation is fixed and grouped into a sample, the following frequency and ratio metrics are calculated, considering the aspects of "HTTP Method" and "Status Code". Absolute frequency: HTTP method:

[0210] GET: 3

[0211] POST:2

[0212] PUT: 1

[0213] DELETE: 1 Status Code:

[0214] 200:3

[0215] 201:1

[0216] 404:1

[0217] 204:1

[0218] 400:1 Relative frequency (proportion): HTTP method:

[0219] GET: 3 / 7 = 0.429

[0220] POST: 2 / 7 = 0.286

[0221] PUT: 1 / 7 = 0.143

[0222] DELETE: 1 / 7 = 0.143 Status code:

[0223] 200: 3 / 7 = 0.429

[0224] 201:1 / 7 = 0.143

[0225] 404:1 / 7 = 0.143

[0226] 204:1 / 7 = 0.143

[0227] 400:1 / 7 = 0.143

[0228] Ratio between the two most frequent values: HTTP method:

[0229] Ratio (GET / POST): 3 / 2 = 1.5 Status code:

[0230] Ratio (200 / 201): 3 / 1 = 3.0 Top N of the most frequent values: Top 2 HTTP Method:

[0231] GET: 3 occurrences

[0232] POST: 2 occurrences Top 2 Status Code:

[0233] 200: 3 occurrences

[0234] 201: 1 occurrence (with 404, 204, 400) Ratio of the most frequent value HTTP method:

[0235] Ratio (GET): 3 / 7 = 0.429 Status code:

[0236] Ratio (200): 3 / 7 = 0.429

[0237] The following diversity metrics are calculated for these aspects: "http Method" and "Status Code". HTTP method:

[0238] Observations: GET, POST, PUT, DELETE, POST, GET

[0239] Frequencies: GET: 3, POST: 2, PUT: 1, DELETE: 1

[0240] Total number of observations: 7

[0241] Number of distinct values: 4 (GET, POST, PUT, DELETE)

[0242] Ratio between the number of distinct values ​​and the total number of observations:

[0243] 4 / 7 «0.57174 47«0.571

[0244] Shannon entropy: = 1.842 bits

[0245] Simpson's Diversity Index "0.653

[0246] Gini index of Gini «0.653 «0.653 «0.653 Status code:

[0247] Observations: 200, 201, 404, 200, 204, 400, 200

[0248] Frequencies: 200:3, 201:1, 404:1, 204:1, 400:1

[0249] Total number of observations: 7

[0250] Number of distinct values: 5 (200, 201, 404, 204, 400)

[0251] Ratio between the number of distinct values ​​and the total number of observations: 57 0.71475 0.714

[0252] Shannon entropy "2.128 bits

[0253] Simpson's Diversity Index -0.775

[0254] Gini coefficient -0.775

[0255] The feature vector thus comprises, for the "HTTP Method" aspect, the following components:

[0256] 1. Total number of observations: 7

[0257] 2. Absolute frequency of GET: 3

[0258] 3. Absolute frequency of POST: 2

[0259] 4. Absolute frequency of PUT: 1

[0260] 5. Absolute frequency of DELETE: 1

[0261] ô.Relative frequency of GET: 0.429

[0262] 7. Relative frequency of POST: 0.286

[0263] 8. Relative frequency of PUT: 0.143

[0264] 9. Relative frequency of DELETE: 0.143

[0265] Ratio between GET and POST: 1.5

[0266] 1. Top 2 most frequent methods: GET, POST

[0267] 12. Ratio of the most frequent value (GET): 0.429

[0268] 13. Number of distinct values: 4

[0269] 14. Diversity ratio: 0.571

[0270] 15. Shannon entropy: 1.842 bits

[0271] lô.Simpson's Diversity Index: 0.653

[0272] This part of the feature vector relating to the "HTTP Method" aspect can be represented as follows, for a single given sample:

[0273] HTTP_Features=[7,3,2,1,1,0.429,0.286,0.143,0.143,1.5,"GET,POST",0.42 9,4,0.571,1.842,0.653,0.653]

[0274] To manage a fixed size of the "Absolute Frequency" part, which can vary depending on the different values ​​taken by the method, we can limit ourselves to the most common and well-known methods: GET, POST, PUT, HEAD etc.

[0275] Similarly, the feature vector thus comprises, for the "Status Code" aspect, the following components:

[0276] l. Total number of observations: 7

[0277] 2. Absolute frequency of 200: 3

[0278] 3. Absolute frequency of 201:1

[0279] 4. Absolute frequency of 404:1

[0280] 5. Absolute frequency of 204:1

[0281] ô. Absolute frequency of 400: 1

[0282] 7. Relative frequency of 200: 0.429

[0283] 8. Relative frequency of the others (201, 404, 204, 400): 0.143 each

[0284] 9. Ratio between 200 and 201: 3.0

[0285] Top 2 status codes: 200, 201

[0286] 11. Ratio of the most frequent value (200): 0.429

[0287] 12. Number of distinct values: 5

[0288] 13. Diversity ratio: 0.714

[0289] 14. Shannon entropy: 2.128 bits

[0290] 15.1 Simpson Diversity Index: 0.775

[0291] lô.Gini index: 0.775

[0292] This part of the feature vector relating to the "status code" aspect, for a single given sample, can be represented as follows:

[0293] Status_Features=[7,3,1,1,1,1,0.429,0.143,0.143,0.143,0.143,3.0,"200, 201",0.429,5,0.714,2.128,0.775,0.775]

[0294] The same consideration as before applies to having a fixed size.

[0295] In the example described above, the traffic monitoring device 40 implements the preliminary phase 100 and the production phase 200. In another embodiment, separate modules perform the steps of these respective phases.

[0296] In the foregoing, it was assumed that communications passed through a gateway module 20. In other embodiments, the invention is implemented without a gateway module, with a logging system that records observation data relating to communications taking place in the system between users and resources. Depending on the embodiment, the traffic data considered is represented, for example, in the form of PCAP (Packet Capture Application Protocol) files, application-level logs, or any other form representing communications in the network. In one embodiment, the observations are obtained by capturing the traffic passing between users and resources at a probe placed in the network.

[0297] In the foregoing, a sample size expressed in time was considered. In another embodiment, the size considered is expressed in number of logs (or IP packets).

[0298] In the example described above, samples corresponding to 10 s were considered, and then feature vectors calculated for each of these samples were time-serialized to generate the feature vectors of the observation windows. In another embodiment, instead of 10 s samples, samples corresponding to the entire duration T are considered.

[0299] The sample size can be defined by a time duration, such as all logs / packets recorded for 10 seconds, or by a fixed number of observations, for example 3 logs / packets.

[0300] The process steps assigned to the control module 48, respectively the determination module 50, can be implemented by the execution software instructions (stored in a memory of the monitoring device 40) on a processor of the monitoring device 40. Alternatively, they can be implemented by dedicated hardware, typically a digital integrated circuit, either specific (ASIC) or based on programmable logic (e.g. FPGA / Field Programmable Gate Array).

Claims

1. Demands Method of monitoring data traffic in a communication system (1) between clients (10) and servers (30), wherein in a prior phase, groups of clients and / or groups of servers having been defined, and several distinct modules from among automatic traffic anomaly detection modules M1, M2, ..., M7, each distinct module M1 having been designed, in a prior phase, according to traffic observation data from a historical database corresponding specifically to a single respective type Oi of traffic observation angles from among the following: type 01 of observation angle specific to the traffic between a single given client and a single given server, the module M1 being adapted to detect anomalies specifically in this traffic; type 02 of observation angle specific to the traffic between a single given client and a given group of servers, the M2 module being adapted to selectively detect anomalies in this traffic; type 03 of observation angle specific to the traffic between a single given client and all servers, the M3 module being adapted to detect anomalies specifically in this traffic; type 04 of observation angle specific to the traffic between a single given group of clients and a single given server, the M4 module being adapted to selectively detect anomalies in this traffic; type 05 of observation angle specific to the traffic between all clients and a single given server, the M5 module being adapted to detect anomalies specifically in this traffic; type 06 of observation angle specific to traffic between a single given group of clients and a single given group of servers, the M6 ​​module being adapted to detect anomalies specifically in this traffic; type 07 of observation angle specific to the traffic between the given set of clients and the given set of servers, the M7 module being adapted to detect anomalies specifically in this traffic; said method comprising the following steps implemented by an electronic data traffic monitoring device (40), in operational phase: - collect current traffic observation data between clients (10) and servers (30); - perform, using one of said separate automatic traffic anomaly detection modules (M1m), named Mi, an analysis of at least part of the current observation data collected and corresponding specifically to the type Oi of observation angle considered; - perform, using another of said separate automatic traffic anomaly detection modules (M2m), Mj, j^i, an analysis of at least part of the current observation data collected and corresponding specifically to the type Oj of observation angle considered.

2. A method for monitoring data traffic according to claim 1, wherein the analysis by the automatic traffic anomaly detection module Mj specifically corresponding to the type Oj of observation angle considered is triggered at the end of a first period of analysis by the automatic traffic anomaly detection module Mi specifically corresponding to the type Oi of observation angle.

3. A method for monitoring data traffic according to claim 2, wherein said triggering is performed based on at least one of the following events: - an anomaly detected by the Mi module; - a variation in the availability of processing resources available to implement traffic monitoring; - a variation in the volume of traffic to be monitored; - a variation in the level of security required in the system.

4. A method for monitoring data traffic according to any one of claims 2, 3, wherein N client groups having been defined and M server groups having been defined, said distinct automatic detection modules comprise at least: - N x M M6 (M6m, M6NM) type 06 modules with an observation angle specific to the traffic between a single given client group among the N client groups and a single given server group among the M server groups, in which the (t+k)th module M6, named M6k is adapted to detect an anomaly selectively between the given teme group of clients, t = 1 to N, and the given teme group of servers among the M groups of servers, k = 1 to M.

5. A method for monitoring data traffic according to claim 4, wherein said separate automatic detection modules further comprise at least: - an automatic traffic anomaly detection module M7, i = 7, corresponding to the type 07 observation angle specific to the traffic between the given set of clients and the given set of servers;

6. A method for monitoring data traffic according to any one of the preceding claims, wherein the current observation data supplied as input to the separate modules are relative to a common time interval and an anomaly is determined to be present or not based on said detection results supplied over said common time interval by the separate modules.

7. A method for monitoring data traffic according to any one of the preceding claims, wherein the client groups are determined based on descriptive statistics vectors calculated for each client (10) from the historical basic traffic observation data, and characterizing its behavior; and the server groups are determined based on descriptive statistics vectors calculated for each server (30) from the historical basic traffic observation data characterizing how they are solicited by clients.

8. Computer program, intended to be stored in the memory of a traffic monitoring device (40) and further comprising a microcomputer, said computer program comprising instructions which, when executed on the microcomputer, implement the steps of a method according to any one of the preceding claims.

9. A device for monitoring data traffic (40) in a communication system (1) between clients (10) and servers (30), wherein, after client groups and / or server groups have been defined, said monitoring device comprises several distinct modules from among automatic detection modules of traffic anomalies M1, M2, ...M7, each distinct module Mi having been designed, in a prior phase, based on traffic observation data from a historical database specifically corresponding to a single respective type Oi of traffic observation angles from among the following: type 01 of observation angle specific to the traffic between a single given client and a single given server, the Ml module being adapted to detect anomalies specifically in this traffic; type 02 of observation angle specific to the traffic between a single given client and a given group of servers, the M2 module being adapted to selectively detect anomalies in this traffic; type 03 of observation angle specific to the traffic between a single given client and all servers, the M3 module being adapted to detect anomalies specifically in this traffic; type 04 of observation angle specific to the traffic between a single given group of clients and a single given server, the M4 module being adapted to selectively detect anomalies in this traffic; type 05 of observation angle specific to the traffic between all clients and a single given server, the M5 module being adapted to detect anomalies specifically in this traffic; type 06 of observation angle specific to traffic between a single given group of clients and a single given group of servers, the M6 ​​module being adapted to detect anomalies specifically in this traffic; type 07 of observation angle specific to the traffic between the given set of clients and the given set of servers, the M7 module being adapted to detect anomalies specifically in this traffic; wherein said electronic data traffic monitoring device (40) is adapted to collect observation data of current traffic between clients and servers; said electronic data traffic monitoring device (40) is adapted to perform, using one of said separate automatic traffic anomaly detection modules, named Mi, an analysis of at least a part of the current observation data collected and corresponding specifically to the type Oi of observation angle considered; said electronic data traffic monitoring device (40) is adapted to perform, using another of said separate automatic traffic anomaly detection modules, Mj, j^i, an analysis of at least a part of the current observation data collected and corresponding specifically to the type Oj of observation angle considered.

10. Data traffic monitoring device (40) according to claim 9, adapted to trigger analysis by the automatic traffic anomaly detection module Mj specifically corresponding to the type Oj of observation angle considered at the end of a first period of analysis by the automatic traffic anomaly detection module Mi specifically corresponding to the type Oi of observation angle.

Images