WO2007006995A2 - Detection dynamique d'anomalies dans le trafic relatif a une entite de service - Google Patents

Detection dynamique d'anomalies dans le trafic relatif a une entite de service Download PDF

Info

Publication number
WO2007006995A2
WO2007006995A2 PCT/FR2006/050670 FR2006050670W WO2007006995A2 WO 2007006995 A2 WO2007006995 A2 WO 2007006995A2 FR 2006050670 W FR2006050670 W FR 2006050670W WO 2007006995 A2 WO2007006995 A2 WO 2007006995A2
Authority
WO
WIPO (PCT)
Prior art keywords
service entity
traffic
volume
evaluated
deviation
Prior art date
Application number
PCT/FR2006/050670
Other languages
English (en)
Other versions
WO2007006995A3 (fr
Inventor
Hervé SIBERT
Emmanuel Besson
Aline Gouget
Original Assignee
France Telecom
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 France Telecom filed Critical France Telecom
Publication of WO2007006995A2 publication Critical patent/WO2007006995A2/fr
Publication of WO2007006995A3 publication Critical patent/WO2007006995A3/fr

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • 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
    • H04L63/1425—Traffic logging, e.g. anomaly detection

Definitions

  • the present invention relates to the field of network security and flood denial of service attacks. More particularly, it relates to an anomaly detection in the traffic supported by a transmission link and relating to at least one service entity.
  • Telecommunications networks such as the Internet transmit data between different service entities via a common infrastructure.
  • a service entity connected to such a network responds to client terminal requests by providing them with a service, that is, by performing well-defined actions requested by the clients.
  • Service entities are, for example, a web server, a content or streaming server offering a download of multimedia files or broadcasting multimedia files, an e-mail server that relays messages, or a DNS domain name server that provides IP addresses corresponding to domain names.
  • These service entities are, in some cases, endpoints of the network and are located at customers of an operator, while other service entities, such as DNS servers, are managed by the operator of the network itself.
  • a denial of service attack is an attack that attempts to make a service entity unavailable.
  • denial of service attacks There are several types of denial of service attacks, for example specific queries that directly attack the service entity's operation by asking it to perform an action. "improper” .
  • flood denial-of-service type attacks consist in exceeding, and thus “flooding", the network capacity of the service entity or the transmission link through which the service entity is connected to the network. In both cases, volume characteristics of the network traffic to the service entity increase suddenly.
  • detection methods there are two major families of detection methods.
  • the first family is related to signature detections. It consists of continuously observing the traffic in the vicinity of a potential service entity, and comparing the observations with traffic patterns stored in memory and which characterize known attacks.
  • the detection methods of the first family are particularly suitable for intrusion detection and non-flood-based denial of service detection of service entities.
  • the invention further relates to the second family which relates to anomaly detections.
  • An anomaly is a traffic assessment that does not conform to a set of acceptable normal traffic evaluations. All eligible assessments are determined a priori using rules and expert knowledge. There are several types of rules, such as an access control list and security policies, set by the operator or the customer who owns a service entity. These rules define characteristics that normal traffic must satisfy or otherwise not satisfy. However, these rules are insufficient: The most sensitive service entities most targeted by cybercrime are also the most difficult to protect a priori; in particular, the traffic of service entities whose clients are not known in advance is treated, and the rules that can be set a priori are limited.
  • An attack can indeed comply with most rules set a priori in the form of the traffic that the attack sends to flood the service entity. To avoid this, it is necessary to fix in addition threshold type rules on volume components of the traffic. For good detection quality, these thresholds must take into account the traffic of the service entity in normal times, which implies a phase of learning of normal traffic by the detection method, the success of the attack being based the amount of attack traffic actually reached at the service entity for processing. If the rules are traffic thresholds, their effectiveness and relevance depends on the difference between these thresholds and the activity of the service at the time of the attack. It is therefore important that such rules take into account the activity of the service, and rules defined a priori are insufficient.
  • the detection of behavioral anomalies consists in modeling the activity of the service entity to be protected by observing it and modeling its behavior. Few known anomaly detection methods are specifically oriented towards flood attacks. Given evaluations and a behavioral model of the service entity, these methods use statistical variables to predict the next assessment (s). If the next effective evaluations deviate significantly from the predicted estimates, then an alert is reported. However, these anomaly detection methods also detect attacks other than flood attacks, inducing a loss of processing time by the security operator.
  • the purpose of the invention is to dynamically detect near a service entity to protect behavioral anomalies both in the traffic directed towards this service entity and in the traffic which comes from it, by resorting to coefficients and rules that can evolve with traffic and without resorting to a prediction of evaluations of statistical variables, so as to report very quickly and precisely a flood denial of service attack.
  • a method for detecting anomalies in the traffic supported by a transmission link and relating to a service entity, including previously a modeling of the normal activity of the service entity is characterized in that the modeling provides models for volumetric components of the traffic periodically evaluated for a predetermined duration, a model relating to a volume component including deviation coefficients evaluated as a function of a moving average of the evaluated volumetric component for the predetermined duration, said method comprising for at least one subsequent evaluation of deviation coefficients relating to the volume components, incrementing a respective alert value for at least one deflection coefficient if a new value of the deflection coefficient is greater than a respective threshold value included in the model.
  • the method of the invention is based not on absolute values of traffic parameters of the service entity at a given time, but on deviation coefficients depending at least on two evaluations of a volume component, so as to observe the behavioral transitions in the service entity traffic.
  • the invention extrapolates a normal dynamic activity of the service entity by basing the deviation coefficients on means and discrete traffic derivatives evaluated during the modeling and which can be updated periodically at most at each evaluation of the volume components.
  • the deviation coefficients are compared with thresholds to detect whether the behavioral transitions in the succession of evaluations remain lower than the behavioral transitions according to the models; otherwise an alert value is incremented.
  • the invention detects abnormal activity in the service entity traffic when the alert value exceeds a predetermined alert level.
  • the invention detects and characterizes a flood denial of service attack to protect service entities of an operator or its customers for example.
  • the invention characterizes it by the result of comparisons of the deviation coefficients evaluated to threshold values, which result may represent an anomaly in the form of an abnormal variation of the components. assessed volumes.
  • the evaluations of volume components may relate to the traffic destined for the service entity to be protected, or to the traffic originating from this entity, or both of these traffics at the same time. .
  • the detection of behavioral abnormalities according to the invention is called "dynamic" because it relies on traffic deviation measurements in a relative manner as a function of successive evaluations of volume components, regardless of absolute values, and does not intended to handle periods of stable activity of the supervised service entity.
  • the invention and particularly to the modeling including a moving average, it is therefore advantageous to carry out a detailed statistical analysis of the traffic relating to a service entity.
  • said moving average is an exponentially weighted moving average.
  • the invention provides, according to particular features, updating of models to periodically replace current old models relating to the service entity. by updated models based on recent values of the volume components and the deviation coefficients associated with the service entity.
  • a current value of a deflection coefficient of the first type is updated by replacing said current value by the average thereof and by a new value of the deflection coefficient if said new value is greater than the current value. the deflection coefficient when the deflection coefficient is of a first type, or if the new value is lower than the current value of the deflection coefficient when the deflection coefficient is of a second type.
  • the invention also relates to a device for detecting anomalies in the traffic supported by a transmission link and relating to a service entity, the normal activity of the service entity being previously modeled, and a traffic probe including the device. to detect anomalies.
  • the device is characterized in that it comprises means for modeling the normal activity of the service entity by models for volumetric components of the traffic evaluated periodically for a predetermined duration, a model relating to a volume component comprising coefficients deviation values evaluated as a function of a moving average of the evaluated volume component for the predetermined duration, means for at least one subsequent evaluation of deviation coefficients relating to the volume components for incrementing a respective alert value for at least one coefficient of deviation if a new value of the deflection coefficient is greater than a respective threshold value included in the model.
  • said moving average is an exponentially weighted moving average.
  • the invention relates to a computer program adapted to be implemented in an anomaly detection device according to the invention.
  • the program comprises instructions which, when the program is loaded and executed in said device, perform the steps of the method of detecting anomalies according to the invention.
  • FIG. 1 is a schematic block diagram of a device for detecting dynamic anomalies in an internet type network, according to the invention
  • FIG. 2 is an algorithm of the dynamic anomaly detection method according to the invention.
  • a dynamic anomaly detection device DD is included in a traffic probe and acts as essentially software agent for inhibiting attacks against service entities SE in a telecommunications network.
  • High-speed packets RT managed by an operator according to the IP (Internet Protocol).
  • Data is transmitted in a transmission link LT of the RT network constituting part of the Internet.
  • the data are, for example, contained in packets transmitted by TC client terminals and intended for SE service entities comprising web servers.
  • the transmission link LT is located near the service entities SE whose traffic is to be monitored by the probe so that the latter detects anomalies in the traffic which characterize abnormal behavior of the service entity clients, particularly attacks by flood of service entities.
  • the transmission link LT to which the probe is connected in listening according to FIG. 1 is located in the network RT at the point of entry of one or more service entities on the network, between the network RT and the network. last RO router of the network operator RT preceding a router connected to an service entity SE.
  • the probe is not connected to a client link between the RO router and the service entity SE whose traffic might already be congested due to the limited capacity of the client link.
  • the probe is cut-off to the transmission link LT to also remove abnormal packets for one or more monitored service entities.
  • the detection device DD reports an alert based on the observation of the traffic relating to the entity or the service entities in the link LT so that the operator takes appropriate measures to counter an attack directed towards the entity or the service entities.
  • the probe issues alerts from listening to traffic at a point of the network RT.
  • the dynamic detection device DD may be in the form of a computer or a workstation, or a local or distributed computer system.
  • the device DD comprises the following modules: a human-machine management interface HMI, local or remote, including including a keyboard and a screen, to activate the device automatically or manually by an operator and in particular to enter service entity identifiers and characteristics, select data for detection and read alerts; a service entity declaration module DEC for selecting a portion of the traffic to be monitored in the link LT which is intended for SE service entities to be protected; a MED mediated listening module according to Figure 1, or alternatively cut to the transmission link LT to evaluate volume components of traffic; a MOD modeling module that constructs normal activity patterns for the service entities to be protected based on traffic volume component values evaluated by the MED mediation module to produce dynamic behavior models for each protected service entity and for each volume component; a DB database for recording models relating to the volume components of the service entities; a DET anomaly detection module detecting anomalies in the observed
  • HMI human-machine management
  • the method for dynamic detection of traffic anomalies is implemented in the detection device DD and comprises three main stages E1, E2 and E3, as shown in FIG. 2.
  • the steps E1, E2 and E3 comprise respectively sub-steps ElO to E12, E20 to E26 and E30 to E35.
  • Sub-stages are also indicated in FIG. 1 at the level of links between modules of the detection device DD intervening for the execution of these substeps.
  • the first step E1 includes a declaration of the service entities OS to be explicitly protected by the operator, which defines a set of services to be protected provided by these entities.
  • the operator defines SE service entities that he wishes to protect in the declaration module DEC via the human-machine interface HMI.
  • the DEC module thus selects a portion of the traffic in the link LT which is intended for each declared service entity.
  • the operator explicitly defines service entities by entering identifiers and characteristics of the service entities to be protected transmitted to the DEC, or by entering identifiers of the service entities passed to the DEC that reads characteristics of the selected service entities in correspondence with the identifiers of the entities in a prerecorded list in a database in connection with the link LT.
  • the characteristics identifying a service entity are for example triplets.
  • the feature triple of a service entity includes a destination address or IP destination address class, a transport protocol, and a port.
  • Service entity identifiers may also be specialized, for example, the feature triplets themselves.
  • a declared service entity has a triplet of characteristics (IP destination address, transport protocol (s) T, port (s) P): an IP destination address that is in the format
  • 159.151.254.0/25 means the address 159.151.254.0 at the address 159.151.254.127 since 2 32 - 2 25 -
  • "Supplementary" service entities may be implicitly declared as a result of the explicit declaration of the service entities to be protected.
  • An implicit supplementary service entity may be a service entity declared by default to cover attacks on specific protocols, such as undesirable traffic using the Internet Control Message Protocol (ICMP).
  • An implicit supplementary service entity may be constructed as a complement to at least one declared service entity having an IP address, and relating to traffic other than those relating to services hosted by the declared service entity but having said IP address. and for example different ports.
  • Complementary service entities are automatically inferred from the characteristics of the declared service entities to synthesize the LT link activity of the network that is not explicitly declared by the operator.
  • the supplementary service entities to be protected have characteristic triplets (IP destination address, T transport protocol (s), all ports except P) and (IP destination address, transport protocol (s) except T, port (s) ) P).
  • the declaration of service entities is automatic thanks to a listening of the traffic in the link LT by the declaration module DEC.
  • the DEC module is connected in listening mode according to FIG. 1.
  • the DEC module establishes a list of the service entities requested by the packets that pass in the link LT and classifies these service entities by frequency of appearance of the packets intended these entities, in order to obtain a pre-list of service entities. Then, this list is automatically reduced in order, for example, to keep in memory of the DEC module only the service entities requested by more than 1% of the packets, or is modified by the operator.
  • the list thus established is the list of service entities to be protected.
  • the service entities to be protected by the device DD are well identified.
  • the modeling module MOD is initialized by receiving the list of identifiers of the service entities to be protected provided by the declaration module DEC.
  • the MOD module receives the list automatically to the sub-step ElI, or alternatively after validation of the operator via the HMI interface to the substep Ella.
  • the MOD modeling module For each service entity to be protected, the MOD modeling module associates default traffic evaluation parameters which are a granularity and a default list of volume components of traffic to, or possibly originating from, the service entity. SE service.
  • the granularity defines a service entity traffic evaluation period and may be a default value dependent on a feature of the service entity. For example, the granularity is 10 seconds if the P port of the service entity is 80 (HTTP), or 1 minute if the port is 23 (Telnet).
  • the volume components of traffic in the default list are characteristics that can be read from network and transport layer information and aggregated as counter counts reset at each traffic evaluation period defined by granularity.
  • the volume components are for example: at the level of the IP network layer: the volumetry expressed by a traffic rate in bytes per second, the volubility expressed by a packet traffic rate per second, the connectivity expressed by a number of different source addresses in packets destined for the service entity, and fragmentation expressed as a fragmented packet rate as a function of the DF and MF bits in the flag field of the header of an IP packet; and at the Transmission Control Protocol (TCP) level: the connection opening expressed by a packet rate including a SYN control bit at "1", the "stress” expressed by a packet rate including a PUSH control bit at "1" indicating that the data is to be transferred to the upper layer, the urgency expressed by a packet rate including an urgency message control bit URG to "1”, and the volatility expressed by a number of different ports solicited.
  • TCP
  • a threshold S x which must not exceed the volume component, and a floor P x , below which the evaluations of the volume components are considered irrelevant, are defined a priori by operator or by default depending on the capabilities of the protected service entities.
  • a volume component to be evaluated on a HyperText Transfer Protocol (HTTP) service is the number of requests on a specific method, such as the 'GET' method, the number of requests to CGI (Common Gateway Interface) pages, PHP (Personal). Home Page), a Java Server Page (JSP), or a 2xx, 3xx, 4xx, or 5xx error code returned by the server involving a return traffic measurement, or the version of the protocol used (0.9, 1.0, 1.1) .
  • HTTP HyperText Transfer Protocol
  • the operator can manually modify the list of solid components as well as any other evaluation parameter that has taken a default value, such as granularity.
  • the module MOD transmits a list of service entities, possibly after validation of the operator, to the mediation module MED of the device DD.
  • the service entity list shall include the identifier and characteristics of the service entity and the volume components of the traffic necessary for modeling to that from these volume components, the MOD module produces a model of dynamic behavior of the service entity.
  • the mediation module MED extracts from each relevant packet captured in the link LT and intended for an identified service entity to protect, in particular the address of IP source, the IP destination address, the transport protocol field value, the source port, the destination port, the total packet length in bytes, the flag field with the fragmentation bits, and the TCP flag list , to evaluate the volume components.
  • the MED module comprises COM counters respectively which for example count predetermined bytes, packets, source addresses and control bits to express the volume components and thus are assigned to the evaluation. the volume components of the service entity. The counters are reset regularly to the evaluation period according to the granularity, for example of the order of a few seconds, typically 10 seconds. Each volume component evaluation is time stamped with the start date of the period.
  • the counters counts are values of the requested traffic volume components that are aggregated, formatted and provided by the MED module to the MOD module.
  • the volume components provided by the MED module are temporarily stored in an evaluation database included in the MOD module.
  • the module MOD processes a series of sets of volume component values that have been evaluated for a predetermined duration which is much greater than the granularity evaluation period selected for the aggregation of the volume components. , or else defined by the operator.
  • the models depend on values of the volume components that are established consecutively over a predetermined duration specific to the service entity, during which the service entity passes through all the behaviors. normal activity that the service entity will have during the detection phase. Therefore, given the variations in the activity of TC client terminals, the predetermined duration is for example at least a week or a month and is defined by the operator.
  • the dynamic modeling according to the invention thus does not determine periods of stable activity dividing a long duration of operation of the protected service entity.
  • the predetermined duration during which the counts of the COM counters are read and supplied to the MOD module to perform the first modeling with respect to several service entities to be protected supposed to be in normal activity after the activation of the detection device DD constitutes a learning phase. . From these volume components evaluated during the learning phase for the service entities to be protected, the MOD module produces dynamic behavior models of each protected service entity, as explained below.
  • the module MOD evaluates admissible dynamic behavior coefficients called DC deflection coefficients used subsequently for the dynamic detection of anomalies by comparison.
  • the modeling module MOD evaluates in real time several variables from the evaluations of the volume components. For each monitored volumetric component x relative to the given service entity, the MOD modulates one or more exponentially weighted moving averages over the predetermined time based on one or more selected average coefficients.
  • M n Cx n + (1-C) M n -I, where C is a carefully chosen constant. It is said that M n is the "exponentially weighted moving average", with a weighting coefficient C, of the values x 0 to x n .
  • C 2 / (1 + c) e [0, 1], where c is a coefficient of average, for example previously chosen by default for a model in a list of average coefficients ⁇ 1, 3, 9, 27 ⁇ which MOD module has and which can be modified by the operator.
  • the moving average Mj thus mathematically depends on the last evaluations, that is to say, "has a memory” of evaluations, although its updating by the module MOD does not require, in addition to the old value Mj-i of the average , that the memorization of the value of the last evaluation of the volume component xi.
  • volume component N n CX n + (1 - C) N n -I, and a mobile deviation SD n equal to the square root of the absolute value N n - M n I of the difference of the moving average of the squares and square of the moving average.
  • This deviation is strictly positive as soon as at least one non-zero value of the volume component has been observed.
  • a floor mechanism described later ensures that all calculations involving said movable deviation are performed only when said movable deviation is strictly positive.
  • the module MOD Based on the values of these common variables (M n -I, MM n -I, d n -i, dd n -i, N n -I, SD n _i) determined at the previous current evaluation n-1 of the volume component and (M n , MM n , d n , dd n , N n , SD n ) determined at the new evaluation of the volume component n, the module MOD evaluates deflection coefficients of a first type CD1 and coefficients deviating a second type CD2 to give a dynamic character to the detection of traffic anomalies, the current substeps E22 and E23.
  • the CD1 deviation coefficients of the first type relating to a volume component x and a coefficient of average c depend on certain variables, such as the volume component, the exponentially weighted moving average, the exponentially weighted average of the moving average, and the exponentially weighted average of the squares of values of the volume component.
  • the CDl deviation coefficients are used to check the conformity of the current evaluation of the service entity's volume components against previous assessments.
  • a deviation coefficient CD1 n of the first type relating to the volume component x is equal to the ratio (x n -
  • CD1 n [x n - 2M n + MM n - C (M n - MM n ) / (I - C)] / SD n .
  • the deviation coefficients CD1 n are chosen to be equal to 0 if the mobile deviation SD n is zero.
  • the module MOD compares the old current value CD1 n -I of the deviation coefficient with the new value of the deviation coefficient CD1 n , and updates the current value according to a rule which can be for example: the new value CDl n of the deflection coefficient is greater than the current value CDl n -I of the deflection coefficient, replacing the current value by the following average of the latter and of the new value: (CDi n -HCr-I) CDi 11-1 ) Zr, where Test an integer constant, for example equal to the duration expressed in days of learning, rounded to the higher integer.
  • the MOD modeling module evaluates the deviation coefficients of a second type CD2 which in relation to a volume component depends on certain variables, such as the volume component, the exponentially weighted moving average, the exponentially weighted average of moving average values, the discrete first derivative of the volume component proportional to the difference in the evaluated volume component and the moving average, the discrete second derivative of the volume component equal to the difference of a new value and a current value of the first derivative, and a respective common threshold S x .
  • the CD2 deflection coefficients are used to predict the conformity of next evaluations of each volume component succeeding the current evaluation, with respect to the threshold S x set for the volume component, in dependence on current and new evaluations thereof.
  • the MOD module further performs several ways modeling by predicting a time required for the treated volume component x exceeds the respective threshold S x has been assigned initially and which is a maximum value of the component volumetric permissible by the given service entity SE.
  • the module MOD compares the old current value CD2 n -i of the deflection coefficient with the new value of the deflection coefficient CD2 n , and updates the current value according to a rule which can be for example: if the new value of the deflection coefficient CD2 n is smaller than the current value CD2 n -i of the deflection coefficient, replacing said current value with the average (CD2 n + (T-1) CD2 n _i / T) of this ci and said new value.
  • a rule which can be for example: if the new value of the deflection coefficient CD2 n is smaller than the current value CD2 n -i of the deflection coefficient, replacing said current value with the average (CD2 n + (T-1) CD2 n _i / T) of this ci and said new value.
  • Another mode of prediction modeling consists in that the module MOD initially has a list of constants called temporal coefficients and, for example ⁇ 10, 30, 60 ⁇ , and determines values of the volume component predicted at dates subsequent to the current date of the volume component evaluation, increased respectively by time coefficients of the list.
  • the rule for updating the deflection coefficient is, for example: if the new value of the deflection coefficient is greater than the current value of the deflection coefficient, replace the current value by the average of the latter and the new value.
  • the values of the deviation coefficients are updated only if the corresponding volume component x just evaluated is greater than a floor P x which constitutes a minimum value below which the values of the volume component are considered insignificant for the dynamic detection according to the invention.
  • the floor is by default 6 ket / s for volumetry, or 10 packets per second for volubility, or 3 source addresses per second for connectivity.
  • the values of the deviation coefficients are not updated either when the first evaluations of the volume component by the MED module to the MOD module.
  • the first 30 valuations defining a depreciation period prior to modeling are used to update the variables only so that the variables of the "average" type stabilize.
  • the MOD module finally transforms each of the deviation coefficients thus obtained using default elasticity coefficients, in order to avoid potential positive false alarms.
  • the module MOD provides for each volume component x and each coefficient of average c, a dynamic model.
  • This dynamic model is a list including the identifier of the given service entity SE, the granularity, the threshold values S x and floor P x , the date of creation of the model, the designation of the volume component x and the values deviation coefficients CD1, CD2 as well as possibly additional parameters such as for example a temporal coefficient and if it occurs in the prediction modeling mode chosen. Consecutive evaluations of the volume components are then summarized by the data in the models of the different volume components.
  • Each evaluation, when processed by the MOD module, can be cleared.
  • the MOD module saves each model in the DB database in the substep E25.
  • the modeling module MOD includes a submodule for updating MAM models which periodically reads the current old models relating to a given service entity in the DB to provide updated models replacing the current old models.
  • This model replacement is intended to reflect the potential evolution of customer usage for communication with SE protected service entities and thus the evolution of the actual LT link traffic between TC terminals and protected service entities.
  • the discount period can be done for example every week or every month.
  • the MOD module produces updated models based on recent values of the volumic components associated with the service entity, evaluated with the granularity defined in said current models and provided by the MED module since the last update, as in step E20.
  • the recent values of the volumetric components evaluated are first temporarily stored in the evaluation database, then purified of any value that led to the generation of an alert and therefore to the reporting of an abnormal activity of the service entity, verifying that these recent values are consistent with existing legacy models, i.e., they do not trigger an alert by applying a detecting comparison detailed below.
  • a deviation coefficient is updated only if the corresponding evaluated volumetric component has not been purified and therefore has led to no report of abnormal activity in the traffic of the service entity. SE service.
  • the purification may however be skipped by decision of the operator or in accordance with definition of different update modes: for example an "obsolete" mode for which the purification is skipped, and a "normal” mode for which the purification is executed.
  • the submodule MAM updates the corresponding model by again determining the aforementioned variables according to their old current values and the recently assessed value of the volume component.
  • the MOD module determines the values of the deviation coefficients CD1, CD2 in the models in a manner similar to the learning phase.
  • the MAM model update submodule updates the values of the CD1, CD2 deflection coefficients in each model by applying a weighting to the values of the deflection coefficients of the current old model.
  • the weighting may depend on the length and date of creation of the current old model to give less weight to the current old model or created very quickly.
  • the values of the deviation coefficients of the old model are weighted by the duration of the modeling and the inverse of the age of the current old model.
  • the MOD module establishes an age of each registered model expressed in number of days, in association with the identifier of the service entity, the date of creation of the model and a predetermined integer, serving as a phase code, indicating if the model is under construction during the learning phase, in use for detection, or invalid temporarily, or has generated a recent alert.
  • the updated templates are transferred to the DB database, which stores them as in substep E25 to replace and delete the current old templates.
  • the abnormal activity detection step E3 comprises initialization substeps E30 to E32 and comparison sub-steps to the models E33 to E35.
  • the DET anomaly detection module is activated either automatically after the substep E25 of the learning phase, that is to say after the first modeling, or by the operator via the human-machine interface HMI. .
  • the DET module receives from the declaration module DEC and / or from the operator via the interface HMI the list of identifiers and characteristics of the service entities to be protected, and possibly the list of evaluation parameters. , including the granularity of the assessments, for each service entity.
  • the DET module reads in the DB database all the current models corresponding to the parameters, and if for a service entity no granularity is mentioned, the DET module calls in the database DB the current models and therefore the most recent for this service entity and reads their granularities.
  • the DET module has the list of service entities to protect and current models relevant for detection.
  • the DET module loads and stores all these current models in RAM.
  • the identifier and characteristics of the service entity and the The traffic evaluation parameters of this entity necessary for the detection and contained in the models are, after any modification and validation by the operator, subsequently applied by the DET module to the mediation module MED, in the substep E31.
  • the mediation module MED In response to the characteristics and parameters of the service entity, the mediation module MED periodically delivers to the detection module DET an evaluation of the traffic intended for the service entity, in the substep E32.
  • This assessment includes the counts of the COM meters that are assigned to the evaluation of the service entity's volumic components and that are periodically reset to the evaluation period according to the requested granularity for the service entity.
  • the evaluated volumic components of the service entity have "instantaneous" values expressed by the accounts of the respective counters COM that are delivered by the module MED to be processed by the detection module DET.
  • the DET module calls the current models relating to the volume components.
  • Each volume component for the given service entity is associated with at least one current model of normal activity transferred from the database BD into the RAM.
  • the detection module DET evaluates the same variables including means, derivatives and deviation, and the same deviation coefficients CD1, CD2 as those evaluated by the module. model, according to the parameters contained in the model of the volume component, such as the coefficient of average c and the possible temporal coefficient and.
  • the module DET does not carry out detection by use of the coefficients of deviation, during said first evaluations or when the value of the evaluated volume component x is less than the floor P x .
  • the DET module compares the respective value of the deflection coefficient included in the model with the new value of the deviation coefficient just evaluated and increments a respective alert value Al x if the new value of the deflection coefficient is greater than the value of the deflection coefficient included in the model.
  • the DET module For CD2 deviation coefficients of the second type in a model, representative of predictions of duration necessary for a threshold overshoot, the DET module combines the value of the coefficient of deviation CD2 included in the model with variables that have just been evaluated to determine a prediction value. The DET module compares the prediction value with the threshold S x of the volume component x included in the model and increments a respective alert value A2 X if the prediction value is greater than the threshold S x .
  • the DET module groups together the alert values Al x , A2. X relating respectively to the deflection coefficients in an alert vector.
  • the DET module also determines an overall deviation DG according to the alert values Al x , A2 X for the assessed volume components, for example equal to the root mean square of the alert values.
  • the alert vector thus represents the more or less pronounced similarity of the evaluation to the current models relevant for this evaluation.
  • the alert vector is delivered to the ALE alert module responsible for the output of alerts.
  • the ALE alert module decides whether the alert vector should generate an alert or not. For this, the ALE module examines said alert vector, and determines according to this alert vector a global alert value. If the global alert value exceeds a predetermined alert level, the ALE module reports abnormal activity in the service entity SE traffic by transmitting an alert to the operator via the HMI interface, and / or to an external device.
  • the alert transmitted is accompanied by the values of the volume components of the evaluation that triggered the alert, the relevant deviation coefficient thresholds at the time of the evaluation, and a type of alert depending on the values of the deviations of volume components.
  • the method of detecting anomalies according to the invention is provided to be able to detect anomalies relating to the traffic of several service entities supported by the transmission link.
  • each service entity is declared by a destination address, at least one transport protocol and at least one port and a list of volume components to be evaluated for the predetermined duration.
  • the invention described herein relates to a method and a computing device DD for detecting anomalies in the traffic supported by the transmission link LT and relating to one or more service entities SE.
  • the steps of the method of the invention are determined by the instructions of a computer program incorporated in the computing device.
  • the program comprises program instructions which, when said program is loaded and executed in the device, whose operation is then controlled by the execution of the program, carry out the steps of the method according to the invention.
  • the invention also applies to a computer program, including a computer program on or in an information carrier, adapted to implement the invention.
  • This program can use any programming language, and be in the form of source code, object code, or intermediate code between source code and object code such as in a partially compiled form, or in any other form desirable to implement the method according to the invention.
  • the information carrier may be any entity or device capable of storing the program.
  • the medium may comprise storage means or recording medium, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a USB key, or a magnetic recording means, for example a floppy disk or a hard disk.
  • the information medium may be a transmissible medium such as an electrical or optical signal, which may be conveyed via an electrical or optical cable, by radio or by other means.
  • the program according to the invention can in particular, be downloaded on an internet-type network.
  • the information carrier may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in carrying out the method according to the invention.

Abstract

Dans un dispositif détectant rapidement des anomalies dans le trafic (LT) relatif à au moins une entité de service (SE) suite à des attaques de type déni de service par inondation, un module (MOD) modélise l'activité normale de l'entité par des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée. Chaque modèle d'une composante volumique comprend des coefficients de déviation dépendant d'une moyenne mobile de la composante volumique évaluée pendant ladite durée. Pour au moins une évaluation ultérieure, un module (DET) incrémente une valeur d'alerte pour au moins un coefficient de déviation si une nouvelle valeur de celui-ci excède un seuil du modèle.

Description

Détection dynamique d'anomalies dans le trafic relatif à une entité de service
La présente invention se rapporte au domaine de la sécurité des réseaux et aux attaques de type déni de service par inondation. Plus particulièrement elle a trait à une détection d'anomalies dans le trafic supporté par une liaison de transmission et relatif à au moins une entité de service.
Les réseaux de télécommunications, comme 1' internet, transmettent des données entre différentes entités de service, via une infrastructure commune. Une entité de service connectée à un tel réseau répond à des requêtes de terminaux de clients en leur fournissant un service, c'est-à-dire en effectuant des actions bien définies et demandées par les clients . Des entités de service sont par exemple un serveur web, un serveur de contenus ou de streaming proposant un téléchargement de fichiers multimédias ou diffusant des fichiers multimédias, un serveur de messagerie électronique qui relaie des messages, ou un serveur de noms de domaine DNS qui fournit des adresses IP correspondant à des noms de domaine. Ces entités de service sont, dans certains cas, des extrémités du réseau et sont localisées chez des clients d'un opérateur, tandis que d'autres entités de service, tels les serveurs DNS, sont gérées par l'opérateur du réseau lui-même. Une attaque par déni de service est une attaque qui vise à rendre indisponible une entité de service. Il existe plusieurs types d'attaques par déni de service, par exemple des requêtes spécifiques qui attaquent directement le fonctionnement de l'entité de service en lui demandant d'effectuer une action "non conforme" . Parmi les attaques par déni de service, les attaques de type déni de service par inondation consistent à dépasser, et donc à "inonder" la capacité réseau de l'entité de service ou de la liaison de transmission par laquelle l'entité de service est reliée au réseau. Dans les deux cas, des caractéristiques volumiques du trafic réseau à destination de l'entité de service augmentent soudainement . Afin de détecter les attaques par déni de service, il existe deux grandes familles de procédés de détection.
La première famille est relative aux détections par signature. Elle consiste à observer de manière continue le trafic à proximité d'une entité de service potentielle, et à comparer les observations avec des motifs de trafic conservés en mémoire et qui caractérisent des attaques connues. Les procédés de détection de la première famille sont particulièrement adaptés à la détection d'intrusion et la détection de dénis de service non basés sur l'inondation des entités de service.
L'invention concerne davantage la deuxième famille qui est relative aux détections d'anomalies. Une anomalie est une évaluation de trafic non conforme à un ensemble d'évaluations de trafic normal admissibles. L'ensemble des évaluations admissibles est déterminé a priori à l'aide de règles et de connaissances expertes. Il existe plusieurs types de règles telles qu'une liste de contrôle d'accès et des politiques de sécurité, fixées par l'opérateur ou le client qui possède une entité de service. Ces règles définissent des caractéristiques que le trafic normal doit satisfaire ou au contraire ne pas satisfaire. Cependant, ces règles sont insuffisantes : les entités de service les plus sensibles et les plus visées par la cyber-criminalité sont aussi les plus difficiles à protéger a priori ; en particulier, on traite le trafic d'entités de service dont les clients ne sont pas connus à l'avance, et les règles que l'on peut fixer a priori sont limitées. Une attaque peut en effet se conformer à la plupart des règles fixées a priori dans la forme du trafic que l'attaque envoie pour inonder l'entité de service. Pour éviter cela, il est nécessaire de fixer en plus des règles de type "seuil" sur des composantes volumiques du trafic. Pour une bonne qualité de détection, ces seuils doivent prendre en compte le trafic de l'entité de service en temps normal, ce qui implique une phase d'apprentissage du trafic normal par le procédé de détection, le succès de l'attaque étant fondé sur la quantité de trafic d'attaque effectivement parvenu à l'entité de service pour traitement. Si les règles sont des seuils de trafic, leur efficacité et leur pertinence dépend de la différence entre ces seuils et l'activité du service au moment de l'attaque. Il est donc important que de telles règles prennent en compte l'activité du service, et des règles définies a priori sont insuffisantes.
La détection d'anomalies comportementales consiste à modéliser l'activité de l'entité de service à protéger en l'observant et en modélisant son comportement. Peu de procédés de détection d'anomalies connus sont orientés spécifiquement vers les attaques par inondation. Etant donné des évaluations et un modèle de comportement de l'entité de service, ces procédés font appel à des variables statistiques pour prédire la ou les prochaines évaluations . Si les prochaines évaluations effectives divergent significativement des évaluations prédites, alors une alerte est signalée. Cependant ces procédés de détection d'anomalies détectent également des attaques autres que les attaques par inondation, induisant une perte de temps de traitement par l'opérateur de sécurité.
Par ailleurs sont connus des procédés de détection d'anomalies dédiés à la détection d'attaques par inondation. Mais leur coût est élevé et leurs algorithmes sont maintenus confidentiels. Certains de ces procédés de lutte contre les attaques par inondation sont conçus pour être installés au cœur de réseau et/ou se basent sur des informations basées sur un mécanisme de comptage installé dans des routeurs, lesquelles informations ne caractérisent que très grossièrement les attaques.
L'invention a pour objectif de détecter dynamiquement près d'une entité de service à protéger des anomalies comportementales aussi bien dans le trafic dirigé vers cette entité de service que dans le trafic qui en provient, en recourant à des coefficients et règles pouvant évoluer avec le trafic et sans recourir à une prédiction d'évaluations de variables statistiques, de manière à signaler très rapidement et précisément une attaque de type déni de service par inondation.
Pour atteindre cet objectif, un procédé pour détecter des anomalies dans le trafic supporté par une liaison de transmission et relatif à une entité de service, incluant préalablement une modélisation de l'activité normale de l'entité de service, est caractérisé en ce que la modélisation fournit des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, ledit procédé comprenant pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques, une incrémentation d'une valeur d'alerte respective pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle.
Le procédé de l'invention est fondé non pas sur des valeurs absolues de paramètres du trafic de l'entité de service à un instant donné, mais sur des coefficients de déviation dépendant au moins de deux évaluations d'une composante volumique, de manière à observer les transitions comportementales dans le trafic relatif à l'entité de service. En particulier, 1 ' invention extrapole une activité dynamique normale de l'entité de service en fondant les coefficients de déviation sur des moyennes et dérivées discrètes de trafic évaluées lors de la modélisation et pouvant être actualisées périodiquement au plus à chaque évaluation des composantes volumiques . A chaque évaluation ultérieure de composantes volumiques et de coefficients de déviation, les coefficients de déviation sont comparés à des seuils pour détecter si les transitions comportementales dans la succession des évaluations restent plus faibles que les transitions comportementales selon les modèles; sinon une valeur d'alerte est incrémentée. Ainsi, l'invention permet de détecter une activité anormale dans le trafic de l'entité de service lorsque la valeur d'alerte excède un niveau d' alerte prédéterminé . L'invention détecte et caractérise une attaque de type déni de service par inondation afin de protéger des entités de service d'un opérateur ou de ses clients par exemple. Lorsqu'une attaque de type déni de service par inondation est détectée, l'invention la caractérise par le résultat de comparaisons des coefficients de déviation évalués à des valeurs de seuil, lequel résultat peut représenter une anomalie sous forme d'une variation anormale des composantes volumiques évaluées . On notera que, dans le cadre de l'invention, les évaluations de composantes volumiques peuvent porter sur le trafic à destination de l'entité de service à protéger, ou sur le trafic provenant de cette entité, ou sur ces deux trafics à la fois. La détection d'anomalies comportementales selon l'invention est dite "dynamique" parce qu'elle repose sur des mesures de déviations de trafic de manière relative en fonction d'évaluations successives de composantes volumiques, indépendamment de valeurs absolues, et n'a pas vocation à traiter des périodes d'activité stable de l'entité de service surveillée.
Grâce à l'invention, et notamment à la modélisation incluant une moyenne mobile, on peut donc avantageusement effectuer une analyse statistique fine du trafic relatif à une entité de service .
Selon des caractéristiques particulières, ladite moyenne mobile est une moyenne mobile à pondération exponentielle . Cette disposition permet avantageusement de réduire la quantité de données à mémoriser par comparaison, par exemple, à la quantité de données requise dans le cas d'une moyenne mobile arithmétique de la composante volumique, puisqu'une telle moyenne devrait être recalculée à chaque fois sur la base de valeurs précédentes de la composante volumique, qui devraient donc être mémorisées à cet effet.
Afin d'assurer une détection efficace des anomalies lorsque le trafic normal relatif à l'entité de service évolue, l'invention prévoit, selon des caractéristiques particulières, une actualisation de modèles pour remplacer périodiquement des modèles anciens courants relatifs à l'entité de service par des modèles actualisés en fonction de valeurs récentes des composantes volumiques et des coefficients de déviation associés à l'entité de service. A chaque évaluation, une valeur courante d'un coefficient de déviation du premier type est actualisée en remplaçant ladite valeur courante par la moyenne de celle-ci et d'une nouvelle valeur du coefficient de déviation si ladite nouvelle valeur est supérieure à la valeur courante du coefficient de déviation lorsque le coefficient de déviation est d'un premier type, ou si ladite nouvelle valeur est inférieure à la valeur courante du coefficient de déviation lorsque le coefficient de déviation est d'un deuxième type.
L'invention concerne également un dispositif pour détecter des anomalies dans le trafic supporté par une liaison de transmission et relatif à une entité de service, l'activité normale de l'entité de service étant préalablement modélisée, et une sonde de trafic incluant le dispositif pour détecter des anomalies. Le dispositif est caractérisé en ce qu'il comprend un moyen pour modéliser l'activité normale de l'entité de service par des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, un moyen pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques pour incrémenter une valeur d'alerte respective pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle.
Selon des caractéristiques particulières, ladite moyenne mobile est une moyenne mobile à pondération exponentielle.
Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre dans un dispositif de détection d'anomalies selon l'invention. Le programme comprend des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent les étapes du procédé de détection d'anomalies selon l'invention.
D'autres caractéristiques et avantages de la présente invention apparaîtront plus clairement à la lecture de la description suivante de plusieurs réalisations préférées de l'invention, données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels : - la figure 1 est un bloc-diagramme schématique d'un dispositif de détection d'anomalies dynamique dans un réseau de type internet, selon l'invention; et - la figure 2 est un algorithme du procédé de détection d'anomalies dynamique selon l'invention.
En référence à la figure 1, un dispositif de détection d'anomalies dynamique DD selon l'invention est inclus dans une sonde de trafic et fait office d'agent essentiellement logiciel pour inhiber des attaques contre des entités de service SE dans un réseau de télécommunications par paquets à débit élevé RT géré par un opérateur selon le protocole IP (Internet Protocol) . Des données sont transmises dans une liaison de transmission LT du réseau RT constituant une partie de l' internet. Les données sont par exemple contenues dans des paquets transmis par des terminaux de client TC et destinées aux entités de service SE comprenant des serveurs web. La liaison de transmission LT est située à proximité des entités de service SE dont le trafic est à surveiller par la sonde afin que celle-ci détecte des anomalies dans le trafic qui caractérisent des comportements anormaux des clients des entités de service, particulièrement des attaques par inondation des entités de service.
Par exemple, la liaison de transmission LT à laquelle la sonde est connectée en écoute selon la figure 1, est située dans le réseau RT au point d'entrée d'une ou plusieurs entités de service sur le réseau, entre le réseau RT et le dernier routeur RO de l'opérateur du réseau RT précédant un routeur relié à une entité de service SE. La sonde n'est pas connectée à une liaison du client entre le routeur RO et l'entité de service SE dont le trafic pourrait être déjà congestionné à cause de la capacité limitée de la liaison du client.
En variante, la sonde est connectée en coupure à la liaison de transmission LT de manière également à retirer des paquets anormaux destinés à une ou plusieurs entités de service surveillées.
Le dispositif de détection DD signale une alerte à partir de l'observation du trafic relatif à l'entité ou les entités de service dans la liaison LT afin que l'opérateur prenne des mesures adéquates pour contrer une attaque dirigée vers l'entité ou les entités de service.
Quelle que soit l ' implémentation de la sonde, limitée ou non au dispositif de détection dynamique de l'invention, la sonde émet des alertes à partir de l'écoute du trafic en un point du réseau RT.
Comme montré à la figure 1, le dispositif de détection dynamique DD peut être sous la forme d'un ordinateur ou d'une station de travail, ou d'un système informatique local ou réparti. En relation avec l'invention, le dispositif DD comprend les modules suivants : une interface homme - machine de management IHM, locale ou éloignée, incluant notamment un clavier et un écran, pour activer le dispositif automatiquement ou manuellement par un opérateur et saisir notamment des identificateurs et caractéristiques d'entité de service, sélectionner des données pour la détection et lire des alertes; un module de déclaration d'entité de service DEC pour sélectionner une partie du trafic à surveiller dans la liaison LT qui est destinée à des entités de service SE à protéger; un module de médiation MED connecté en écoute selon la figure 1, ou en coupure en variante, à la liaison de transmission LT afin d'évaluer des composantes volumiques de trafic; un module de modélisation MOD qui construit des modèles d'activité normale pour les entités de service à protéger en fonction de valeurs de composantes volumiques de trafic évaluées par le module de médiation MED afin de produire des modèles de comportement dynamique pour chaque entité de service protégée et pour chaque composante volumique; une base de données DB pour enregistrer des modèles relatifs aux composantes volumiques des entités de service; un module de détection d'anomalies DET détectant des anomalies dans le trafic observé destiné aux entités de service à protéger, anomalies qui sont décelées sous forme de franchissements anormaux de valeurs de seuil des modèles d'activité normale par des coefficients de déviation évalués en fonction des composantes volumiques; et un module d'alerte ALE délivrant des alertes suite à des franchissements anormaux des coefficients de déviation.
Le procédé de détection dynamique d'anomalies de trafic selon l'invention est mis en œuvre dans le dispositif de détection DD et comprend trois étapes principales El, E2 et E3, comme montré à la figure 2. Les étapes El, E2 et E3 comprennent respectivement des sous-étapes ElO à E12, E20 à E26 et E30 à E35. Des sous-étapes sont également indiquées dans la figure 1 au niveau de liens entre des modules du dispositif de détection DD intervenant pour l'exécution de ces sous-étapes. La première étape El comporte une déclaration des entités de service SE à protéger explicitement par l'opérateur, ce qui définit un ensemble de services à protéger dispensés par ces entités.
A la première sous-étape ElO de l'étape de déclaration d'entité de service El, l'opérateur définit des entités de service SE qu'il souhaite protéger dans le module de déclaration DEC via l'interface homme - machine IHM. Le module DEC sélectionne ainsi une partie du trafic dans la liaison LT qui est destinée à chaque entité de service déclarée.
L'opérateur définit explicitement des entités de service en saisissant des identificateurs et des caractéristiques des entités de service à protéger transmis au module DEC, ou bien en saisissant des identificateurs des entités de service transmis au module DEC qui lit des caractéristiques des entités de service sélectionnées en correspondance aux identificateurs des entités dans une liste préenregistrée dans une base en relation avec la liaison LT. Les caractéristiques identifiant une entité de service sont par exemple des triplets . Typiquement le triplet de caractéristiques d'une entité de service inclut une adresse de destination ou classe d'adresse de destination IP, un protocole de transport et un port. Les identificateurs d'entité de service peuvent aussi être spécialisés, par exemple être les triplets de caractéristiques eux- mêmes .
Par exemple, une entité de service déclarée a pour triplet de caractéristiques (adresse de destination IP, protocole (s) de transport T, port (s) P) : une adresse de destination IP qui est au format
'w.x.y.z/m', avec w, x, y et z compris entre 0 et
255, et m compris entre 0 et 32, et éventuellement affectée d'un masque selon la notation CIDR (Classless Internet Domain Routing) ; par exemple:
159.151.254.0/25 signifie de l'adresse 159.151.254.0 à l'adresse 159.151.254.127 puisque 232 - 225 -
1 = 127; une liste de protocoles de transport qui est au format fpl;p2' avec pi, p2, ... des valeurs en nombre fini prises dans des mots-clés tels que 'tcp', 'udp', ' ip ' , 'icmp', la valeur 'ip' recouvrant à la fois 'tcp' et 'udp'; et une liste de ports qui est au format fpl;p2;p3- p4 ' avec pi, p2, p3, p4, ... des valeurs entières comprises entre 0 et 65535 et pouvant être incluses dans une plage de valeurs entières, par exemple '3200-3299', ou dans une liste de valeurs entières, par exemple '3200; 3202; 3208'. Des entités de service "complémentaires" peuvent être implicitement déclarées à la suite de la déclaration explicite des entités de service à protéger. Une entité de service complémentaire implicite peut être une entité de service déclarée par défaut afin de recouvrir des attaques sur des protocoles spécifiques, comme les trafics indésirables selon le protocole de paquet de commande 'icmp' (Internet Control Message Protocol) . Une entité de service complémentaire implicite peut être construite comme un complément à au moins une entité de service déclarée ayant une adresse IP, et relative à des trafics autres que ceux qui concernent des services hébergés par l'entité de service déclarée mais ayant ladite adresse IP et par exemple des ports différents. Les entités de service "complémentaires" sont inférées automatiquement des caractéristiques des entités de service déclarées pour synthétiser l'activité de la liaison LT du réseau qui n'est pas explicitement déclarée par l'opérateur. Les entités de service complémentaires à protéger ont des triplets de caractéristiques (adresse de destination IP, protocole (s) de transport T, tous ports sauf P) et (adresse de destination IP, protocole (s) de transport sauf T, port (s) P) .
En variante, à une étape ElOa pouvant être conjointe à l'étape ElO ou la remplacer pour certaines entités de service, la déclaration d'entités de service est automatique grâce à une écoute du trafic dans la liaison LT par le module de déclaration DEC. Dans cette variante, le module DEC est connecté en écoute selon la figure 1. Le module DEC établit une liste des entités de service demandées par les paquets qui passent dans la liaison LT et classe ces entités de service par fréquence d'apparition des paquets destinés à ces entités, afin d'obtenir une pré-liste des entités de service. Ensuite, cette liste est réduite automatiquement afin par exemple de ne conserver en mémoire du module DEC que les entités de service demandées par plus de 1% des paquets, ou bien est modifiée par l'opérateur. La liste ainsi établie est la liste des entités de service à protéger.
Après l'étape ElO ou ElOa, les entités de service à protéger par le dispositif DD sont bien identifiées .
Le module de modélisation MOD est initialisé en recevant la liste des identificateurs des entités de service à protéger fournie par le module de déclaration DEC. Le module MOD reçoit la liste automatiquement à la sous-étape ElI, ou en variante après validation de l'opérateur via l'interface IHM à la sous-étape Ella.
A chaque entité de service à protéger, le module de modélisation MOD associe des paramètres d'évaluation de trafic par défaut qui sont une granularité et une liste par défaut de composantes volumiques de trafic à destination, ou éventuellement en provenance, de l'entité de service SE. La granularité définit une période d'évaluation du trafic de l'entité de service et peut être une valeur par défaut dépendant d'une caractéristique de l'entité de service. Par exemple, la granularité est 10 secondes si le port P de l'entité de service est 80 (HTTP) , ou 1 minute si le port est 23 (Telnet) .
Les composantes volumiques de trafic dans la liste par défaut correspondent à des caractéristiques pouvant être relevées à partir d'informations des couches de réseau et de transport et agrégées sous forme de comptes de compteurs remis à zéro à chaque période d'évaluation de trafic définie par la granularité. Les composantes volumiques sont par exemple : au niveau de la couche de réseau IP : la volumétrie exprimée par un débit de trafic en octets par seconde, la volubilité exprimée par un débit de trafic en paquets par seconde, la connexité exprimée par un nombre d'adresses de source différentes dans des paquets destinés à l'entité de service, et la fragmentation exprimée par un taux de paquets fragmentés en fonction des bits DF et MF dans le champ drapeau de l'entête d'un paquet IP; et au niveau de la couche de transport TCP ("Transmission Control Protocol", mots anglais signifiant "Protocole de Commande de Transmission") : l'ouverture de connexion exprimée par un taux de paquets incluant un bit de contrôle SYN à "1", le "stress" exprimé par un taux de paquets incluant un bit de contrôle PUSH à "1" indiquant que les données sont à transférer à la couche supérieure, l'urgence exprimée par un taux de paquets incluant un bit de contrôle de message urgent URG à "1", et la volatilité exprimée par un nombre de ports différents sollicités.
Pour chacune x de ces composantes volumiques, un seuil Sx, que ne doit pas dépasser la composante volumique, et un plancher Px, au-dessous duquel les évaluations des composantes volumiques sont considérées comme non-pertinentes, sont définis a priori par l'opérateur ou bien par défaut suivant les capacités des entités de service protégées.
A la liste par défaut de composantes volumiques de trafic peut être ajoutée une liste d'autres composantes volumiques spécifiques qui dépendent de l'entité de service, comme des grandeurs propres à un protocole applicatif utilisé. Par exemple une composante volumique à évaluer sur un service HTTP (HyperText Transfer Protocol) est le nombre de requêtes sur une méthode spécifique, comme la méthode 'GET', le nombre de requêtes vers des pages CGI (Common Gateway Interface) , PHP (Personal Home Page) , JSP (Java Server Page), ou un code d'erreur de type 2xx, 3xx, 4xx ou 5xx renvoyé par le serveur impliquant une mesure du trafic retour, ou la version du protocole utilisée (0.9, 1.0, 1.1). Cependant à la sous-étape Ella, via l'interface
IHM, l'opérateur peut modifier manuellement la liste de composantes volumiques ainsi que tout autre paramètre d'évaluation qui a pris une valeur par défaut, comme la granularité.
A la sous-étape E12, le module MOD transmet une liste des entités de service, éventuellement après validation de l'opérateur, au module de médiation MED du dispositif DD. Pour l'activité normale de chaque entité de service à protéger que le module MOD doit modéliser, la liste d'entités de service comprend l'identificateur et les caractéristiques de l'entité de service et les composantes volumiques de trafic nécessaires à la modélisation afin qu'à partir de ces composantes volumiques, le module MOD produise un modèle de comportement dynamique de l ' entité de service .
Au début E20 de l'étape de modélisation d'activité d'entité de service E2, le module de médiation MED extrait de chaque paquet pertinent capturé dans la liaison LT et destiné à une entité de service identifiée à protéger, notamment l'adresse de source IP, l'adresse de destination IP, la valeur du champ de protocole de transport, le port source, le port destination, la longueur totale du paquet en octets, le champ drapeau avec les bits de fragmentation, et la liste des drapeaux TCP, afin d'évaluer les composantes volumiques. Pour chaque entité de service, le module MED comprend des compteurs COM respectivement qui comptent par exemple des octets, paquets, adresses de source prédéterminées et bits de contrôle prédéterminés pour exprimer les composantes volumiques et qui sont ainsi assignés à l'évaluation des composantes volumiques de l'entité de service. Les compteurs sont réinitialisés régulièrement à la période d'évaluation selon la granularité, par exemple de l'ordre de quelques secondes, typiquement 10 secondes. Chaque évaluation des composantes volumiques est horodatée avec la date de début de la période. Au cours de la sous-étape E20 et à l'expiration de chaque période d'évaluation, les comptes des compteurs constituent des valeurs des composantes volumiques de trafic demandées qui sont agrégées, formatées et fournies par le module MED au module MOD.
Les composantes volumiques fournies par le module MED sont conservées temporairement dans une base d'évaluations incluse dans le module MOD. Pour une entité de service donnée SE, le module MOD traite une suite d'ensembles de valeurs de composantes volumiques qui ont été évaluées pendant une durée prédéterminée qui est très supérieure à la période d'évaluation de granularité retenue pour l'agrégation des composantes volumiques, ou bien définie par l'opérateur. En particulier, pour l'entité de service donnée, les modèles dépendent de valeurs des composantes volumiques qui sont établies consécutivement au cours d'une durée prédéterminée propre à l'entité de service, pendant laquelle l'entité de service passe par tous les comportements d'activité normale que l'entité de service aura lors de la phase de détection. Par conséquent, compte tenu des variations de l'activité des terminaux de client TC, la durée prédéterminée est par exemple au moins une semaine ou un mois et est définie par l'opérateur. La modélisation dynamique selon l'invention ne détermine pas ainsi des périodes d'activité stable divisant une longue durée de fonctionnement de l'entité de service protégée. La durée prédéterminée pendant laquelle les comptes des compteurs COM sont lus et fournis au module MOD pour effectuer la première modélisation relativement à plusieurs entités de service à protéger supposées en activité normale après la mise en marche du dispositif de détection DD constitue une phase d'apprentissage. A partir de ces composantes volumiques évaluées pendant la phase d'apprentissage pour les entités de service à protéger, le module MOD produit des modèles de comportement dynamique de chaque entité de service protégée, comme expliqué ci- après .
Pour modéliser le comportement du trafic à destination de l'entité de service donnée SE et ainsi l'activité normale de celle-ci en des modèles, le module MOD évalue des coefficients de comportement dynamique admissibles appelés coefficients de déviation CD utilisés par la suite pour la détection dynamique d'anomalies par comparaison.
A cette fin, à la sous-étape E21 le module de modélisation MOD évalue en temps réel plusieurs variables à partir des évaluations des composantes volumiques. Pour chaque composante volumique surveillée x relative à l'entité de service donnée, le module MOD actualise une ou plusieurs moyennes mobiles à pondération exponentielle pendant la durée prédéterminée en fonction d'un ou plusieurs coefficients de moyenne choisis.
On considère la valeur Mn calculée par récurrence à partir de valeurs xo à xn de la manière suivante :
Mo = xo ^ et Pour n > 0: Mn = Cxn + (1 - C)Mn-I , où C est une constante judicieusement choisie. On dit alors que Mn est la "moyenne mobile à pondération exponentielle", à coefficient de pondération C, des valeurs xo à xn. On choisit C = 2/ (1+c) e [0, 1] , où c est un coefficient de moyenne, par exemple choisi préalablement par défaut pour un modèle dans une liste de coefficients de moyenne {1, 3, 9, 27} dont dispose le module MOD et qui peut être modifiée par l'opérateur.
On montre que la moyenne Mj avec I ≥ n+1 ne dépend que des I-n moyennes évaluations précédentes selon la relation :
Mi = £ C (1 - C)1"1 xi + (1 - C)1"11 Mn i=n+l
si les coefficients (1 - C) pour k > I-n sont négligeables .
La moyenne mobile Mj dépend ainsi mathématiquement des I-n dernières évaluations, c'est-à-dire "a une mémoire" de I-n évaluations, bien que son actualisation par le module MOD ne nécessite, outre l'ancienne valeur Mj-i de la moyenne, que la mémorisation de la valeur de la dernière évaluation de la composante volumique xi .
Le module MOD actualise une moyenne à pondération exponentielle MMn des valeurs Mi à Mn de la moyenne mobile de la même manière selon la formule : MMn = C Mn + (1 - C)MMn-I.
Outre la moyenne mobile à pondération exponentielle et la moyenne de la moyenne mobile, le module MOD détermine aussi d'autres variables parmi lesquelles une "dérivée première" discrète de composante volumique dn = C (xn - Mn-i) proportionnelle à la différence de la nouvelle valeur de la composante volumique et de la moyenne mobile courante Mn-I, une "dérivée seconde" discrète de composante volumique ddn = dn - dn-i égale à la différence de la nouvelle valeur de la dérivée première dn et de la valeur courante de la dérivée première dn-i, une moyenne mobile à pondération
2 2 exponentielle des carrés xo à xn des valeurs de la
2 composante volumique Nn = C Xn + (1 - C)Nn-I , et une déviation mobile SDn égale à la racine carrée de la valeur absolue Nn - Mn I de la différence de la moyenne mobile des carrés et du carré de la moyenne mobile. Cette déviation est strictement positive dès qu'au moins une valeur non nulle de la composante volumique a été observée. En particulier un mécanisme de plancher décrit plus loin assure que tous les calculs faisant intervenir ladite déviation mobile ne sont effectués que lorsque ladite déviation mobile est strictement positive.
En fonction des valeurs de ces variables courantes (Mn-I, MMn-I, dn-i, ddn-i, Nn-I, SDn_i) déterminées à l'évaluation courante précédente n-1 de la composante volumique et (Mn, MMn, dn, ddn, Nn, SDn) déterminées à la nouvelle évaluation de la composante volumique n, le module MOD évalue des coefficients de déviation d'un premier type CDl et des coefficients de déviation d'un deuxième type CD2 pour conférer un caractère dynamique à la détection d'anomalies de trafic, aux sous-étapes courantes E22 et E23. Les coefficients de déviation CDl du premier type relatifs à une composante volumique x et à un coefficient de moyenne c dépendent de certaines variables, comme la composante volumique, la moyenne mobile à pondération exponentielle, la moyenne à pondération exponentielle de la moyenne mobile, et la moyenne à pondération exponentielle des carrés de valeurs de la composante volumique. Les coefficients de déviation CDl servent à vérifier la conformité de l'évaluation courante des composantes volumiques de l'entité de service par rapport à des évaluations précédentes. Selon un premier exemple, un coefficient de déviation CDln du premier type relatif à la composante volumique x est égal au rapport (xn -
Mn) /SDn entre la différence entre la composante volumique évaluée Xn et la moyenne mobile Mn, et la déviation mobile SDn. Selon un deuxième exemple, lorsque le coefficient de pondération C est choisi différent de 1, un coefficient de déviation CDln du premier type relatif à la composante volumique x est déduit de la formule :
CDln = [xn - 2Mn + MMn - C(Mn - MMn) /(I - C) ] /SDn . Dans ces deux exemples, les coefficients de déviation CDln sont choisis égaux à 0 si la déviation mobile SDn est nulle. A la sous-étape E22, le module MOD compare l'ancienne valeur courante CDln-I du coefficient de déviation à la nouvelle valeur du coefficient de déviation CDln, et actualise la valeur courante suivant une règle qui peut être par exemple : si la nouvelle valeur CDln du coefficient de déviation est supérieure à la valeur courante CDln-I du coefficient de déviation, remplacer ladite valeur courante par la moyenne suivante de celle-ci et de ladite nouvelle valeur : (CDin-HCr-I)CDi11-1)Zr , où Test une constante entière, par exemple égale à la durée exprimée en jours de l'apprentissage, arrondie à l'entier supérieur.
A la sous-étape E23 le module de modélisation MOD évalue les coefficients de déviation d'un deuxième type CD2 qui relativement à une composante volumique dépendent de certaines variables, comme la composante volumique, la moyenne mobile à pondération exponentielle, la moyenne à pondération exponentielle de valeurs de la moyenne mobile, la dérivée première discrète de composante volumique proportionnelle à la différence de la composante volumique évaluée et de la moyenne mobile, la dérivée seconde discrète de composante volumique égale à la différence d'une nouvelle valeur et d'une valeur courante de la dérivée première, et un seuil commun respectif Sx. Les coefficients de déviation CD2 servent à prédire la conformité de prochaines évaluations de chaque composante volumique succédant à l'évaluation courante, par rapport au seuil Sx fixé pour la composante volumique, en dépendance d'évaluations courante et nouvelle de celle-ci. A cette fin, le module MOD effectue en outre de plusieurs manières une modélisation par prédiction d'une durée nécessaire pour que la composante volumique traitée x excède le seuil respectif Sx qui lui a été attribué initialement et qui est une valeur maximale de la composante volumique admissible par l'entité de service donnée SE. Selon deux exemples pour ce deuxième type de coefficient de déviation, un coefficient de déviation CD2n relatif à la composante volumique x est déduit de la formule : CD2n = (Sx - Mn)Mn, ou de la formule : CD2n = (dn 2 + 2 ddn (Sx - Mn) ).
A la sous-étape E23, le module MOD compare l'ancienne valeur courante CD2n-i du coefficient de déviation à la nouvelle valeur du coefficient de déviation CD2n, et actualise la valeur courante suivant une règle qui peut être par exemple : si la nouvelle valeur du coefficient de déviation CD2n est inférieure à la valeur courante CD2n-i du coefficient de déviation, remplacer ladite valeur courante par la moyenne (CD2n + (T - l)CD2n_i / T) de celle-ci et ladite nouvelle valeur.
Un autre mode de modélisation par prédiction consiste en ce que le module MOD possède initialement une liste de constantes appelées coefficients temporels et, par exemple {10, 30, 60}, et détermine des valeurs de la composante volumique prédites à des dates postérieures à la date courante de l'évaluation de composante volumique, augmentées respectivement de coefficients temporels de la liste. La règle d'actualisation du coefficient de déviation est par exemple : si la nouvelle valeur du coefficient de déviation est supérieure à la valeur courante du coefficient de déviation, remplacer ladite valeur courante par la moyenne de celle-ci et ladite nouvelle valeur.
Avantageusement pour éviter d'obtenir des coefficients de déviation admissibles trop élevés, les valeurs des coefficients de déviation ne sont actualisées que si la composante volumique correspondante x venant d'être évaluée est supérieure à un plancher Px qui constitue une valeur minimale en dessous de laquelle les valeurs de la composante volumique sont considérées comme non significatives pour la détection dynamique selon l'invention. Par exemple le plancher est par défaut 6 koetet/s pour la volumétrie, ou 10 paquets par seconde pour la volubilité, ou 3 adresses de source par seconde pour la connexité. Les valeurs des coefficients de déviation ne sont pas non plus actualisées lors de la transmission des premières évaluations de la composante volumique par le module MED au module MOD. Par exemple les 30 premières évaluations définissant une période d'amortissement préalable à une modélisation servent à actualiser les variables uniquement afin que les variables de type "moyenne" se stabilisent. Le module MOD transforme enfin chacun des coefficients de déviation ainsi obtenus à l'aide de coefficients d'élasticité par défaut, afin d'éviter de potentielles fausses alarmes positives. Finalement, à la sous-étape E24 après la durée prédéterminée de modélisation au cours de laquelle les divers coefficients de déviation fixent un comportement normal de changement d'activité de l'entité de service SE, le module MOD fournit pour chaque composante volumique x et chaque coefficient de moyenne c, un modèle dynamique. Ce modèle dynamique est une liste comprenant l'identificateur de l'entité de service donnée SE, la granularité, les valeurs de seuil Sx et plancher Px, la date de création du modèle, la désignation de la composante volumique x et les valeurs des coefficients de déviation CDl, CD2 ainsi qu'éventuellement des paramètres supplémentaires comme par exemple un coefficient temporel et si celui-ci intervient dans le mode de modélisation par prédiction choisi. Les évaluations consécutives des composantes volumiques sont alors résumées par les données dans les modèles des différentes composantes volumiques.
Chaque évaluation, lorsqu'elle a été traitée par le module MOD, peut être effacée. En fin de modélisation, le module MOD enregistre chaque modèle dans la base DB à la sous-étape E25.
Le module de modélisation MOD comprend un sous- module d'actualisation de modèles MAM qui périodiquement lit les modèles anciens courants relatifs à une entité de service donnée dans la base DB pour fournir des modèles actualisés remplaçant les modèles anciens courants . Ce remplacement de modèles vise à refléter l'évolution potentielle des usages des clients en matière de communication avec les entités de service protégées SE et donc l'évolution du trafic réel dans la liaison LT entre les terminaux TC et les entités de service protégées. La période d'actualisation peut être réalisée par exemple toutes les semaines ou tous les mois.
Pour une actualisation de modèles E26 répétant au moins les sous-étapes E20 à E25, le module MOD produit des modèles actualisés en fonction de valeurs récentes des composantes volumiques associées à l'entité de service, évaluées avec la granularité définie dans lesdits modèles courants et fournies par le module MED depuis la dernière actualisation, comme à l'étape E20. Les valeurs récentes des composantes volumiques évaluées sont d'abord conservées temporairement dans la base d'évaluations, puis épurées de toute valeur ayant conduit à la génération d'une alerte et donc au signalement d'une activité anormale de l'entité de service, en vérifiant que ces valeurs récentes sont conformes aux modèles anciens existants, c'est-à-dire qu'elles ne déclenchent pas d'alerte en leur appliquant une comparaison relative à la détection détaillée plus loin. Ainsi à l'étape E26, un coefficient de déviation n'est actualisé que si la composante volumique évaluée correspondante n'a pas été épurée et donc n'a conduit à aucun signalement d'une activité anormale dans le trafic de l'entité de service SE.
L'épuration peut cependant être sautée par décision de l'opérateur ou conformément à la définition de différents modes d'actualisation : par exemple un mode "obsolète" pour lequel l'épuration est sautée, et un mode "normal" pour lequel l'épuration est exécutée. Ensuite, pour chaque composante volumique surveillée x relative à l'entité de service donnée et pour chaque coefficient de moyenne c, le sous-module MAM actualise le modèle correspondant en déterminant à nouveau les variables précitées en fonction de leurs valeurs courantes anciennes et de la valeur récemment évaluée de la composante volumique. Le module MOD détermine les valeurs des coefficients de déviation CDl, CD2 dans les modèles de manière semblable à la phase d'apprentissage. De préférence le sous-module d'actualisation de modèles MAM actualise les valeurs des coefficients de déviation CDl, CD2 dans chaque modèle en appliquant une pondération aux valeurs des coefficients de déviation du modèle ancien courant. La pondération peut dépendre de la durée et de la date de création du modèle ancien courant pour conférer moins de poids au modèle ancien courant ou créé très rapidement. Par exemple, les valeurs des coefficients de déviation du modèle ancien sont pondérées par la durée de la modélisation et l'inverse de l'âge du modèle ancien courant .
En conséquence le module MOD établit un âge de chaque modèle enregistré exprimé en nombre de jours, en association à l'identificateur de l'entité de service, la date de création du modèle et un nombre entier prédéterminé, servant de code de phase, indiquant si le modèle est en cours de construction pendant la phase apprentissage, en cours d'utilisation pour la détection, ou invalide temporairement, ou encore a généré une alerte récente .
Après l'actualisation, les modèles actualisés sont transférés à la base DB qui les enregistre comme à la sous-étape E25 pour remplacer et supprimer les modèles anciens courants .
L'étape de détection d'activité anormale E3 comprend des sous-étapes d'initialisation E30 à E32 et des sous-étapes de comparaison aux modèles E33 à E35.
Le module de détection d'anomalies DET est activé soit automatiquement après la sous-étape E25 de la phase d'apprentissage, c'est-à-dire après la première modélisation, soit par l'opérateur via l'interface homme - machine IHM. A la sous-étape E30, le module DET reçoit du module de déclaration DEC et/ou de l'opérateur via l'interface IHM la liste des identificateurs et caractéristiques des entités de service à protéger, et éventuellement la liste des paramètres d'évaluation, notamment la granularité des évaluations, pour chaque entité de service. Le module DET lit dans la base de données DB tous les modèles courants correspondant aux paramètres, et si pour une entité de service aucune granularité n'est mentionnée, le module DET appelle dans la base DB les modèles courants et donc les plus récents pour cette entité de service et lit leurs granularités . Ainsi, le module DET dispose de la liste des entités de service à protéger et des modèles courants pertinents pour la détection. Le module DET charge et conserve en mémoire vive tous ces modèles courants .
Pour chaque entité de service SE que le dispositif DD doit protéger, l'identificateur et les caractéristiques de l'entité de service et les paramètres d'évaluation de trafic de cette entité nécessaires à la détection et contenus dans les modèles sont, après modification et validation éventuelles par l'opérateur, appliqués ensuite par le module DET au module de médiation MED, à la sous- étape E31.
En réponse aux caractéristiques et paramètres de l'entité de service, le module de médiation MED délivre périodiquement au module de détection DET une évaluation du trafic destiné à l'entité de service, à la sous-étape E32. Cette évaluation comprend les comptes des compteurs COM qui sont assignés à l'évaluation des composantes volumiques de l'entité de service et qui sont réinitialisés régulièrement à la période d'évaluation selon la granularité demandée pour l'entité de service.
Les composantes volumiques évaluées de l'entité de service ont des valeurs "instantanées" exprimées par les comptes des compteurs respectifs COM qui sont délivrés par le module MED pour être traités par le module de détection DET. Suite à l'évaluation, le module DET appelle les modèles courants relatifs aux composantes volumiques . Chaque composante volumique pour l'entité de service donnée est associée à au moins un modèle courant d'activité normale transféré de la base BD dans la mémoire vive.
A la sous-étape E33, à chaque évaluation de chaque composante volumique x, le module de détection DET évalue les mêmes variables dont les moyennes, les dérivées et la déviation, et les mêmes coefficients de déviation CDl, CD2 que ceux évalués par le module de modélisation MOD, selon les paramètres contenus dans le modèle de la composante volumique, comme le coefficient de moyenne c et l'éventuel coefficient temporel et. De la même manière que le module MOD ne modélise qu'après une période d'amortissement et pour des évaluations supérieures au plancher Px, le module DET n'effectue pas de détection par utilisation des coefficients de déviation, lors desdites premières évaluations ou lorsque la valeur de la composante volumique évaluée x est inférieure au plancher Px. Pour les coefficients de déviation CDl du premier type dans un modèle, le module DET compare la valeur respective du coefficient de déviation incluse dans le modèle à la nouvelle valeur du coefficient de déviation venant d'être évaluée et incrémente une valeur d'alerte respective Alx si la nouvelle valeur du coefficient de déviation est supérieure à la valeur du coefficient de déviation incluse dans le modèle. Pour les coefficients de déviation CD2 du deuxième type dans un modèle, représentatifs de prédictions de durée nécessaire à un dépassement de seuil, le module DET combine la valeur du coefficient de déviation CD2 incluse dans le modèle à des variables venant d'être évaluées pour déterminer une valeur de prédiction. Le module DET compare la valeur de prédiction au seuil Sx de la composante volumique x incluse dans le modèle et incrémente une valeur d'alerte respective A2X si la valeur de prédiction est supérieure au seuil Sx.
Puis à la sous-étape E34, pour chaque composante volumique x et pour chaque modèle et donc pour chaque coefficient de moyenne et, optionnellement, chaque coefficient temporel (c, et) , le module DET regroupe les valeurs d'alerte Alx, A2X relatives respectivement aux coefficients de déviation dans un vecteur d'alerte. Le module DET détermine aussi une déviation globale DG en fonction des valeurs d'alerte Alx, A2X pour les composantes volumiques évaluées, par exemple égale à la moyenne quadratique des valeurs d'alerte. Le vecteur d'alerte représente ainsi la similarité plus ou moins prononcée de l'évaluation aux modèles courants pertinents pour cette évaluation. Le vecteur d'alerte est délivré au module d'alerte ALE chargé de la sortie des alertes.
Finalement à la sous-étape E35, le module d'alerte ALE décide si le vecteur d'alerte doit engendrer une alerte ou non. Pour cela, le module ALE examine ledit vecteur d'alerte, et détermine en fonction de ce vecteur d'alerte une valeur d'alerte globale. Si la valeur d'alerte globale excède un niveau d'alerte prédéterminé, le module ALE signale une activité anormale dans le trafic de l'entité de service SE en transmettant une alerte pour l'opérateur via l'interface IHM, et/ou vers un dispositif externe. L'alerte transmise est accompagnée des valeurs des composantes volumiques de l'évaluation qui a déclenché l'alerte, des seuils de coefficient de déviation pertinents au moment de l'évaluation, et d'un type d'alerte dépendant des valeurs des déviations des composantes volumiques .
En pratique, le procédé de détection d'anomalies selon l'invention est prévu pour pouvoir détecter des anomalies relatives au trafic de plusieurs entités de service supporté par la liaison de transmission.
Préalablement, chaque entité de service est déclarée par une adresse de destination, au moins un protocole de transport et au moins un port et une liste de composantes volumiques à évaluer pendant la durée prédéterminée .
L'invention décrite ici concerne un procédé et un dispositif informatique DD pour détecter des anomalies dans le trafic supporté par la liaison de transmission LT et relatif à une ou plusieurs entités de service SE. Selon une implémentation préférée, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans le dispositif informatique. Le programme comporte des instructions de programme qui, lorsque ledit programme est chargé et exécuté dans le dispositif, dont le fonctionnement est alors commandé par l'exécution du programme, réalisent les étapes du procédé selon l'invention.
En conséquence, l'invention s'applique également à un programme d'ordinateur, notamment un programme d'ordinateur sur ou dans un support d'informations, adapté à mettre en œuvre l'invention. Ce programme peut utiliser n'importe quel langage de programmation, et être sous la forme de code source, code objet, ou de code intermédiaire entre code source et code objet tel que dans une forme partiellement compilée, ou dans n'importe quelle autre forme souhaitable pour implémenter le procédé selon l'invention.
Le support d'informations peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage ou support d'enregistrement, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou encore un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'informations peut être un support transmissible tel qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou optique, par radio ou par d'autres moyens. Le programme selon l'invention peut être en particulier téléchargé sur un réseau de type internet .
Alternativement, le support d'informations peut être un circuit intégré dans lequel le programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé selon 1 ' invention .

Claims

REVENDICATIONS
1 - Procédé pour détecter des anomalies dans le trafic supporté par une liaison de transmission (LT) et relatif à une entité de service (SE) , incluant préalablement une modélisation de l'activité normale de l'entité de service, caractérisé en ce que la modélisation (E2) fournit des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, ledit procédé comprenant pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques, une incrémentation (E31 - E33) d'une valeur d'alerte respective pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle.
2 - Procédé conforme à la revendication 1, selon lequel ladite moyenne mobile est une moyenne mobile à pondération exponentielle.
3 - Procédé conforme à la revendication 2, selon lequel des coefficients de déviation d'un premier type
' relatifs à une composante volumique dépendent, outre de la composante volumique et de la moyenne mobile à pondération exponentielle, d'une moyenne à pondération exponentielle de la moyenne mobile, et d'une moyenne à pondération exponentielle des carrés de valeurs de la composante volumique, et les valeurs de seuil pour les coefficients de déviation de premier type sont des coefficients de déviation évalués lors de la modélisation.
4 - Procédé conforme à la revendication 3, comprenant à chaque évaluation, une actualisation (E22) d'une valeur courante d'un coefficient de déviation du premier type si une nouvelle valeur du coefficient de déviation est supérieure à la valeur courante du coefficient de déviation, en remplaçant ladite valeur courante par la moyenne de celle-ci et de ladite nouvelle valeur.
5 - Procédé conforme à la revendication 3 ou 4, selon lequel les moyennes à pondération exponentielle pour les coefficients de déviation du premier type relatifs à une composante volumique et un modèle dépendent d'un coefficient de moyenne choisi préalablement pour le modèle.
6 - Procédé conforme à l'une quelconque des revendications 1 à 5, selon lequel des coefficients de déviation d'un deuxième type relatifs à une composante volumique dépendent, outre de la composante volumique et de la moyenne mobile à pondération exponentielle, d'une moyenne à pondération exponentielle de valeurs de la moyenne mobile, d'une dérivée première discrète de composante volumique proportionnelle à la différence de la composante volumique évaluée et de la moyenne mobile, d'une dérivée seconde discrète de composante volumique égale à la différence d'une nouvelle valeur et d'une valeur courante de la dérivée première, et d'un seuil commun, et les valeurs de seuil pour les coefficients de déviation de deuxième type sont égales au seuil commun relatif à la composante volumique.
7 - Procédé conforme à la revendication 6, comprenant à chaque évaluation, une actualisation (E23) d'une valeur courante d'un coefficient de déviation d'un deuxième type si une nouvelle valeur du coefficient de déviation est inférieure à la valeur courante du coefficient de déviation, en remplaçant ladite valeur courante par la moyenne de celle-ci et ladite nouvelle valeur.
8 - Procédé conforme à la revendication 4 ou 7, selon lequel un coefficient de déviation n'est actualisé que si la composante volumique évaluée correspondante n'a conduit à aucun signalement d'une activité anormale dans le trafic de l'entité de service (SE) .
9 - Procédé conforme à la revendication 4 ou 7 ou 8, selon lequel les coefficients de déviation dans un modèle sont actualisés en appliquant une pondération dépendant d'une date de création du modèle aux valeurs des coefficients de déviation du modèle.
10 - Procédé conforme à l'une quelconque des revendications 1 à 9, détectant des anomalies relatives au trafic de plusieurs entités de service (SE) supporté par la liaison de transmission (LT) , et comprenant préalablement une déclaration de chaque entité de service par une adresse de destination, au moins un protocole de transport et au moins un port et une liste de composantes volumiques à évaluer pendant la durée prédéterminée .
11 - Dispositif (DD) pour détecter des anomalies dans le trafic supporté par une liaison de transmission (LT) et relatif à une entité de service
(SE), l'activité normale de l'entité de service étant préalablement modélisée, caractérisé en ce qu'il comprend un moyen (MOD) pour modéliser l'activité normale de l'entité de service par des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, un moyen (DET) pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques pour incrémenter une valeur d'alerte respective pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle.
12 - Dispositif conforme à la revendication 11, dans lequel ladite moyenne mobile est une moyenne mobile à pondération exponentielle.
13 - Sonde de trafic incluant un dispositif (DD) conforme à la revendication 11 ou 12 pour détecter des anomalies . 14 - Programme d'ordinateur apte à être mis en œuvre dans un dispositif (DD) pour détecter des anomalies dans le trafic supporté par une liaison de transmission (LT) et relatif à une entité de service (SE), l'activité normale de l'entité de service étant préalablement modélisée, ledit programme comprenant des instructions qui, lorsque le programme est chargé et exécuté dans ledit dispositif, réalisent les étapes consistant à : modéliser (E2) l'activité normale de l'entité de service par des modèles pour des composantes volumiques du trafic évaluées périodiquement pendant une durée prédéterminée, un modèle relatif à une composante volumique comprenant des coefficients de déviation évalués en fonction d'une moyenne mobile de la composante volumique évaluée pendant la durée prédéterminée, pour au moins une évaluation ultérieure de coefficients de déviation relatifs aux composantes volumiques, incrémenter (E31 - E33) une valeur d'alerte respective pour au moins un coefficient de déviation si une nouvelle valeur du coefficient de déviation est supérieure à une valeur de seuil respective incluse dans le modèle.
15 - Programme d'ordinateur conforme à la revendication 14, dans lequel ladite moyenne mobile est une moyenne mobile à pondération exponentielle.
PCT/FR2006/050670 2005-07-07 2006-07-04 Detection dynamique d'anomalies dans le trafic relatif a une entite de service WO2007006995A2 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0552099A FR2888439A1 (fr) 2005-07-07 2005-07-07 Detection dynamique d'anomalies dans le trafic relatif a une entite de service
FR0552099 2005-07-07

Publications (2)

Publication Number Publication Date
WO2007006995A2 true WO2007006995A2 (fr) 2007-01-18
WO2007006995A3 WO2007006995A3 (fr) 2007-04-12

Family

ID=36124039

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2006/050670 WO2007006995A2 (fr) 2005-07-07 2006-07-04 Detection dynamique d'anomalies dans le trafic relatif a une entite de service

Country Status (2)

Country Link
FR (1) FR2888439A1 (fr)
WO (1) WO2007006995A2 (fr)

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101841435B (zh) * 2010-01-18 2012-08-29 中国科学院计算机网络信息中心 Dns查询流量异常的检测方法、装置和系统
CN107493272A (zh) * 2017-08-01 2017-12-19 杭州迪普科技股份有限公司 一种流量清洗方法、装置和系统

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN115452936B (zh) * 2022-07-11 2023-04-07 合肥贵专电磁科技有限公司 一种基于无线传输的钢丝绳探测结果评估系统

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
SIRIS V A ET AL: "Application of anomaly detection algorithms for detecting SYN flooding attacks" GLOBAL TELECOMMUNICATIONS CONFERENCE, 2004. GLOBECOM '04. IEEE DALLAS, TX, USA 29 NOV.-3 DEC., 2004, PISCATAWAY, NJ, USA,IEEE, vol. 4, 29 novembre 2004 (2004-11-29), pages 2050-2054, XP010757893 ISBN: 0-7803-8794-5 *
YE N, BORROR C, ZHANG Y: "EWMA TECHNIQUES FOR COMPUTER INTRUSION DETECTION THROUGH ANOMALOUS CHANGES IN EVENT INTENSITY" QUALITY AND RELIABILITY ENGINEERING INTERNATIONAL, [Online] 13 août 2002 (2002-08-13), XP002376922 Extrait de l'Internet: URL:http://ceaspub.eas.asu.edu/ye/publicat ions/v2/Ye_32.pdf> [extrait le 2006-04-12] *

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN101841435B (zh) * 2010-01-18 2012-08-29 中国科学院计算机网络信息中心 Dns查询流量异常的检测方法、装置和系统
CN107493272A (zh) * 2017-08-01 2017-12-19 杭州迪普科技股份有限公司 一种流量清洗方法、装置和系统

Also Published As

Publication number Publication date
FR2888439A1 (fr) 2007-01-12
WO2007006995A3 (fr) 2007-04-12

Similar Documents

Publication Publication Date Title
EP1463238B1 (fr) Dispositif de gestion locale de procédés d'assurance pour un équipement de réseau de communications
EP1367769A1 (fr) Dispositif et procédé de classification de messages d'alarme résultant d'une violation d'accord de niveau de service dans un réseau de communications
EP3957045A1 (fr) Procede et dispositif de traitement d'un message d'alerte notifiant une anomalie detectee dans un trafic emis via un reseau
Aiello et al. Profiling DNS tunneling attacks with PCA and mutual information
EP2053783A1 (fr) Procédé et système pour l'identification de trafic VoIP dans des réseaux
WO2007006994A2 (fr) Detection statique d'anomalies dans le trafic relatif a une entite de service
WO2007006995A2 (fr) Detection dynamique d'anomalies dans le trafic relatif a une entite de service
WO2008050059A2 (fr) Procede de supervision d'une pluralite d'equipements dans un reseau de communication
EP2353272B1 (fr) Procede de caracterisation d'entites a l'origine de variations dans un trafic reseau
WO2016071607A1 (fr) Délégation d'intermédiation sur un échange de données chiffrées
WO2007020361A2 (fr) Etablissement d'alertes par detection d'anomalies statique et dynamique dans le trafic d'une entite de service
Yoon et al. Header signature maintenance for Internet traffic identification
EP3539259B1 (fr) Procédé et dispositif d'actualisation d'un modèle prédictif d'une variable relative à un terminal mobile
EP2838241B1 (fr) Procédé de détection d'évènements suspects dans un fichier de collecte d'informations relatives à un flux de données ; support d'enregistrement et système associés.
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
EP3963842A1 (fr) Procedes et dispositifs de mesure de reputation dans un reseau de communication
EP3869368A1 (fr) Procede et dispositif de detection d'anomalie
CN116800588B (zh) 网通产品网络优化方法和装置
FR2917556A1 (fr) Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets
FR3044195A1 (fr) Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip
EP1372295A1 (fr) Dispositif et procédé de contrôle de profils, notamment de flux de données, dans un réseau de communications
EP3835985A1 (fr) Procédé de surveillance de données transitant par un équipement utilisateur
WO2006123036A1 (fr) Procede de representation en structure arborescente d'un groupe de flots de donnees numeriques. structure arborescente, procede et systeme de detection d'une attaque par inondation
FR3127663A1 (fr) Procédé de contrôle d’un accès à un service applicatif, procédé de traitement d’un message de contrôle d’un accès audit service, dispositifs, système et programmes d’ordinateur correspondants.
WO2023036847A1 (fr) Procede et système de surveillance et gestion du trafic de données

Legal Events

Date Code Title Description
NENP Non-entry into the national phase

Ref country code: DE

WWW Wipo information: withdrawn in national office

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 06779011

Country of ref document: EP

Kind code of ref document: A2