WO2009004234A1 - Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets - Google Patents

Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets Download PDF

Info

Publication number
WO2009004234A1
WO2009004234A1 PCT/FR2008/051067 FR2008051067W WO2009004234A1 WO 2009004234 A1 WO2009004234 A1 WO 2009004234A1 FR 2008051067 W FR2008051067 W FR 2008051067W WO 2009004234 A1 WO2009004234 A1 WO 2009004234A1
Authority
WO
WIPO (PCT)
Prior art keywords
entity
packet
type
rule
intercepted
Prior art date
Application number
PCT/FR2008/051067
Other languages
English (en)
Inventor
Patrick Battistello
Stéphane TUFFIN
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 WO2009004234A1 publication Critical patent/WO2009004234A1/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/1408—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic by monitoring network traffic
    • H04L63/1416—Event detection, e.g. attack signature detection

Definitions

  • the present invention relates to security in a packet network based on packet analyzes transmitted in the network. More particularly, it relates to detection of anomalies or security incidents in the traffic supported by a transmission link and relating to at least one service entity in the packet network.
  • a packet network such as the Internet, transmits packets between different service entities, via a common infrastructure.
  • a service entity connected to such a network responds to requests from client entities, such as client terminals, 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 server offering a download of multimedia files, an e-mail server, or a VoIP ("Voice Over IP") VoIP application server.
  • Service entities may be faced with various types of packet traffic problems, such as attacks or anomalies that degrade the quality of service provided by service entities. An anomaly may be considered as a non-conforming traffic assessment to a set of allowable normal traffic evaluations. All eligible evaluations are determined a priori with the help of expert knowledge and rules, defining, for example, characteristics that normal traffic must satisfy.
  • VoIP networks offering VoIP voice over IP service are expanding rapidly. Such networks are eventually replacing traditional telephony networks and supporting new multimedia applications such as videoconferencing, while limited efforts are made for the security of these applications.
  • VoIP networks will be subject in the near future to malicious acts such as identity theft, sending polluting messages, or attempts to decommission service entities, for example in order to degrade the brand image.
  • network protection equipment such as firewalls or voice over IP devices, that block or reject abnormal traffic. These devices do not map the entities generating abnormal traffic, to prevent possible network attacks from such entities. It is therefore difficult to detect abnormal traffic patterns before they are dangerous to the network, and packets are blocked. Current equipment is more focused on blocking non-compliant or hostile packets than on upstream detection of abnormal behavior.
  • the fineness and complexity of the analyzes performed by such equipment are limited to the analysis of current traffic packets processing and possibly on the application context associated with the traffic.
  • IDS Intrusion Detection System
  • honeypots Other network protection equipment, such as Intrusion Detection System (IDS) probes or honeypots, do not distinguish between treatments performed according to the type of entity being used. origin of the traffic. For example, "jars of honey” perform processing only on the traffic they attract and do not analyze traffic destined for service entities.
  • IDS Intrusion Detection System
  • protection equipment dealing with large volumes of traffic has a limited level of analysis that does not allow to take into account the specificities of the voice over IP service.
  • Such equipment offering a level of in-depth analysis is limited by processing capacity and supported throughput.
  • a method for detecting an anomaly in the traffic transmitted by an entity comprising a recovery of a context of the entity as a function of a packet intercepted in the traffic, characterized in that, said retrieved context comprising at least one type and level of conformity of the entity, it comprises: a selection of at least one of the first predetermined rules according to the type and level of conformity of the entity; recovered entity and available resources of a device having intercepted said packet, a decision on the compliance of the intercepted packet with said at least one selected first rule, the conformity of the intercepted packet being indeterminate if said at least one selected first rule is inapplicable to the intercepted packet, and updating the context of the entity according to the decision made on the compliance of the intercepted packet.
  • An anomaly can then be detected if the intercepted packet does not conform to said at least one selected first rule.
  • the invention advantageously detects behavioral abnormalities both in the traffic directed towards this entity and in the traffic that comes from it, in order to signal very quickly and accurately a device to be protected, such as a service entity. attack or anomaly in the analyzed traffic.
  • the invention further detects malicious behavior before a possible attack occurs. Indeed, any attack against a service entity is usually preceded by an investigation phase during which the attacker searches for the security limits of the service entity.
  • the method according to the invention thus detects intentional malicious behaviors, resulting for example directly from the action of an attacker outside the network to which the service entity is attached, as well as unintentional malicious behaviors, resulting by example of the action of a client terminal infected by a worm that emits packets in large quantities.
  • unintentionally configured client terminal can be detected, ideally before the customer calls a technical support center.
  • the method according to the invention distinguishes unreliable entities, such as client entities, reliable entities, such as service entities, by selecting rules based on the context of the entity, including for example a type or subtype of the entity, and available resources of the device so as not to expose the latter to attacks by resource saturation. This distinction makes it possible to analyze more precisely packets sent by entities considered unreliable.
  • the method according to the invention allows an abnormality detection device to react to the detected anomaly, for example by memorizing the anomalies, by raising an alarm or by blocking the traffic presenting. an abnormality.
  • the invention adapts the analysis carried out on the intercepted packet according to the resources of the device, for example as a function of a compromise between an execution time necessary for the application of a selected rule to the intercepted packet, a received packet risk depending on anomalies already detected for the entity and available resources of the anomaly detection device.
  • the update of the context of the entity is done according to the intercepted packet and at least one other intercepted packet in the traffic issued by the entity.
  • the analysis depth is thus adapted to the type of the entity and possibly to a history of analysis of the packets sent by the entity.
  • the selection of said at least one first rule may depend on a level of conformity of the entity contained in the entity. context of the entity, said compliance level depending on the compliance of at least one other packet of the entity intercepted prior to said intercepted packet with at least one other first rule.
  • the first rules are thus selected according to the type of entity and the level of compliance of the latter, in order to analyze more precisely entities that are considered non-compliant and unreliable.
  • the context of the entity can be updated according to the conformity of the intercepted packet to said at least one selected first rule.
  • the compliance level of the entity is updated after the analysis of each intercepted packet. Therefore, the context of the entity is also updated, and the first rules selected according to the context of the entity may be different for each intercepted packet.
  • the method may furthermore comprise, if the type of the entity is defined and if the intercepted packet does not conform to the said at least one selected rule, a selection of at least a second rule depending on the context of the entity and said at least one first rule which is not not conforming to the intercepted packet and detecting an abnormality based on a compliance of the intercepted packet and at least one other intercepted packet in the traffic sent by the entity to said at least one selected second rule.
  • anomalies such as time-based attacks
  • other anomalies are detected later on the analysis of the received packet, considering a set of packets that are not compliant with the selected rules and issued by the same entity.
  • the method may further comprise, if the type of the entity is defined and if the intercepted packet conforms to said at least one selected first rule, an extraction of attributes of the intercepted packet and a memorization of the extracted attributes in the context of the entity.
  • the method may further include updating entity type attributes based on the stored extracted attributes and other extracted attributes of intercepted packets issued by other entities of the same type as that of said entity, and anomaly detection if the value of one of the extracted attributes is excluded from a predetermined interval depending on the extracted attributes.
  • the invention retrieves information about the packet that is issued by a trusted entity to enrich a database that includes entity-type attributes so that other undefined entities can be determined later.
  • the anomaly detection device thus learns characteristics common and useful for detecting entities of the same type.
  • the first rules selected may comprise critical rules and non-critical rules, the critical rules being applied to the intercepted packet in priority over the non-critical rules, and the conformity of the packet. intercepted may be indeterminate if at least one of the critical rules could not be applied to the intercepted packet for a predetermined processing time.
  • Critical rules aim at detecting anomalies or attacks having a critical and immediate impact on the controlled service, and are applied in priority to the intercepted packet.
  • the non-critical rules have a less or less immediate impact and are for example applied to the intercepted packet depending on the available resources of the device. For example, the dichotomy between critical and non-critical rules is done by the domain expert.
  • the number of rules selected may depend on the level of compliance of the entity.
  • the invention analyzes the intercepted packets of an entity all the more precisely since the entity is considered as non-compliant. For example, the number of rules selected is all the higher the lower the level of compliance; that is, the entity is not reliable.
  • the invention also relates to a device for detecting an anomaly in the traffic transmitted by an entity presenting a context recovered in a function of a packet intercepted in the traffic, characterized in that, said retrieved context comprising at least one type and a level of conformity of the entity, it comprises: a means for selecting at least one of the first predetermined rules depending on the type and level of compliance of the recovered entity and available resources of the device,
  • the device may comprise:
  • the device may be linked to a database comprising the context of the entity and the attributes extracted from the intercepted packets, and further linked to another database comprising attributes of type d entity that are updated based on the attributes extracted from intercepted packets and used to determine the type of the entity.
  • the invention relates to a computer program adapted to be implemented in a processor, such as that in a device for detecting anomalies in the traffic transmitted by an entity to another entity, said program comprising instructions that when the program is executed in the processor, perform the steps according to the method of the invention.
  • FIGS. 1A and 1B are schematic block diagrams of a system respectively according to first and second embodiments of the invention.
  • FIG. 2 is a schematic block diagram of an abnormality detection device according to the invention
  • FIG. 3 is a schematic block diagram of databases relating to the anomaly detection device according to the invention.
  • FIGS. 4 and 5 are an algorithm of an anomaly detection method according to the invention.
  • an anomaly detecting device DD is for example included in a probe and serves as a substantially software agent for protecting ES service entities interconnected via a packet network.
  • Internal RI to a more global packet transmission network like the internet.
  • service entities are web servers interconnected through one or more routers.
  • the internal network RI network is for example a computer network, such as an intranet of a company or part of the Internet, managed by an operator according to the protocol IP ("Internet Protocol" in English).
  • IP Internet Protocol
  • the internal packet network RI offers one or more services, such as voice over IP, each supporting one or more protocols, such as the Session Initiation Protocol (SIP) for voice service. on IP, or private protocols such as the IPX protocol ("Inter-network Packet eXchanqe" in English).
  • Packets are transmitted to the ES service entities over a transmission link LT from EC client entities connected to each other via a packet network RE external to the internal packet network RI grouping the service entities in the Internet.
  • the client entities are, for example, user terminals or servers.
  • the transmission link LT is located near the ES service entities whose traffic is to be monitored by the detection device DD so that the latter detects anomalies in the traffic which characterize, for example, abnormal or malicious behaviors of the client entities, such as attacks by flood of service entities.
  • the transmission link LT to which the detection device DD is connected in listening according to FIG. 1A or cut-off according to FIG. 1B, is located at the entry point of one or more service entities ES, between the external network RE and the internal network RI, for example between an external network edge router RE and a router of the internal network RI connected to one or more service entities ES.
  • the detection device DD is placed in listening or shunting and its main function is to detect suspicious traffic.
  • the DD device records characteristics of the suspicious traffic, triggers alarms according to characteristics of the suspicious traffic and optionally controls the protection equipment able to block suspicious traffic, such as a firewall connected at the edge of the packet network internal RI.
  • the DD device reports an alert based on the observation of the service entity traffic in the LT link so that the operator takes appropriate action to counter a possible service entity-directed attack.
  • the detection device DD is placed in a break and its main function is to detect and block suspicious traffic.
  • the disconnected DD device has, in addition to the same functionality as the device DD placed in listening, the functionality to directly block the suspicious traffic.
  • the detection device DD analyzes the compliance of the traffic bidirectionally, that is to say both the traffic sent by the potentially malicious EC client entities to the ES service entities to be protected and the traffic issued by the ES service entities to be protected to potentially malicious EC client entities.
  • the detection device DD only analyzes the compliance of the traffic sent by the client entities EC to the service entities ES, the traffic transmitted by the service entities ES being considered as non-malicious.
  • the detection device DD may be in the form of a computer or a workstation, or a local or distributed computer system.
  • the DD device receives PAQ packets transmitted via the transmission line LT.
  • the received packets are previously filtered by an upstream entity, independent of the method, for example a firewall type entity.
  • This upstream filtering relates for example to IP addresses and transmission protocols, so as not to overload the device DD.
  • the detection device DD comprises a low-level processing system TBN, operating ideally at the speed of the transmission link LT, including a DEC decoding module, a FIL filtering module and a REC entity type retrieval module.
  • the decoding module DEC extracts from each received packet PAQ certain pieces of information useful for the method. These elements are predetermined according to the supervised protocols and optionally, for a given protocol, the type of packet received.
  • the FIL filtering module filters PAQ packets, according to filtering rules applicable to the information elements extracted by the DEC decoding module.
  • the REC entity type retrieval module retrieves, based on the information elements extracted from each packet received by the DEC decoding module, the types of the sending and receiving entities of the received packet by means of a type-recovery function.
  • fREC entity • The REC module retrieves, where appropriate, contexts associated with the determined entities, in particular information on the type of entity, this type information being structured hierarchically into one or more sub-types.
  • the information elements extracted by the DEC decoding module, the information elements retrieved by the REC module, and the received packet are supplied to a TEM timing module. which places these items in a queue before they are processed by a high level processing system THN of the detection device DD.
  • the high-level THN processing system includes an AC compliance analysis module, a CTE entity type characterization module, a COL entity type characterization information collection module and ANC non-conformance analysis module.
  • the AC compliance analysis module detects abnormal or malicious traffic behavior on a short-term time scale, by analyzing each received PAQ packet using a compliance analysis function f AC •
  • the module AC performs compliance analysis only on packets sent from the external network RE to the internal network RI, the packets received from the internal network RI being assumed to be non-malicious.
  • the conformity analysis can be performed also on the packets sent from the internal network RI to the external network RE. Treatments relating to the conformity analysis are based in particular on the type of entities that are the source or the destination of the received packet PAQ.
  • the characterization module of the CTE entity type determines, on a medium-term time scale, the type and / or subtypes of an entity from which a set of PAQ packets has been received by means of a fCTE characterization function •
  • the CTE module carries out an entity characterization that applies to the entities of the internal network RI as well as those of the external network RE.
  • the module CTE determines the type of this new entity or reports an anomaly in case the determination fails.
  • the COL entity type characterization information collection module collects ATT type of entity attributes based on the information contained in the received PAQ packets at the same time. Using a fCOL Collection Function • The COL module performs a first level of learning about the attributes collected for each type of entity. This learning applies to both the entities of the internal network RI and those of the external network RE. The training is performed on so-called compliant packets for which the compliance analysis has given a positive result.
  • the ANC non-compliance analysis module analyzes so-called non-compliant packets for which the compliance analysis has given a negative result, by means of a non-conformity analysis function ANC •
  • the ANC module performs a non-compliance analysis that correlates a set of non-compliant packets issued by a given entity to infer a type of non-compliant or malicious behavior.
  • the compliance analysis which provides a result for each received packet, the non-conformance analysis processes a set of non-compliant packets for a longer period.
  • the device DD further comprises one or more processing units UT which are each defined as a set of hardware resources of the device DD, such as a processor, a memory and a communication bus, which are dedicated to the processing of the received packets.
  • the processing units are assumed to be independent of one another, that is, the processing of a packet by a processing unit UT has no influence on the resources available to the other processing units.
  • a processing unit is dedicated to performing the function fAC •
  • the number of processing units depends on the implementation of the DD device and several criteria such as the hardware architecture of the device comprising one or more processors, the maximum rate of the packets to be processed, the service in question and a number of rules to be applied by different processing functions.
  • the modules of the THN system cooperate with a secondary processing system TS of the detection device DD including a processing management module GES, a correlation module COR and a characterization information learning module of the type of entity APP.
  • the GES treatment management module regulates processing times relating to each of the modules of the detection device DD in particular according to the resources of the latter.
  • the COR correlation module establishes a correlation between first packets sent from the external network RE to the internal network RI, or vice versa, and second packets sent from the internal network RI to the external network RE, or vice versa, in response to the first packets, by means of a correlation function fc OR -
  • This correlation is applied only to packets for which a response from an entity of the internal or external network is required for processing of the device DD.
  • the COR correlation module is solicited indifferently and independently by the AC compliance analysis module, the CTE entity type characterization module, and the ANC nonconformity analysis module.
  • the correlation function fc OR is executed asynchronously with respect to the other processing functions of the modules of the device DD.
  • the characterization information learning module of the entity type APP cooperates with the collection module COL.
  • the APP module aggregates attributes ATT of type and subtype of entity collected by the module COL by means of a learning function f APP r when a sufficient number of attributes is collected for a sufficient number entities.
  • the APP module provides characterization attributes for different types and subtypes of features that are used by the characterization module of the CTE entity type.
  • the modules of the detection device DD have time outs of execution and delivery of results, which can be short-term, medium-term or long-term.
  • the AC compliance analysis module and the COR correlation module have short-term response times, since the AC module provides a result after the analysis of each received packet, and the COR module establishes a link between queries and answers that are usually close in time.
  • the characterization module of the CTE entity type and the ANC nonconformity analysis module have medium-term response times since they require a set of packets before providing a result.
  • the collection module COL and the learning module APP have long-term response times because they require a large number of packets relating to a representative set of entities before they can consolidate characterization attributes.
  • the modules of the high-level processing system THN and the secondary processing system TS execute so-called high-level processing.
  • these processes generate delays in transferring received and processed packets.
  • the DD device dynamically adapts these high-level processing operations to the context of said service, in particular as a function of the origin of the packet, the type of the entity, the nature of the service. a level of compliance of the entity and DD device resources.
  • the compliance analysis invokes a set of rules that depends on the type of entity considered for each packet processed.
  • processes are executed according to a level of analysis of the received packet and the associated entity which is not constant.
  • an entity compliance level is used to tailor the processing performed by the compliance analysis function f AC .
  • the lower the resources of the DD device the more it reduces the amount of processing performed per entity or packet received.
  • This dynamic adaptation of the resources of the DD device is made according to the entity, ensuring that so-called critical control rules are applied for each processed packet regardless of the level of compliance of the entity.
  • a resource limitation based on the entity avoids, for example, a situation where an abusive malicious behavior of an entity prevents the application of control rules for other entities.
  • This dynamic adaptation of the DD device avoids a systematic verification of the same rules for all the entities and for all the received packets, which is very resource consuming and which limits the degree of analysis of the packets.
  • an entity whose behavior checks a predefined template will undergo a minimum of controls, while an entity whose behavior is removed from the predefined template will be subject to more and more checks as the level of compliance of the entity decreases.
  • This dynamic adaptation ensures that the DD device performs sufficiently fine checks on entities with suspicious or abnormal features, while saving processing resources through critical controls based on a minimum number of rules enforced on entities conforming to the template.
  • critical controls are always prioritized for internal network security, and other finer controls are conditional on system resources, entity type, and level of compliance of the latter.
  • the information manipulated by the detection device DD is organized and stored in a set of different databases comprising a characterization basis of the BCTE entity type, a BIE entity identification base, an ECB entity context base and a BR rule base.
  • This organization is logical in nature and not limited to a particular implementation.
  • the databases BCTE, BIE, BCE and BR are related to the detection device DD, that is to say they are either integrated in the detection device DD, or incorporated into one or more database management servers. and connected to detection device by a local or remote link.
  • the BCTE, BIE and BCE databases are read and write, while the BR base is read only, for example for high-level processing processing functions.
  • the BCTE entity type characterization database contains ATT attributes that are descriptive information about different types and subtypes of RI and RE network entities defined in the DD and that allow the CTE characterization module to determine the type and possibly one or more sub-types of an entity based on packets received from the entity.
  • An entity is defined by a type, and possibly by one or more subtypes in a hierarchical manner. By default, an entity subtype recursively inherits attributes from the upper subtype to the root entity type. On the other hand, an attribute of the entity type can be redefined in any of the entity subtypes.
  • the attributes stored in the BCTE database are read by the feature type characterization function fc TE - These attributes can be written dynamically by the f APP learning function, or by an administrator of the DD device at the management plan, especially when initializing the DD device during which certain attributes are configured by default.
  • the BIE entity identification database contains information or primary keys allowing the REC type entity recovery function of the REC module to retrieve the type of each of the sending and receiving entities according to the analysis of each package received.
  • Information contained in the BIE database are segmented into two parts.
  • a first base portion includes index information ⁇ IDX ⁇ including a primary key or a set of primary keys identifying an entity belonging to the internal network RI or the external network RE.
  • This first information corresponds to a subset of the information decoded by the module DEC.
  • a second base portion includes descriptive information of each entity, i.e., a unique IE entity identifier, a ⁇ TE> entity type, optionally one or more associated entity subtypes. ⁇ STE> and a compliance level of the ⁇ NCE> entity.
  • the entity identifier IE points to the corresponding entity context contained in the BCE database.
  • the characterization function fc ⁇ ⁇ of the module CTE updates the type of entity ⁇ TE> and possibly one or more associated entity sub-types ⁇ STE> since the function fc ⁇ ⁇ has determined the type or the sub-type -type of a previously undefined entity.
  • the entity context base BCE contains, for a given entity identifier IE, stored in the entity identification database BIE, an entity context ⁇ IE ⁇ associated with this identifier.
  • the context of an entity refers to a set of information specific to the entity. Since there is a bijection between the entity identifier IE and the entity context, the notation ⁇ IE ⁇ will subsequently designate the entity context indifferently. the aggregation of the entity identifier and the context of the entity.
  • the BCE database contains, for each entity, compliance, characterization and history information. The compliance information indicates the observed behavior of an entity by the AC and ANC functions of the AC and ANC modules that read, write, or modify this information.
  • the characterization information describes characteristics of the entity, and is initially read and modified by the characterization function fc ⁇ ⁇ of the module CTE, then by the collection function fc OL of the module COL. This characterization information is also read by the APP learning function of the APP module.
  • the history information aggregates in the long term different faults or alarms detected by the functions f A fcTEr fANC or fAPP-
  • the BR rule base statically describes conformance analysis rules, entity type characterization rules, characterization attribute collection rules, nonconformity analysis rules, and rules of characterization. correlation.
  • the BR base contains rule modules each composed of a set of rules called by a particular processing function, such as ⁇ RAC ⁇ compliance analysis rules, ⁇ RCTE ⁇ entity type characterization rules, characterization attribute collection rules ⁇ RCOL ⁇ , non-conformance analysis rules ⁇ RANC ⁇ , and correlation rules ⁇ RCOR ⁇ .
  • Each rule defines an action or check according to input parameters specific to the rule and returns one or more values to the calling processing function, that is to say the module executing this function. appellant.
  • the base BR For each possible combination of selection parameters, specific to each of the functions fAO fcTE / - f ⁇ L and fANO the base BR respectively points to the set ⁇ RAC ⁇ , ⁇ RCTE ⁇ , ⁇ RCOL ⁇ and ⁇ RANC ⁇ of rules to invoke for this combination.
  • the set of possible combinations of the input parameters of these functions is discrete and bounded.
  • the compliance analysis rules are invoked by the AC module and consist in verifying that a packet complies with a certain number of security rules, in particular the rules identified as critical for the application or for supervised protocols. Each rule returns a result of the type "OK” if the packet conforms to the rules invoked, "NOK” if the packet is not in conformity with the invoked rules, or "IND” if the result is undefined, that is to say if the AC module can not decide on the conformity of the packet.
  • These compliance analysis rules are classified into two categories: “critical” rules and “non-critical” rules.
  • Entity type characterization rules are invoked by the CTE module and evaluate a similarity between an indefinite type entity and the different entity types and subtypes defined in the DD. For each packet to which they are applied, these rules compare certain information retrieved from the packet to the ATT attributes defined in the BCTE entity type characterization database and evolve likelihood indicators for the various possible entity types and subtypes. .
  • Characterization attribute collection rules are invoked by the COL module and define parameters to be added or modified, according to the packets received, among the characterization attributes associated with the entity and stored in its context ⁇ IE ⁇ .
  • the nonconformity analysis rules are invoked by the ANC module and are applied to packets detected nonconforming by the fAC function. • These rules aim to more precisely determine a type or logic of attack over an average period of time. -term.
  • the anomaly detection method according to the invention comprises steps E1 to E11 executed in the detection device DD.
  • the IS service entities of the IN network are not malicious and the DD performs a compliance analysis only on the traffic sent by the EC client entities from the RE network to the IS service entities of the IN network.
  • the steps of the method may be similarly executed for an analysis of the traffic transmitted by the ES service entities to the EC client entities.
  • the DD device intercepts and receives PAQ packets transmitted in messages via the transmission line LT between the networks RI and RE.
  • the decoding module DEC extracts a set of information ⁇ IAD ⁇ to be decoded for each received packet PAQ, generally structured as fields in the packet.
  • the received packet contains information fields relating to the protocol supported by the routing, such as the IP protocol, to the protocol supported by the transport, such as the UDP protocol ("User Datagram Protocol" in English), and the protocols supported by the application relating to the service offered by the IN network.
  • the module DEC processes all the packets received, in a manner adapted to the rate supported by the transmission line, so that the number of information to be decoded is relatively small.
  • the information to be decoded may depend on the type of packet received, for example a packet relating to a request or a response. If the DD device has few capabilities, the information to be decoded ⁇ IAD ⁇ has the advantage to be identical regardless of the type of packet received.
  • information extracted by the module DEC is the protocol associated with the received packet, hereinafter called packet protocol ⁇ P> and can designate any protocol application or transport. Since each protocol is generally structured into several types of messages, another piece of information extracted by the module DEC is the type of message, for a given protocol, associated with each received packet, subsequently called type of message received ⁇ TM>.
  • the extracted information set ⁇ IAD ⁇ includes the packet protocol ⁇ P> and the received message type ⁇ TM>.
  • an ⁇ NDEC> flag indicates the level of decoding that could be achieved among the increasing ordered values corresponding to the OSI model layers.
  • OSI model layers Open Systems Interconnection .
  • ⁇ IAD ⁇ contains the source IP address and the destination IP address of the received packet, and that only the source IP address could be decoded, then the network decode level is not reached and the flag ⁇ NDEC> is set to "null.” Therefore, if a decoding level could not be reached, the following levels could not be reached: By convention, a decoded packet completely relative to the information set ⁇ IAD ⁇ is associated with a ⁇ NDEC> flag with a "total" value, which is equivalent to the "application" level.
  • the module DEC provides a set of decoded information ⁇ ID ⁇ , for example containing any decoded information other than the packet protocol ⁇ P>, the type of message received ⁇ TM> and the flag ⁇ NDEC>.
  • the decoded information contained in the set ⁇ ID ⁇ can be the value of a field of the packet, the number of occurrences of a field of the packet, or the length of a field of the packet, or any combination of these. three types of information mentioned above.
  • the decoding module DEC provides the information ⁇ ID ⁇ , ⁇ P>, ⁇ TM> and ⁇ NDEC>, as well as the received packet PAQ to the filtering module FIL.
  • FIL receives the information ⁇ ID ⁇ , ⁇ P>, ⁇ TM> and
  • ⁇ NDEC> as well as the received packet and applies if necessary static filtering rules and / or dynamic with filtering criteria for ⁇ ID ⁇ , ⁇ P>, ⁇ TM>, or ⁇ NDEC> information.
  • the static filtering rules are configured and activated via a management plan supervised by an administrator, for example as part of a legal interception procedure.
  • Dynamic filter rules are configured and enabled by high-level processing functions.
  • the FIL filtering module applies filtering rules whose filtering criteria relate to the information ⁇ ID ⁇ , ⁇ P>, ⁇ TM> or ⁇ NDEC> extracted by the DEC decoding module, and does not analyze the set of the received packet, so as to optimize the use of the resources of the DD device.
  • the FIL module applies static filtering rules to other information contained in the received packet.
  • the filtering rules are applied according to the ⁇ NDEC> flag. If the received packet has not been fully decoded, i.e. the ⁇ NDEC> flag is different from “total”, filtering rules are applied depending on the decode level reached. For example, if the level reached is "transport”, only filtering rules relating to the "network” and “transport” levels are applied, while the filtering rules relating to the "application” level are not applied.
  • a dynamic filtering rule unlike a static filtering rule, is associated with a context that is managed by a top-level processing function that created the dynamic rule. When this context disappears, the associated dynamic rule is deleted by the FIL module. In order to avoid resource overload attacks, the FIL module can refuse to create a new dynamic filtering rule as soon as a number of rules threshold is reached. On the other hand, the filtering module may delete a dynamic filtering rule that has been inoperative for a predetermined period of time, that is, no packet received during the predetermined period of time has satisfied the criteria for using the filtering rule. the dynamic filter rule.
  • Each filtering rule applied to the received packets can perform the following actions: deleting a received packet, for example when the device is unmuted to avoid denial-of-service attacks from a given source; counting received packets, for example to inform the GHG processing management module of the data volume from a given entity; and - marking a received packet, for example to apply to the latter a specific processing function such as flow recording in the case of a legal interception procedure.
  • the FIL module thus filters the received packets and provides those that have not been deleted to the REC entity type recovery module, with the information ⁇ ID ⁇ , ⁇ P>, ⁇ TM> and ⁇ NDEC>. For the sake of simplification in the remainder of the description, the information ⁇ P>, ⁇ TM> and ⁇ NDEC> are assumed to be included in the set ⁇ ID ⁇ .
  • step E3 the REC entity type recovery module receives the information ⁇ ID ⁇ and the corresponding received packet and applies thereto. the entity recovery function f REC to determine, for each received packet, the sending entity and the destination entity of the received packet.
  • the function recovery function of the f REC entity type returns the following information which is a type of entity ⁇ TE>, an entity subtype ⁇ STE m , ⁇ E > / - with 1 ⁇ m ⁇ M, and an ⁇ IE ⁇ set of an identifier and a context associated with the entity.
  • the entity subtype ⁇ STE m , ⁇ E > more precisely characterizes an entity of a given type ⁇ TE>.
  • ⁇ TE> "mobile terminal”
  • two first sub-types can be ⁇ STE] _
  • TE> "mobile GSM”
  • TE> "mobile UMTS”
  • Each entity of the network RI or RE has a unique identifier and an associated context, forming the set of information ⁇ IE ⁇ specific to this entity.
  • the feature type recovery function f REC performs a match search to a substep E31 and a context recovery to a substep E32.
  • the recovery module REC initiates a correspondence search based on a set of information ⁇ IDX ⁇ which constitutes a total or partial subset of all the information ⁇ ID ⁇ decoded by the module DEC.
  • the information set ⁇ IDX ⁇ is fixed, that is, the search for correspondence always relates to the same parameters.
  • the set of information ⁇ IDX ⁇ may be variable, that is to say the search for correspondence relates to different parameters depending on the type of protocol ⁇ P > or the message type ⁇ TM>.
  • the match lookup compares the ⁇ IDX ⁇ set with primary information or keys stored in the BIE Entity Identification Database.
  • the match lookup is successful and the context recovery sub-step E32 is executed.
  • the search for correspondence can be a failure in the following two cases.
  • substep E32 executed if the search for correspondence to substep E31 is successful, the retrieval module REC reads in the entity identification database BIE the identifier corresponding to the information coinciding with the set. IDX ⁇ . Then the REC retrieves the context associated with this identifier in the BCE entity context database, noting ⁇ IE ⁇ the set consisting of the identifier and the associated context.
  • the REC module thus retrieves the information ⁇ TE>, ⁇ STE> and ⁇ IE ⁇ that are subsequently available for high-level processing functions, both with respect to the sending entity and to the destination entity of the packet. received.
  • information ⁇ TE>, ⁇ STE> are assumed to be included in the set ⁇ IE ⁇ .
  • the ⁇ TE> entity type information allows THN system modules, such as AC compliance analysis and COL collection modules, to tailor processing to the type of entity being considered.
  • THN system modules such as AC compliance analysis and COL collection modules
  • total the REC module performs actions in two cases.
  • the function ÎREC is executed according to the principles described above.
  • the function ÎREC is not executed according to the principles described above and carries out a marking specific to the received packet by assigning a value "IND" to information ⁇ TE> and ⁇ IE ⁇ , indicating to downstream functions that the recovery of the entity type has failed.
  • the recovery module REC supplies the set ⁇ IE ⁇ , as well as the received packet PAQ to the timer module TEM, in addition to the set ⁇ ID ⁇ provided by the decoding module DEC. In addition, the module REC indicates whether the packet is transmitted from the network RE to RI or vice versa.
  • step E4 the timer module TEM stores the sets ⁇ IE ⁇ , ⁇ ID ⁇ and the received packet
  • the TEM module cooperates with the management module GES so that a management function fc ⁇ s determines a processing time ⁇ TT> to allocate functions of the modules of the THN system according to the characteristics of the entity transmitting the received packet.
  • the treatment management function is part of the high level processing functions. More precisely, this function intervenes at the interface between the modules of the TBN system that operate at the debit transmission line and THN system modules that perform much longer operations, causing delay and / or jitter in the processing of received packets.
  • the management function fc ⁇ s takes as input the different parameters: the received packet and the information ⁇ ID ⁇ and ⁇ NDEC> provided by the DEC decoding module; the direction of transmission of the received packet, for example from the network RE to the network RI, provided by the recovery module of the entity type REC; the set ⁇ IE ⁇ containing the identifier and the context associated with the issuing entity, provided by the REC module, this set ⁇ IE ⁇ being able to contain in addition to the information ⁇ TE> and ⁇ STE> information ⁇ NCE> denoting a level of compliance of the issuing entity; knowledge of the processing units UT of the device DD and the high-level processing functions which are attached to these units; for each processing unit, a filling level of the FIFO queue (UT) and available resources CPU (UT); and - for each processing unit, a relative priority pFj (UT) of the function Fj within the processing unit UT, with 1 ⁇ j ⁇ J and J being the number of functions attached to the processing unit.
  • the fc ⁇ s management function regulates processing times relative to each of the modules of the detection device DD, for each treatment unit independently of the other processing units, at regular intervals and timelessly according to sub-steps for determining the mean processing time E41, determining the reference time by function E42, and adjusting the reference time by function E43.
  • CPU (UT) which is a number between 0 and 1, where 0 is the lowest charge, and fl is a function that takes values between 0 and 1 and provides a result also between 0 and 1.
  • the function fl thus provides a result ⁇ Tm> close to 0.1 when the unit UT is saturated, and a result ⁇ Tm> close to 1 when the unit UT is very lightly loaded.
  • the GES module adjusts the average time ⁇ Tm> to the number of packets waiting for the processing unit UT in an adjusted average time ⁇ Tma>, that is to say at the filling level of the queue.
  • FIFO wait (UT) at the input of the UT unit: ⁇ Tma> f2 ( ⁇ Tm>, FIFO (UT)), with FIFO (UT) is a number between 0 and 1, where 0 is by convention the level F2 is a function that takes values between 0 and 1 for the parameters ⁇ Tm> and FIFO (UT) and provides a result also between 0 and 1.
  • the function f2 thus provides a result ⁇ Tma> close to ⁇ Tm> when the queue is almost empty, and a result ⁇ Tma> close to 0.1 when the queue is almost full.
  • the GES module avoids an overall saturation of the DD device, which can lead, for example, to unacceptable processing times or the impossibility of filtering malicious packets.
  • Sub-step E41 is executed at regular time intervals by the GES module in order to update the average time ⁇ Tm> and, if applicable, the adjusted average time ⁇ Tma> as a function of variations in the device load or the level filling queues.
  • the management module GES determines a reference time ⁇ TmFj> for each function Fj attached to the processing unit in question, with 1 ⁇ j ⁇ J and J being the number of functions attached to the processing unit.
  • the reference time ⁇ TmFj> of a function Fj is determined as a function of the average processing time ⁇ Tm> or ⁇ Tma> and the relative priority ⁇ pFj> of this function within the processing unit UT, the relative priority ⁇ pFj> being set for a given implementation of the DD device.
  • the reference time ⁇ TmFj> is further determined as a function of a number of packets ⁇ npFj> for the function Fj.
  • This number of packets ⁇ npFj> is for example determined by the entity recovery module REC which, depending on the type of the entity and the direction of the packet, deduces the functions traversed and counts the number of packets for each of these functions .
  • the reference time ⁇ TmFj> is for example determined according to the following relationship:
  • J J ⁇ Tm> ( ⁇ ⁇ npFj>. ⁇ TmFj>) / ⁇ ⁇ npFj> (1).
  • the unit time TU can be written as follows:
  • the GES module maintains a predetermined average processing time per Tm packet for a given processing unit, and equitably distributes the processing times by function of a processing unit, according to the relative priority of each function within the processing unit. the processing unit, and the number of packets intended for this function.
  • Sub-step E42 is executed at regular time intervals by the module GES in order to update the values ⁇ TmFj> according to the variations of ⁇ Tm> or ⁇ Tma> and the number of packets ⁇ npFj> intended for each of the functions within the processing unit.
  • the management module GES adjusts the reference time by function ⁇ TmFj> according to the context of the entity relating to the received packet, and in particular a compliance level ⁇ NCE> of
  • the management module GHG counts a number of packets ⁇ npFj, k> in the queue that is destined for the function Fj and whose sending entity has a level of conformity ⁇ NCE> equal to k, l ⁇ k ⁇ K and K being the number of different levels of compliance for different issuing entities.
  • ⁇ npFj> ⁇ ⁇ npFj, k> (4).
  • k l
  • the reference time per function ⁇ TmFj> is adjusted to an adjusted reference time ⁇ TmFj, k>, which is an average processing time of the packets of the entity whose compliance level is equal to k, as a function of a relative priority ⁇ pFj, k> of the function Fj for entities of compliance level equal to k.
  • the adjusted reference time ⁇ TmFj, k> is for example determined according to the following relation (5):
  • the average adjusted reference time TRMA can thus be written according to the following relation (7):
  • the GES management module determines a processing time ⁇ TT>, relative or absolute, allocated to a function used by a processing unit UT processing the received packet
  • the processing time ⁇ TT> is equal to the average processing time ⁇ Tm>, or if appropriate to the adjusted average time ⁇ Tma> determined in the substep E41.
  • the processing time ⁇ TT> of a packet intended for a function Fj is equal to the reference time ⁇ TmFj> of the function Fj determined in the substep
  • the GES module may adjust the ⁇ TT> processing time to the ⁇ NCE> compliance level of the entity, and the ⁇ TT> processing time a packet transmitted by the compliance level entity k for a function Fj is equal to the adjusted reference time ⁇ TmFj, k> of the function Fj determined in the substep E43.
  • the GES module then commands the time delay module TEM to provide the sets ⁇ IE ⁇ and ⁇ ID ⁇ and the received packet PAQ to the compliance analysis module AC by allocating a processing time ⁇ TT> for the received packet PAQ to the f AC conformity analysis function •
  • the processing time ⁇ TT> denotes indifferently an absolute processing time, for example a duration of 10 milliseconds, or a relative processing time that is used by the processors.
  • upstream THN system functions to adjust the number of selected rules.
  • the processing time ⁇ TT> allocated to each of the functions of the THN system is not necessarily identical, and depends directly on the implementation and the stream of received packets. These different processing times are denoted ⁇ TAC> / - ⁇ TCTE> / - ⁇ TCOL> and ⁇ TANC> respectively for the functions fA O fcTEr f ⁇ TE and fANC-
  • step E5 the conformity analysis module AC receives the information ⁇ ID ⁇ and ⁇ NDEC> provided by the decoding module DEC, as well as the corresponding received packet PAQ, and applies to these latter the analysis function. of compliance fcc to analyze the received packet according to compliance rules stored in the rule base BR.
  • the function f AC also takes as input the following parameters: sets ⁇ IE ⁇ containing the identifier and the context respectively associated with the entities issuing and destina- tor, including information ⁇ TE> and ⁇ STE>; and the processing time ⁇ TT> allocated by the management function f GES -
  • ⁇ IE ⁇ E and ⁇ IE ⁇ D denote the sets containing the identifier and the context respectively associated with the sending and receiving entities, and these sets are called context of emission ⁇ IE ⁇ E and context of destination ⁇ IE ⁇ D-
  • the ⁇ TT> processing time, relative or absolute, allocated to the function fcc is noted ⁇ TAC> -
  • the AC performs an entity compliance scan defined in step E8 only if the ⁇ TE> E type of the sending entity is defined.
  • step E6 is executed.
  • step E6 the compliance analysis module
  • AC selects a set of ⁇ RAC1 ⁇ compliance analysis rules stored in the rule base BR, for the entities of the undefined type, in particular according to the packet processing time ⁇ i AC > r and optionally the packet protocol ⁇ P> and the type of message received ⁇ TM>.
  • the AC module prioritizes critical compliance analysis rules, and optionally non-critical compliance analysis rules, in order of priority so that the highest priority rules are applied to the received packet during the first time.
  • ⁇ TAC> packet processing time allocated to the fAC function •
  • critical compliance analysis rules take precedence over non-critical rules.
  • the RACl rule verifies that the sending entity transmits requests to an authorized destination port of the destination entity.
  • the rule compares the destination port contained in the received PAQ packet of the current request with a list of the destination authorized ports of the destination entity and stored in the BCE entity context base.
  • the result RESl takes the value OK if the packet conforms to the considered rule, the value NOK if the packet is non-compliant.
  • the result RESl takes the value IND (indefinite) if the rule could not determine if the packet is compliant or not, that is to say if the rule is inapplicable to the packet.
  • the decoding of the destination port contained in the received packet PAQ can be wrong and uninterpretable to be compared with a list of authorized destination ports.
  • the compliance of the packet with the rule is undetermined.
  • the compliance of the packet with the rule may be indeterminate when the rule requires characterization information of type or subtype that is not yet filled in the BCTE when the rule is executed.
  • the compliance analysis module AC provides a global result RESG1 depending on the RESl results returned respectively by the RACl rules.
  • the overall result RESG1 is equal to NOK and the received packet is non-compliant. If no rule gives a result RES1 equal to NOK, but at least one rule gives a result RES1 equal to IND, then the overall result RESG1 is equal to IND.
  • the global result RESGl is also equal to IND if at least one selected critical rule could not be applied to the packet during the time ⁇ TAC> -
  • the module AC updates the compliance information relating to the sending entity considered in the context ⁇ IEJE-
  • several output actions can be executed :
  • the module AC executes an abnormality processing step EA1. If the overall result RESG1 is equal to NOK or IND, the AC module optionally registers history information in the ⁇ IE ⁇ E context of the sending entity. If the overall result RESG1 is equal to OK, the module AC provides a copy of the received packet PAQ and the information associated with the characterization module of the type of entity CTE. The received packet PAQ, considered as compliant, is transmitted by the device DD to the network RI.
  • a correlation request may be addressed to the COL module to update information in the context of the entity, depending on the eventual response returned relative to the parsed packet.
  • step EA1 the conformity analysis module AC detects an anomaly, for example as a function of the overall result RESG1 relating to the received packet PAQ.
  • the AC module can then issue an alarm depending on the level of the anomaly observed, in particular in the case where at least one critical rule of conformity analysis has provided a negative result.
  • the AC module may delete the packet or control the removal of the packet by the DD device.
  • the AC module may add historical information to the transmission context ⁇ IE
  • the AC module can control the addition of a dynamic filtering rule at the level of the FIL module, relative to the sending entity in question, in order to protect itself from packets that can be issued later by this entity.
  • the characterization module of the type of entity CTE receives the information ⁇ ID ⁇ and ⁇ NDEC> provided by the decoding module DEC, as well as the received packet PAQ corresponding, and applies to them the characterization function fc ⁇ ⁇ to determine the type ⁇ TE> E of the transmitting entity and possible sub-types, from a maximum number NMPAQ packets received consecutively from the same issuer of undefined type.
  • the function fc ⁇ ⁇ also takes into account the transmission context ⁇ IE ⁇ E and destination ⁇ IE ⁇ D and a processing time ⁇ TCTE> allocated by the management function f GHG -
  • the function fc TE initializes variables to a value of substep E71, determines characterization rules at a substep E72 and executes these rules determined at a substep E73.
  • the CTE module initializes to zero a number of packets analyzed ⁇ NPA>.
  • the type of the issuing entity is assumed to belong to a set of P possible entity types.
  • the CTE module initializes to zero a counter ⁇ CVT p >, with 1 ⁇ p ⁇ P, indicating the likelihood that the type of the transmitting entity corresponds to the type "p" of an entity, among the P types of possible entity .
  • the higher the value of the ⁇ CVT p > counter the higher the likelihood, and vice versa.
  • the CTE module initializes to zero a counter ⁇ CVT m? P >, with 1 ⁇ m ⁇ M and M the number of subtypes of the transmitting entity, indicating the likelihood that the subtype of the entity issuing corresponds to the "m" subtype of the "p” type of an entity.
  • the P possible entity types are assumed to be sufficiently dissimilar to each other, so that one of the ⁇ CVT p > counters takes a higher value relative to the other counters as the number of packets received and analyzed increases.
  • the CTE module selects a set of ⁇ RCTE ⁇ feature type characterization rules and / or a subset of entity subtype characterization rules ⁇ RSCTE ⁇ from a set of characterization rules stored in the rule base BR.
  • the CTE module selects the characterization rules according to the processing time
  • ⁇ TCTE> allocated by the GES module, the number of received packets ⁇ NPA>, and a likelihood vector ⁇ VV> whose components are the ⁇ CVT p > and ⁇ CVT m , p > counters.
  • the selection parameters ⁇ TCTE> / - ⁇ NPA> and ⁇ VV> are brought back to discrete and bounded spaces, so that the rules can be selected using a static matrix or simple logical rules.
  • the CTE module executes the selected characterization rules, prioritizing the rules of the set ⁇ RCTE ⁇ in respect of the allocated processing time ⁇ TCTE> -
  • Each characterization rule deals with information selected from the sets ⁇ ID ⁇ , ⁇ IE
  • the characterization rule may relate to information contained in the received packet, outside those extracted by the DEC decoding module.
  • Each characterization rule compares selected information, such as attributes of the received packet, with those stored in the BCTE entity type characterization basis. For example, a selected characterization rule RCTE compares the length or value of a field in the received packet with a length or a reference value contained in the BCTE. According to other examples, the selected rule RCTE compares the position of a field relative to other fields in the received packet with respect to a reference position, or compares the number of occurrences of a field in the received packet.
  • the CTE module modifies the vector ⁇ VV> by incrementing some components ⁇ CVT p > or ⁇ CVT m , p >, and decrementing other components.
  • the CTE module checks whether one of the ⁇ CVT p > components has reached a high enough value relative to the other components to determine the type of the sending entity.
  • the module CTE updates the value of the type ⁇ TE> E stored in the entity identification database BIE, and thus updates the transmission context ⁇ IE ⁇ E-
  • the CTE module checks whether one of the components ⁇ CVT m , p > has reached a sufficiently high value compared to the others to determine the sub-type or sub-types of the issuing entity. On the other hand, if the type of the sending entity could not be determined after an NMPAQ number of received packets, the type of the entity remains in the indefinite state "IND", which leads to a new characterization phase of entity type and step E7 is repeated.
  • the CTE module stores history information in the context of the entity in the BCE entity context database.
  • the CTE may issue an alarm at step EA2 if the type of the transmitting entity could not be determined.
  • the CTE module detects an anomaly relating to the PAQ packets of the transmitting entity, meaning for example that the entity is of unknown type and potentially dangerous.
  • step E8 if the type of entity ⁇ TE> E is considered as defined by the compliance analysis module AC at the end of step E5, the conformity analysis function f A c of the AC module determines compliance analysis rules to a substep E81 and executes these determined rules at a substep E82.
  • the AC module selects a set of compliance analysis rules ⁇ RAC2 ⁇ stored in the rule base BR, depending in particular on the compliance level ⁇ NCE> E of the issuing entity, the time the ⁇ TAC> / - packet processing type of the ⁇ TE> E entity type of the transmitting entity, and possibly the ⁇ P> packet protocol and the ⁇ TM> received packet type.
  • the function f A c thus adapts the compliance analysis to the compliance level of the transmitting entity and to the available resources of the detection device.
  • Compliance Analysis Rule Set ⁇ RAC2 ⁇ includes both types of following rules: critical rules and non-critical rules.
  • Critical compliance analysis rules take precedence over non-critical rules.
  • the critical rules are used to detect anomalies or attacks that are considered critical, that is, dangerous in relation to the controlled service.
  • each packet received contains "From" and "To" fields which respectively designate logical identifiers of transmission and destination. and which are decoded by the DEC decoding module.
  • a critical rule verifies that the transmitting entity transmitting a packet that is an "INVITE" type message has a transmission identifier designated in the "From" field of the packet that is present in the BCE entity context base.
  • this transmission identifier has been stored in the BCE database by the correlation function fco R having established a correlation between a request of type "REGISTER” sent from the issuing entity and a response to this request by the entity destination, the response containing this transmission identifier in a "To" field.
  • a critical rule verifies that the sending entity does not issue a forbidden request according to the type ⁇ TE> E of the entity. For this purpose, the critical rule compares the type of the current request with a list of forbidden requests associated with the type ⁇ TE> E of the entity and stored in the BCE database.
  • Non-critical rules of conformity analysis are less important than critical rules, and relate to anomalies or attacks that are supposed to be possible by the administrator of the device DD, but whose consequences are less than those of a critical attack.
  • a non-critical rule verifies that the received PAQ packet transmitted by the sending entity is a "SIP" type message that is authorized for the sending entity according to the type and / or at least one subtype of the latter.
  • the non-critical rule compares the message type "SIP" with a list of message types associated with the transmitting entity and stored in the BCTE database. For example, this list has been stored in the BCTE database by the learning function f APP -
  • critical rules can be for denial of service or identity theft attacks, while non-critical rules can be for information-gathering attacks.
  • the critical rules can be ordered among them by priority level.
  • substep E82 the AC module applies the selected compliance analysis rules to the received packet.
  • the AC module cooperates with the COR correlation module to establish correlations between received packets.
  • the result provided by the function f ⁇ c can not depend correlation rules used by the ROC unit since the AC module needs to give a result for each received packet.
  • correlation rules called by the function f ⁇ c serve to update information stored in the BCE database that may be subsequently used by the AC module.
  • a selected RAC2 conformance analysis rule is executed based on the received packet PAQ and the sending contexts ⁇ IE ⁇ E and destination ⁇ IE
  • D, and the AC module makes a decision on the compliance of the PAQ packet based on an RES2 result provided by the analysis rule: RES2 RAC2 (PAQ, ⁇ IE ⁇ E , ⁇ IE ⁇ D ).
  • the result RES2 is set to OK if the packet conforms to the considered rule, the value NOK if the packet is non-compliant, and the value IND (indefinite) if the rule could not determine if the packet is compliant or not, that is, if the rule is inapplicable to the packet.
  • the result RES2 takes the value IND for example when the rule refers to an entity type attribute that is not yet defined when the rule is executed.
  • the AC executes some or all of the selected rules in order of priority so that the highest priority rules, in this case the critical rules, are applied to the received packet during the allocated packet processing time ⁇ TAC> to the function fA C • In particular, even if a rule gives a negative result, the following rules are executed.
  • the compliance analysis module AC provides a global result RESG2 depending on the results RES2 returned respectively by the rules RAC2.
  • step E6 if at least one rule gives a result RES2 equal to NOK, then the overall result RESG2 is equal to NOK and the received packet is non-compliant. If no rule provides result RES2 equal to NOK, but at least one rule provides a result RES2 equal to IND or if at least one selected critical rule could not be applied to the packet during the time ⁇ T ⁇ c> / - then the overall result RESG2 is equal to IND. In all other cases, that is, if no rule has given a result equal to NOK or IND and if all selected critical rules have been executed, then the RESG2 global result is equal to OK and the received package is considered compliant.
  • the compliance analysis module AC possibly updates the transmission context ⁇ IE ⁇ E and the compliance level ⁇ NCE> E of the issuing entity.
  • the compliance level decreases, respectively increases, when at least one rule provides a negative result, respectively positive for a received packet.
  • the level of compliance decreases, respectively increases, if a predetermined number of rules provides a negative result, respectively positive, for a given packet, or for several consecutive packets, or for several packets received among a number of packets predetermined.
  • the module AC provides a copy of the received packet PAQ and the information associated with the collection module COL, and the method proceeds to step E9.
  • the received packet PAQ considered as compliant, is transmitted by the device DD to the network RI.
  • the AC module provides the received packet PAQ and the information associated with the ANC non-conformance analysis module, and the process goes to step EIl.
  • the AC module issues an alert as described in the alert step EA1.
  • the AC module adds a dynamic filtering rule to those managed by the FIL filtering module to block streams comprising packets similar to the received packet PAQ or to count the packets transmitted by the transmitting entity.
  • the module AC provides the set ⁇ RES2 ⁇ containing the results of each compliance analysis rule that could be executed, in order to inform the downstream processing functions, in particular COL and ANC modules, on details observed on the received packet PAQ.
  • step E9 if the received packet is considered compliant by the AC module in step E8, the collection module COL receives the information ⁇ ID ⁇ and ⁇ NDEC> provided by the DEC decoding module, as well as the packet corresponding PAQ receipt, and applies to them the collection function fco L in order to extract from the received packet entity type characterization attributes intended to update the characterization basis of entity type BCTE, via the function fAPP-
  • the fco L function also takes into account the transmission context ⁇ IE ⁇ E retrieved by the REC module and a processing time ⁇ TCOL> allocated by the fGES management function. • The fco L function determines collection rules to be applied to a sub-step E91 and executes these determined rules at a substep E92.
  • the collection module COL selects a set of collection rules ⁇ RCOL ⁇ stored in the rule base BR, in particular according to the type ⁇ TE> E of the issuing entity and the processing time ⁇ TCOL> -
  • the fcoL function adapts a collection level to the type of the sending entity and the available resources of the DD device.
  • a collection rule RCOL designates a set ⁇ AA ⁇ of characterization attributes of type or subtype to be collected for the received packet, each attribute being associated with a collection method.
  • the collection rules can be further selected according to the packet protocol ⁇ P> and the type of message received.
  • TM> contained in the set ⁇ ID ⁇ , in which case: ⁇ RCOL ⁇ fcoL ( ⁇ TE> E , ⁇ T C0 L>, ⁇ P>, ⁇ TM>).
  • the packet may be a "REGISTER” or "INVITE" type message.
  • the collection module COL executes the selected collection rules, according to a predefined priority order in respect of the allocated processing time ⁇ TCOL> -
  • Each attribute to be collected AA, contained in the set ⁇ AA ⁇ , is extracted from the received packet and then submitted to the corresponding collection method.
  • an attribute to be collected AA may designate the presence, value, length or number of occurrences of a field in the received packet, or the length or time of reception of the received packet.
  • a collection method can consist of counting a number of events or an average value over a predetermined period, determining a maximum value, for example the rate of received packets, or updating an attribute already learned.
  • the fco L collection function provides an error result if at least one RCOL collection rule could not be executed correctly, that is, an attribute to be collected AA could not be extracted from the received packet, or that the corresponding collection method failed.
  • the error result is provided as an indication to the DD device, for example to detect entities whose type has been incorrectly determined or which exhibit abnormal behavior, but does not result in the deletion of the received packet.
  • Each collection rule updates characterization information contained in the transmission context ⁇ IE ⁇ E, which can relate indifferently to the type or subtypes of the entity.
  • This characterization information collected by the fco L collection function is only initialized, written or updated in the transmission context ⁇ IE ⁇ E contained in the BCE entity context database, but is not reported in the characterization database.
  • BCTE entity type In the step ElO, the learning module APP updates attributes of type or subtype of entity ATT stored in the characterization basis of entity type BCTE.
  • the APP module operates asynchronously with respect to the other modules of the DD device, and over a much longer period of time, for example several hours or several days. The asynchronous operation of the APP module directly depends on the available resources of the DD device.
  • the learning function f APP collects entity type or subtype attributes at a sub-step ElO1 and aggregates the collected attributes to a substep E102.
  • the APP training module selects ATT type attributes contained in the BCE entity context base corresponding to a predetermined entity type or subtype.
  • the attributes collected must constitute a homogeneous set, that is to say each correspond to the same characterization information, carried by a set of entities of the same type or sub-type.
  • the collection substep ElO1 ends in failure and the substep of aggregation E102 n is not executed.
  • the step ElO is then repeated at the next expiration of the refresh period.
  • the APP training module applies statistical analysis methods to the set of selected attributes. A statistical analysis method is used depending on the type or subtype of characterization information constituting the set of selected attributes.
  • the method calculates the average of the selected attributes. each corresponding to a particular field length of a received packet.
  • Each method thus provides a result that is a likely attribute for an entity type.
  • the APP module updates entity type characterization attributes in the BCTE entity type characterization basis according to the results provided by the statistical analysis methods, or creates such attributes in the BCTE database when the latter are made. do not exist.
  • the APP module thus refreshes the entity type characterization attributes according to the attributes to learn AA extracted from the received packet and other attributes extracted from packets intercepted by the DD device and previously issued by other entities of the same type as that of the issuing entity. These updated attributes thus enable the characterization module of the CTE entity type to specify the type determination of another entity whose packets are subsequently received by the device DD and whose type is undefined.
  • the APP module may emit an alarm at a step EA3 depending on the selected attributes.
  • the APP module can detect values abnormal attributes selected. For example, an abnormal value is a value excluded from a predetermined interval including a predetermined reference value, such as an average of values of a set of selected attributes. The APP module thus detects an anomaly relating to the entity whose attribute has an abnormal value.
  • the detection of an abnormal attribute value generally assumes an anomaly relating to the entity that issued the packet.
  • This anomaly can come from an entity with malicious behavior not detected by the AC compliance analysis module, a mis-configured entity, or an entity whose type or subtype was poorly determined by the CTE entity characterization module.
  • the learning function, f APP whose execution is of the long-term type, is complementary to the compliance analysis function f AC executed for each received packet, and the entity characterization function fc ⁇ ⁇ executed for a small number of received packets.
  • the APP module can then issue an alarm according to the anomaly observed and the entity relating thereto, or add history information to the entity context database.
  • ECB ECB.
  • step EI1 if the received packet is considered as non-compliant by the AC module in step E8, the non-compliance analysis module ANC receives the information ⁇ ID ⁇ and ⁇ NDEC> provided by the module. DEC, the ⁇ IE ⁇ E and ⁇ IE ⁇ D contexts, the ⁇ NCE> E conformance level and the corresponding received PAQ packet, and the RES2 results of each compliance analysis rule provided by the AC module, and applies to them the non-conformance analysis function f ANC to establish a correlation between non-conforming packets issued by the issuing entity. This correlation is useful for characterizing in the medium term a type of attack or malicious behavior of the entity, relative to a set of non-compliant packets received from this entity.
  • the ANC non-conformance analysis function also takes as input a ⁇ TANC> processing time allocated by the fGES management function.
  • the f ANC function determines non-compliance analysis rules for an ElIl substep. and executes these determined rules at a substep E112.
  • the ANC module selects a set of non-conformance analysis rules ⁇ RANC ⁇ stored in the rule base BR, in particular according to a set ⁇ RES2 ⁇ NC of the non-compliant results returned by the compliance analysis rules and processing time ⁇ T ANC> -
  • the set ⁇ RES2 ⁇ NC therefore depends on conformity analysis rules which are not in accordance with the received packet and other packets also issued by the entity.
  • the function f ANC is described for example in the form of regular expressions based on simple logical operators such as "AND”, "OR” or “NOT”.
  • Each regular expression refers to all or part of the ⁇ RES2 ⁇ NC set and, if checked, adds one or more non-conformance analysis rules to the ⁇ RANC ⁇ set.
  • the set ⁇ RANC ⁇ can then be reduced according to the available resources of the device DD and thus the allocated processing time ⁇ TANC> -
  • the set ⁇ RES2 ⁇ NC contains M rule identifiers RES2 m , with 1 ⁇ m ⁇ M and M ⁇ K, giving a NOK result for the analyzed packet.
  • the function f ANC can be described in the following form: RES2io OR RES2i2 "> RANCi , RES2 3 -> RANK 2 , RES2 5 AND (NOT RES2) _o) "> RANK 3 , ROUND 4 , and
  • RESC RANC (PAQ, ⁇ IE ⁇ E , ⁇ IE ⁇ D ).
  • the RESC result indicates whether the nonconformity analysis rule could have been correctly executed or if other actions are needed.
  • a RANC nonconformity rule is executed in the following three phases:
  • a third phase where the rule becomes inactive, for example when a timer expires, and the compliance information associated with the rule is deleted.
  • Compliance information is for example the time elapsed between the issuance of a request and the receipt of a response to the request.
  • compliance information contained in a ⁇ IE ⁇ E transmission context is associated with a RANC rule, this means that the RANC rule is active and executed.
  • the ANC executes the selected RANC rules in whole or in part, for example in order of priority, during the processing time ⁇ TANC> allocated to the ANC non-compliance analysis function.
  • the ANC module optionally updates compliance information of the transmission context ⁇ IE
  • the ANC module may add history information to the BCE entity context database, or cooperate with the module COR correlation to establish correlations between the analyzed received packet and other received packets.
  • the ANC module adds a dynamic filtering rule to those managed by the FIL filtering module to block for example flows comprising packets similar to the received packet.
  • the ANC may issue an alarm at a step EA4 depending on the selected RANC rules.
  • the ANC module detects an anomaly if one of the selected RANC rules provides a negative result.
  • the ANO function whose execution is of the medium-term type, is complementary to the compliance analysis function f AC performed for each received packet and makes it possible to detect discrete attacks which are spread over a longer period of time. time, for example a few minutes or a few hours.
  • the steps of the method according to the invention are performed for a traffic compliance analysis issued by both the ES service entities to the EC client entities and the EC client entities to the ES service entities.
  • the compliance analysis of the traffic sent by the ES service entities to the EC client entities makes it possible, in particular, to initialize new ES service entities attached to the internal network RI and possibly to detect a malicious behavior or a bad configuration of the latter.
  • the invention described herein relates to a method and a device for detecting anomalies in traffic transmitted by one entity to another entity.
  • the steps of the method of the invention are determined by the instructions of a computer program incorporated into a processor of the detection device according to the invention.
  • the program comprises program instructions which, when said program is executed in the processor 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, in particular a computer program recorded on or in a computer readable recording medium and any data processing device, adapted to implement the computer program. '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 recording medium may be any entity or device capable of storing the program.
  • the medium may comprise storage means on which the computer program according to the invention is recorded, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or a USB key, or magnetic recording means, for example a floppy disk or a hard disk.
  • the recording 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 recording medium may be an integrated circuit in which the program is incorporated, the circuit being adapted to execute or to be used in the execution of the method according to the invention.

Abstract

Pour détecter des anomalies dans le trafic émis par une entité (EC; ES) vers une autre entité, un dispositif (DD) intercepte un paquet du trafic (PAQ) émis par l'entité et détermine un contexte de l'entité en fonction du paquet intercepté. Un module d'analyse de conformité (AC) sélectionne au moins l'une de premières règles (RAC) en fonction du contexte de l'entité, contenant par exemple un type de l'entité, et de ressources disponibles du dispositif ayant intercepté ledit paquet. Le module d'analyse décide la conformité du paquet intercepté à la première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si la première règle sélectionnée est inapplicable au paquet intercepté. Le module d'analyse détecte une anomalie si le paquet intercepté n'est pas conforme à la première règle sélectionnée.

Description

Détection d'anomalie dans le trafic d'entités de service à travers un réseau de paquets
La présente invention concerne la sécurité dans un réseau de paquets basée sur des analyses de paquets transmis dans le réseau. Plus particulièrement, elle a trait à une détection d'anomalies ou d'incidents de sécurité dans le trafic supporté par une liaison de transmission et relatif à au moins une entité de service dans le réseau de paquets .
Un réseau de paquets, comme l' internet, transmet des paquets 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 d'entités clientes, telles que des 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 proposant un téléchargement de fichiers multimédias, un serveur de messagerie électronique, ou un serveur d'applications de voix sur IP VoIP ("Voice Over IP" en anglais). Les entités de service peuvent être confrontées à divers types de problèmes relatifs au trafic des paquets, tels que des attaques ou des anomalies qui dégradent la qualité du service offert par les entités de service. Une anomalie peut être considérée comme 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 connaissances expertes et de règles, définissant par exemple des caractéristiques que le trafic normal doit satisfaire.
En particulier, des réseaux offrant un service de voix sur IP VoIP sont en pleine expansion. De tels réseaux sont amenés à remplacer à terme les réseaux de téléphonie classique et à supporter de nouvelles applications multimédia telles que la visioconférence, alors que des efforts limités sont entrepris pour la sécurité de ces applications. Or, avec l'augmentation du nombre de clients et d'interconnexions entre des réseaux de différents opérateurs, il est prévisible que les réseaux de voix sur IP soient soumis dans un futur proche à des actes malveillants tels que des usurpations d'identité, des envois de messages polluants, ou des tentatives de mise hors service des entités de service, par exemple dans un but de dégradation de l'image de marque.
Dans l'état de la technique, il existe des équipements de protection de réseau, tels que des pare-feu ou des dispositifs de voix sur IP, qui bloquent ou rejettent du trafic anormal. Ces équipements n'établissent pas de cartographie des entités générant du trafic anormal, pour prévenir d'éventuelles attaques du réseau depuis de telles entités. Il est donc difficile de détecter des comportements anormaux du trafic avant que ces derniers ne soient dangereux pour le réseau, et que les paquets ne soient bloqués. Les équipements actuels sont davantage orientés sur le blocage de paquets non-conformes ou hostiles que sur une détection en amont des comportements anormaux.
La finesse et la complexité des analyses effectuées par de tels équipements sont limitées à l'analyse portant sur des paquets du trafic en cours de traitement et éventuellement sur le contexte applicatif associé au trafic.
D'autres équipements de protection de réseau, tels que des sondes de détection d'intrusion IDS ("Intrusion Détection System" en anglais) ou des pots de miel, ne distinguent pas les traitements effectués en fonction du type de l'entité à l'origine du trafic. Par exemple, les "pots de miel" effectuent des traitements uniquement sur le trafic qu'ils attirent et n'analysent pas le trafic destiné à des entités de service.
Par ailleurs, des équipements de protection traitant de grands volumes de trafic ont un niveau d'analyse limité qui ne permet pas de prendre en compte les spécificités du service voix sur IP. De tels équipements offrant un niveau d'analyse approfondi sont limités par des capacités de traitement et par les débits supportés.
Pour remédier aux inconvénients évoqués ci- dessus, un procédé selon l'invention pour détecter une anomalie dans le trafic émis par une entité, comprenant une récupération d'un contexte de l'entité en fonction d'un paquet intercepté dans le trafic, caractérisé en ce que, ledit contexte récupéré comprenant au moins un type et un niveau de conformité de l'entité, il comprend : une sélection d'au moins l'une de premières règles prédéterminées en fonction du type et du niveau de conformité de l'entité récupéré et de ressources disponibles d'un dispositif ayant intercepté ledit paquet, une décision sur la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté, et une actualisation du contexte de l'entité en fonction de la décision prise sur la conformité du paquet intercepté.
Une anomalie peut alors être détectée si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée. L'invention détecte avantageusement près d'une entité à protéger, telle qu'une entité de service, des anomalies comportementales aussi bien dans le trafic dirigé vers cette entité que dans le trafic qui en provient, de manière à signaler très rapidement et précisément une attaque ou une anomalie dans le trafic analysé.
L'invention détecte en outre des comportements malveillants avant qu'une éventuelle attaque ne survienne. En effet, toute attaque contre une entité de service est généralement précédée d'une phase d'investigation durant laquelle l'attaquant recherche les limites de sécurité de l'entité de service.
Le procédé selon l'invention détecte ainsi des comportements malveillants intentionnels, résultant par exemple directement de l'action d'un attaquant à l'extérieur du réseau auquel est rattachée l'entité de service, ainsi que des comportements malveillants non intentionnels, résultant par exemple de l'action d'un terminal client infecté par un ver qui émet des paquets en grande quantité. De même, un terminal de client mal configuré non intentionnellement peut être détecté, idéalement avant que le client n'appelle un centre d'assistance technique.
Le procédé selon l'invention distingue des entités non fiables, telles que des entités clientes, d'entités fiables, telles que des entités de service, en sélectionnant des règles en fonction du contexte de l'entité, comprenant par exemple un type ou un sous-type de l'entité, et des ressources disponibles du dispositif afin de ne pas exposer ce dernier à des attaques par saturation de ressources. Cette distinction permet d'analyser plus précisément des paquets émis par des entités considérées non fiables.
Outre la détection d'anomalies et de comportements malveillants, le procédé selon l'invention permet à un dispositif de détection d'anomalie de réagir à l'anomalie détectée par exemple en mémorisant les anomalies, en levant une alarme ou en bloquant le trafic présentant une anomalie.
Par ailleurs, l'invention adapte l'analyse effectuée sur le paquet intercepté en fonction des ressources du dispositif par exemple en fonction d'un compromis entre un temps d'exécution nécessaire à l'application d'une règle sélectionnée au paquet intercepté, un risque relatif au paquet reçu dépendant d'anomalies déjà détectées pour l'entité et des ressources disponibles du dispositif de détection d ' anomalie .
Selon une autre caractéristique de l'invention, si le type de l'entité n'est pas défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, l'actualisation du contexte de l'entité est faite en fonction du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité.
La profondeur d'analyse est ainsi adaptée au type de l'entité et éventuellement à un historique d'analyse des paquets émis par l'entité. Selon une autre caractéristique de l'invention, si un type de l'entité est défini dans le contexte de l'entité, la sélection de ladite au moins une première règle peut dépendre d'un niveau de conformité de l'entité contenu dans le contexte de l'entité, ledit niveau de conformité dépendant de la conformité d'au moins un autre paquet de l'entité intercepté préalablement audit paquet intercepté à au moins une autre première règle. Les premières règles sont ainsi sélectionnées en fonction du type de l'entité et du niveau de conformité de cette dernière, afin d'analyser plus précisément des entités considérées non-conformes et peu fiables. Une fois que le type de l'entité est défini, l'invention applique des règles plus précises à des paquets émis ultérieurement par l'entité, afin de détecter éventuellement d'autres types d'anomalie.
Selon une autre caractéristique de l'invention, le contexte de l'entité peut être actualisé en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée. Le niveau de conformité de l'entité est actualisé après l'analyse de chaque paquet intercepté. Par conséquent, le contexte de l'entité est également actualisé, et les premières règles sélectionnées en fonction du contexte de l'entité peuvent être différentes pour chaque paquet intercepté.
Selon une autre caractéristique de l'invention, le procédé peut comprendre en outre, si le type de l'entité est défini et si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée, une sélection d'au moins une deuxième règle en fonction du contexte de l'entité et de ladite au moins une première règle à laquelle n'est pas conforme le paquet intercepté et une détection d'une anomalie en fonction d'une conformité du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité à ladite au moins une deuxième règle sélectionnée.
Selon l'invention, d'autres anomalies, telles que des attaques réparties dans le temps, sont détectées ultérieurement à l'analyse du paquet reçu, en considérant un ensemble de paquets qui sont non conformes aux règles sélectionnées et émis par la même entité.
Selon une autre caractéristique de l'invention, le procédé peut comprendre en outre, si le type de l'entité est défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, une extraction d'attributs du paquet intercepté et une mémorisation des attributs extraits dans le contexte de l'entité. De plus, le procédé peut comprendre en outre une actualisation d'attributs de type d'entité en fonction des attributs extraits mémorisés et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, et une détection d'anomalie si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits.
L'invention récupère des informations relatives au paquet qui est émis par une entité fiable pour enrichir une base de données comprenant des attributs relatifs au type de l'entité, de manière à déterminer ultérieurement plus précisément d'autres entités indéfinies .
Selon l'invention, le dispositif de détection d'anomalie apprend ainsi des caractéristiques communes et utiles à la détection d'entités de même type.
Selon encore une autre caractéristique de l'invention, les premières règles sélectionnées peuvent comprendre des règles critiques et des règles non-critiques, les règles critiques étant appliquées au paquet intercepté de manière prioritaire par rapport aux règles non-critiques, et la conformité du paquet intercepté peut être indéterminée si au moins une des règles critiques n'a pas pu être appliquée au paquet intercepté pendant un temps de traitement prédéterminé .
Les règles critiques visent la détection d'anomalies ou d'attaques ayant un impact critique et immédiat sur le service contrôlé, et sont appliquées en priorité au paquet intercepté. Les règles non- critiques ont un impact moins fort ou moins immédiat et sont par exemple appliquées au paquet intercepté en fonction des ressources disponibles du dispositif. Par exemple, la dichotomie entre les règles critiques et non-critiques est réalisée par l'expert du domaine .
Selon l'invention, le nombre de règles sélectionnées peut dépendre du niveau de conformité de l'entité. L'invention analyse les paquets interceptés d'une entité d'autant plus précisément que l'entité est considérée comme non conforme Par exemple, le nombre de règles sélectionnées est d'autant plus élevé que le niveau de conformité est faible, c'est-à-dire que l'entité n'est pas fiable.
L'invention concerne également un dispositif pour détecter une anomalie dans le trafic émis par une entité présentant un contexte récupéré en fonction d'un paquet intercepté dans le trafic, caractérisé en ce que, ledit contexte récupéré comprenant au moins un type et un niveau de conformité de l'entité, il comprend : - un moyen pour sélectionner au moins l'une de premières règles prédéterminées en fonction du type et du niveau de conformité de l'entité récupéré et de ressources disponibles du dispositif,
- un moyen pour décider la conformité du paquet intercepté à ladite au moins une première règles sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté, et - une actualisation du contexte de l'entité en fonction de la décision prise sur la conformité du paquet intercepté.
Selon une autre caractéristique de l'invention, le dispositif peut comprendre :
- un moyen pour détecter une anomalie en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, - un moyen pour détecter une anomalie en fonction d'au moins une deuxième règle qui est sélectionnée en fonction du contexte de l'entité et d'au moins une première règle à laquelle n'est pas conforme le paquet intercepté, - un moyen pour détecter une anomalie si un type de l'entité contenu dans le contexte de l'entité est indéterminable, et
- un moyen pour détecter une anomalie en fonction d'attributs extraits du paquet intercepté et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits. Selon une autre caractéristique de l'invention, le dispositif peut est lié à une base de données comprenant le contexte de l'entité et les attributs extraits des paquets interceptés, et lié en outre à une autre base de données comprenant des attributs de type d'entité qui sont actualisés en fonction des attributs extraits des paquets interceptés et qui servent à déterminer le type de l'entité.
Enfin, l'invention se rapporte à un programme d'ordinateur apte à être mis en œuvre dans un processeur, comme celui dans un dispositif pour détecter des anomalies dans le trafic émis par une entité vers une autre entité, ledit programme comprenant des instructions qui, lorsque le programme est exécuté dans le processeur, réalisent les étapes conformes au procédé de 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 de l'invention données à titre d'exemples non limitatifs, en référence aux dessins annexés correspondants dans lesquels :
- les figures IA et IB sont des blocs-diagrammes schématiques d'un système selon respectivement des première et deuxième réalisations de l'invention ;
- la figure 2 est un bloc-diagramme schématique d'un dispositif de détection d'anomalie selon l'invention ; et - la figure 3 est un bloc-diagramme schématique de bases de données relatives au dispositif de détection d'anomalie selon l'invention ; et
- les figures 4 et 5 sont un algorithme d'un procédé de détection d'anomalie selon l'invention.
En référence aux figures IA et IB, un dispositif de détection d'anomalie DD selon l'invention est par exemple inclus dans une sonde et fait office d'agent essentiellement logiciel pour protéger des entités de service ES reliées entre elles via un réseau de paquets RI interne à un réseau transmission par paquets plus global comme 1 ' internet . Par exemple, les entités de service sont des serveurs web reliés entre eux par l'intermédiaire d'un ou plusieurs routeurs .
Le réseau de paquets interne RI est par exemple un réseau informatique, tel qu'un intranet d'une entreprise ou une partie de l' internet, géré par un opérateur selon le protocole IP ("Internet Protocol" en anglais). Le réseau de paquets interne RI offre un ou plusieurs services, tel que la voix sur IP, supportant chacun un ou plusieurs protocoles, tel que le protocole d'initiation de session SIP ("Session Initiation Protocol" en anglais) pour le service de voix sur IP, ou des protocoles privés tels que le protocole IPX ( "Inter-network Packet eXchanqe" en anglais) .
Des paquets sont transmis aux entités de service ES via une liaison de transmission LT depuis des entités clientes EC reliées entre elles via un réseau de paquets RE externe au réseau de paquets interne RI regroupant les entités de service dans 1 ' internet . Les entités clientes sont par exemples des terminaux d'usager ou des serveurs. La liaison de transmission LT est située à proximité des entités de service ES dont le trafic est à surveiller par le dispositif de détection DD afin que ce dernier détecte des anomalies dans le trafic qui caractérisent par exemple des comportements anormaux ou malveillants des entités clientes, tels que des attaques par inondation des entités de service.
Par exemple, la liaison de transmission LT à laquelle le dispositif de détection DD est connecté en écoute selon la figure IA ou en coupure selon la figure IB, est située au point d'entrée d'une ou plusieurs entités de service ES, entre le réseau externe RE et le réseau interne RI, par exemple entre un routeur en bordure réseau externe RE et un routeur du réseau interne RI relié à une ou plusieurs entités de service ES.
Selon une première réalisation de l'invention en référence à la figure IA, le dispositif de détection DD est placé en écoute ou en dérivation et a pour fonction principale de détecter du trafic suspect. Par exemple, le dispositif DD enregistre des caractéristiques du trafic suspect, déclenche des alarmes selon des caractéristiques du trafic suspect et optionnellement commande des équipements de protection aptes à bloquer du trafic suspect, tel qu'un pare-feu connecté en bordure du réseau de paquets interne RI. Le dispositif DD signale une alerte à partir de l'observation du trafic relatif à des entités de service dans la liaison LT afin que l'opérateur prenne des mesures adéquates pour contrer une éventuelle attaque dirigée vers les entités de service .
Selon une deuxième réalisation de l'invention en référence à la figure IB, le dispositif de détection DD est placé en coupure et a pour fonction principale de détecter et bloquer du trafic suspect. Le dispositif DD placé en coupure a, outre les mêmes fonctionnalités que le dispositif DD placé en écoute, la fonctionnalité de bloquer directement le trafic suspect .
Dans tous les cas, le dispositif de détection DD analyse la conformité du trafic de manière bidirectionnelle, c'est-à-dire à la fois le trafic émis par les entités clientes EC potentiellement malveillantes vers les entités de service ES à protéger et le trafic émis par les entités de service ES à protéger vers les entités clientes EC potentiellement malveillantes. En variante, le dispositif de détection DD analyse seulement la conformité du trafic émis par les entités clientes EC vers les entités de service ES, le trafic émis par les entités de service ES étant considéré comme non malveillant.
En référence à la figure 2, le dispositif de détection 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. Le dispositif DD reçoit des paquets PAQ transmis via la ligne de transmission LT. Optionnellement , les paquets reçus sont préalablement filtrés par une entité en amont, indépendante du procédé, par exemple une entité de type pare-feu. Ce filtrage en amont porte par exemple sur des adresses IP et sur des protocoles de transmission, afin de ne pas surcharger le dispositif DD.
En relation avec l'invention, le dispositif de détection DD comprend un système de traitement de bas niveau TBN, opérant idéalement à la vitesse de la liaison de transmission LT, incluant un module de décodage DEC, un module de filtrage FIL et un module de récupération de type d'entité REC.
Le module de décodage DEC extrait de chaque paquet reçu PAQ certains éléments d'information utiles au procédé. Ces éléments sont prédéterminés en fonction des protocoles supervisés et optionnellement , pour un protocole donné, du type de paquet reçu. Le module de filtrage FIL filtre des paquets PAQ, en fonction de règles de filtrage s 'appliquant aux éléments d'information extraits par le module de décodage DEC.
Le module de récupération de type d'entité REC récupère en fonction des éléments d'information extraits de chaque paquet reçu par le module de décodage DEC les types des entités émettrice et destinatrice du paquet reçu au moyen d'une fonction de récupération de type d'entité fREC • Le module REC récupère le cas échéant des contextes associés aux entités déterminées, en particulier des informations sur le type d'entité, cette information de type étant structurée hiérarchiquement en un ou plusieurs sous- types . En sortie du module de récupération de type d'entité REC, les éléments d'information extraits par le module de décodage DEC, les éléments d'information récupérés par le module REC, et le paquet reçu, sont fournis à un module de temporisation TEM qui place ces éléments en file d'attente avant qu'ils ne soient traités par un système de traitement de haut niveau THN du dispositif de détection DD.
Le système de traitement de haut niveau THN inclut un module d'analyse de conformité AC, un module de caractérisation du type d'entité CTE, un module de collecte d'informations de caractérisation du type d'entité COL et un module d'analyse de non- conformité ANC.
Le module d'analyse de conformité AC détecte des comportements anormaux ou malveillants du trafic sur une échelle de temps court-terme, en analysant chaque paquet reçu PAQ au moyen d'une fonction d'analyse de conformité fAC • Par défaut, le module AC effectue une analyse de conformité seulement sur les paquets émis depuis le réseau externe RE vers le réseau interne RI, les paquets reçus du réseau interne RI étant supposés non malveillants. De manière symétrique, 1 ' analyse de conformité peut être effectuée également sur les paquets émis depuis le réseau interne RI vers le réseau externe RE. Des traitements relatifs à l'analyse de conformité sont basés notamment sur le type des entités qui sont la source ou la destination du paquet reçu PAQ.
Le module de caractérisation du type d'entité CTE détermine, sur une échelle de temps moyen-terme, le type et/ou les sous-types d'une entité en provenance de laquelle a été reçu un ensemble de paquets PAQ au moyen d'une fonction de caractérisation fCTE • Le module CTE effectue une caractérisation d'entité qui s'applique aussi bien aux entités du réseau interne RI qu'à celles du réseau externe RE. Lorsqu'une nouvelle entité est rattachée au réseau interne RI ou au réseau externe RE, le module CTE détermine le type de cette nouvelle entité ou signale une anomalie dans le cas où la détermination échoue.
Le module de collecte d'informations de caractérisation du type d'entité COL collecte des attributs de type d'entité ATT en fonction des informations contenues dans les paquets reçus PAQ au moyen d'une fonction de collecte fCOL • Le module COL effectue un premier niveau d'apprentissage sur les attributs collectés pour chaque type d'entité. Cet apprentissage s'applique à la fois aux entités du réseau interne RI qu'à celles du réseau externe RE. L'apprentissage est effectué sur des paquets dits conformes pour lesquels l'analyse de conformité a donné un résultat positif.
Le module d'analyse de non-conformité ANC analyse des paquets dits non-conformes pour lesquels l'analyse de conformité a donné un résultat négatif, au moyen d'une fonction d'analyse de non-conformité fANC • Le module ANC effectue une analyse de non- conformité qui corrèle un ensemble de paquets non- conformes émis par une entité donnée afin d'en déduire un type de comportement non-conforme ou malveillant. Par rapport à l'analyse de conformité, qui fournit un résultat pour chaque paquet reçu, 1 ' analyse de non-conformité traite un ensemble de paquets non-conformes pendant une période plus longue .
Le dispositif DD comprend en outre une ou plusieurs unités de traitement UT qui sont définies chacune comme un ensemble de ressources matérielles du dispositif DD, telles qu'un processeur, une mémoire et un bus de communication, qui sont dédiées au traitement des paquets reçus. Les unités de traitement sont supposées indépendantes les unes des autres, c'est-à-dire que le traitement d'un paquet par une unité de traitement UT n'a pas d'influence sur les ressources dont disposent les autres unités de traitement. Par exemple, une unité de traitement est dédiée à l'exécution de la fonction fAC •
Le nombre d'unités de traitement dépend de 1 ' implémentation du dispositif DD et de plusieurs critères tels que l'architecture matérielle du dispositif comprenant un ou plusieurs processeurs, le débit maximal des paquets à traiter, le service considéré et un nombre de règles à appliquer par différentes fonctions de traitement.
Les modules du système THN coopèrent avec un système de traitements secondaires TS du dispositif de détection DD incluant un module de gestion des traitements GES, un module de corrélation COR et un module d'apprentissage d'informations de caractérisation du type d'entité APP.
Le module de gestion des traitements GES régule des temps de traitement relatifs à chacun des modules du dispositif de détection DD notamment en fonction des ressources de ce dernier.
Le module de corrélation COR établit une corrélation entre des premiers paquets émis depuis le réseau externe RE vers le réseau interne RI, ou inversement, et des deuxièmes paquets émis depuis le réseau interne RI vers le réseau externe RE, ou inversement, en réponse aux premiers paquets, au moyen d'une fonction de corrélation fcOR- Cette corrélation est appliquée seulement aux paquets pour lesquels une réponse d'une entité du réseau interne ou externe est nécessaire à des traitements du dispositif DD. Le module de corrélation COR est sollicité indifféremment et indépendamment par le module d'analyse de conformité AC, le module de caractérisation du type d'entité CTE, et le module d'analyse de non-conformité ANC. La fonction de corrélation fcOR est exécutée de manière asynchrone par rapport aux autres fonctions de traitement des modules du dispositif DD. Le module d'apprentissage d'informations de caractérisation du type d'entité APP coopère avec le module de collecte COL. Le module APP agrège des attributs ATT de type et de sous-type d'entité collectés par le module COL au moyen d'une fonction d'apprentissage fAPPr dès lors qu'un nombre suffisant d'attributs est collecté pour un nombre suffisant d'entités. Le module APP fournit des attributs de caractérisation pour différents types et sous-types d'entités qui sont utilisés par le module de caractérisation du type d'entité CTE.
Les modules du dispositif de détection DD ont des temps impartis d'exécution et de fourniture de résultats, qui peuvent être de type court-terme, moyen-terme ou long-terme. Le module d'analyse de conformité AC et le module de corrélation COR ont des temps de réponse de type court-terme, puisque le module AC fournit un résultat après l'analyse de chaque paquet reçu, et le module COR établit un lien entre des requêtes et des réponses qui sont généralement proches dans le temps. Le module de caractérisation du type d'entité CTE et le module d'analyse de non-conformité ANC ont des temps de réponse de type moyen-terme puisqu'ils requièrent un ensemble de paquets avant de fournir un résultat. Le module de collecte COL et le module d'apprentissage APP ont des temps de réponse de type long-terme puisqu'ils requièrent un grand nombre de paquets relatifs à un ensemble représentatif d'entités avant de pouvoir consolider des attributs de caractérisation.
Les modules du système de traitement de haut niveau THN et du système de traitements secondaires TS exécutent des traitements dits de haut niveau. Lorsque le dispositif DD est placé en coupure, ces traitements engendrent des délais de transfert des paquets reçus et traités. Afin que ces délais restent dans des limites acceptables pour ne pas dégrader la qualité du service, le dispositif DD adapte dynamiquement ces traitements de haut niveau au contexte dudit service en fonction notamment de l'origine du paquet, du type de l'entité, d'un niveau de conformité de l'entité et des ressources du dispositif DD. Par exemple, l'analyse de conformité invoque un ensemble de règles qui dépend du type d'entité considérée pour chaque paquet traité.
Afin d'optimiser l'utilisation des ressources du dispositif, des traitements sont exécutés en fonction d'un niveau d'analyse du paquet reçu et de l'entité associée qui n'est pas constant. Par exemple, un niveau de conformité de l'entité est utilisé pour adapter les traitements exécutés par la fonction d'analyse de conformité fAC . Plus les ressources du dispositif DD diminuent, plus ce dernier réduit la quantité de traitements exécutés par entité ou par paquet reçu. Cette adaptation dynamique des ressources du dispositif DD est faite en fonction de l'entité, en s 'assurant que des règles de contrôle dites critiques soient appliquées pour chaque paquet traité quel que soit le niveau de conformité de l'entité. Une limitation de ressources en fonction de l'entité évite par exemple une situation où un comportement malveillant abusif d'une entité empêche l'application de règles de contrôles pour d'autres entités.
Cette adaptation dynamique du dispositif DD évite une vérification systématique de mêmes règles pour toutes les entités et pour tous les paquets reçus, qui est très consommatrice de ressources et qui limite le degré d'analyse des paquets. Ainsi, une entité dont le comportement vérifie un gabarit prédéfini subira un minimum de contrôles, tandis qu'une entité dont le comportement est éloigné du gabarit prédéfini subira de plus en plus de contrôles au fur et à mesure que le niveau de conformité de l'entité diminue. Cette adaptation dynamique garantit au dispositif DD de faire des contrôles suffisamment fins sur des entités présentant un comportant suspect ou anormal, tout en économisant des ressources de traitement grâce à des contrôles critiques basés sur un nombre minimal de règles appliquées sur les entités conformes au gabarit. Toutefois, quel que soit le niveau de conformité de l'entité, les contrôles critiques sont toujours réalisés en priorité pour la sécurité du réseau interne et d'autres contrôles plus fins sont conditionnels aux ressources du système, au type de l'entité et au niveau de conformité de cette dernière.
En référence à la figure 3, les informations manipulées par le dispositif de détection DD sont organisées et mémorisées dans un ensemble de différentes bases de données comprenant une base de caractérisation de type d'entité BCTE, une base d'identification d'entité BIE, une base de contexte d'entité BCE et une base de règles BR. Cette organisation est de nature logique et n'est pas limitée à une implémentation particulière. Les bases de données BCTE, BIE, BCE et BR sont liées au dispositif de détection DD, c'est-à-dire elles sont soit intégrées dans le dispositif de détection DD, soit incorporées dans un ou plusieurs serveurs de gestion de base de données et reliées au dispositif de détection par une liaison locale ou distante .
Les bases BCTE, BIE et BCE sont en lecture et en écriture, tandis que la base BR est seulement en lecture, par exemple pour des fonctions de traitement de traitement de haut niveau.
La base de caractérisation de type d'entité BCTE contient des attributs ATT qui sont des informations descriptives sur différents types et sous-types d'entités des réseaux RI et RE définis dans le dispositif DD et qui permettent au module de caractérisation CTE de déterminer le type et éventuellement un ou des sous-types d'une entité en fonction des paquets reçus de l'entité. Une entité est définie par un type, et éventuellement par un ou plusieurs sous-types de manière hiérarchique. Par défaut, un sous-type d'entité hérite de manière récursive des attributs du sous-type supérieur jusqu'au type d'entité racine. Par contre, un attribut du type d'entité peut être redéfini dans l'un quelconque des sous-types d'entité. Les attributs mémorisés dans la base BCTE sont lus par la fonction de caractérisation du type d'entité fcTE- Ces attributs peuvent être écrits de manière dynamique par la fonction d'apprentissage fAPP du module APP, ou par un administrateur du dispositif DD au moyen d'un plan de gestion, en particulier lors de l'initialisation du dispositif DD pendant laquelle certains attributs sont configurés par défaut. La base d'identification d'entité BIE contient des informations ou clés primaires permettant à la fonction de récupération de type d'entité fREC du module REC de récupérer le type de chacune des entités émettrice et destinatrice en fonction de l'analyse de chaque paquet reçu. Les informations contenues dans la base BIE sont segmentées en deux parties. Une première partie de base comprend des informations d'index {IDX} incluant une clé primaire ou un ensemble de clés primaires identifiant une entité appartenant au réseau interne RI ou au réseau externe RE. Ces premières informations correspondent à un sous-ensemble des informations décodées par le module DEC. Une deuxième partie de base comprend des informations descriptives de chaque entité, c'est-à- dire un identificateur d'entité IE qui est unique, un type d'entité <TE>, éventuellement un ou des sous- types d'entité associés <STE> et un niveau de conformité de l'entité <NCE>. En particulier l'identificateur d'entité IE pointe sur le contexte d'entité correspondant contenu dans la base BCE. Lorsque la fonction de récupération de type d'entité fREC détecte une nouvelle entité émettrice dans l'un des réseaux RI et RE, cette fonction crée dans la base un nouvel identificateur d'entité auquel sont associées les informations d'index {IDX} correspondant. Par ailleurs, la fonction de caractérisation fcτ∑ du module CTE actualise le type d'entité <TE> et éventuellement un ou des sous-types d'entité associés <STE> dès lors que la fonction fcτ∑ a déterminé le type ou le sous-type d'une entité précédemment indéfinie.
La base de contexte d'entité BCE contient, pour un identificateur d'entité IE donné, mémorisé dans la base d'identification d'entité BIE, un contexte d'entité {IE} associé à cet identificateur. Le contexte d'une entité désigne un ensemble d'informations propres à l'entité. Comme il existe une bijection entre l'identificateur d'entité IE et le contexte d'entité, la notation {IE} désignera par la suite indifféremment le contexte d'entité ou bien l'agrégation de l'identificateur d'entité et du contexte de l'entité. La base BCE contient, pour chaque entité, des informations de conformité, de caractérisation et d'historique. Les informations de conformité indiquent le comportement observé d'une entité par les fonctions fAC et fANC des modules AC et ANC qui lisent, écrivent ou modifient ces informations. Les informations de caractérisation décrivent des caractéristiques de l'entité, et sont initialement lues et modifiées par la fonction de caractérisation fcτ∑ du module CTE, puis par la fonction de collecte fcOL du module COL. Ces informations de caractérisation sont également lues par la fonction d'apprentissage fAPP du module APP. Les informations d'historique agrègent sur le long terme différentes anomalies ou alarmes détectées par les fonctions fAo fcTEr fANC ou fAPP-
La base de règles BR décrit de manière statique des règles d'analyse de conformité, des règles de caractérisation des types d'entité, des règles de collecte d'attributs de caractérisation, des règles d'analyse de non-conformité et des règles de corrélation. La base BR contient des modules de règles composés chacun d'un ensemble de règles appelées par une fonction de traitement particulière, telles que des règles d'analyse de conformité {RAC}, des règles de caractérisation du type d'entité {RCTE}, des règles de collecte d'attributs de caractérisation {RCOL}, des règles d'analyse de non- conformité {RANC} et des règles de corrélation {RCOR} . Chaque règle définit une action ou une vérification en fonction de paramètres d'entrée propres à la règle et retourne une ou plusieurs valeurs vers la fonction de traitement appelante, c'est-à-dire au module exécutant cette fonction appelante. Pour chaque combinaison possible de paramètres de sélection, propres à chacune des fonctions fAO fcTE/- f∞L et fANO la base BR pointe respectivement sur l'ensemble {RAC}, {RCTE}, {RCOL} et {RANC} de règles à invoquer pour cette combinaison. L'ensemble des combinaisons possibles des paramètres d'entrée de ces fonctions est discret et borné .
Les règles d'analyse de conformité sont invoquées par le module AC et consistent à vérifier qu'un paquet est conforme à un certain nombre de règles de sécurité, en particulier les règles identifiées comme critiques relativement à l'application ou des protocoles supervisés. Chaque règle retourne un résultat du type "OK" si le paquet est conforme aux règles invoquées, "NOK" si le paquet est non-conforme aux règles invoquées, ou "IND" si le résultat est indéfini, c'est-à-dire si le module AC ne peut statuer sur la conformité du paquet. Ces règles d'analyse de conformité sont classées en deux catégories : les règles "critiques" et les règles "non-critiques" .
Les règles de caractérisation du type d'entité sont invoquées par le module CTE et évaluent une ressemblance entre une entité dont le type est indéfini et les différents types et sous-types d'entité définis dans le dispositif DD. Pour chaque paquet auquel elles sont appliquées, ces règles comparent certaines informations extraites du paquet aux attributs ATT définis dans la base de caractérisation de type d'entité BCTE et font évoluer des indicateurs de vraisemblance pour les différents types et sous-types d'entité possibles.
Les règles de collecte d'attributs de caractérisation sont invoquées par le module COL et définissent des paramètres à ajouter ou modifier, en fonction des paquets reçus, parmi les attributs de caractérisation associés à l'entité et stockés dans son contexte {IE}. Les règles d'analyse de non-conformité sont invoquées par le module ANC et sont appliquées aux paquets détectés non-conformes par la fonction fAC • Ces règles visent à déterminer plus finement un type ou une logique d'attaque sur une période de temps moyen-terme.
En référence aux figures 4 et 5, le procédé de détection d'anomalie selon l'invention comprend des étapes El à EIl exécutées dans le dispositif de détection DD.
On suppose que les entités de service ES du réseau RI ne sont pas malveillantes et le dispositif DD réalise une analyse de conformité seulement sur le trafic émis par les entités clientes EC du réseau RE vers les entités de service ES du réseau RI. Par symétrie, les étapes du procédé peuvent être exécutées de manière similaire pour une analyse du trafic émis par les entités de service ES vers les entités clientes EC. Le dispositif DD intercepte et reçoit des paquets PAQ transmis dans des messages via la ligne de transmission LT entre les réseaux RI et RE.
A l'étape El, le module de décodage DEC extrait un ensemble d'informations {IAD} à décoder pour chaque paquet reçu PAQ, généralement structurées sous forme de champs dans le paquet. Par exemple, le paquet reçu contient des champs d'information relatifs au protocole supporté par le routage, tel que le protocole IP, au protocole supporté par le transport, tel que le protocole UDP ("User Datagram Protocol" en anglais), et aux protocoles supportés par l'application relative au service offert par le réseau RI . Le module DEC traite tous les paquets reçus, de manière adaptée au débit supporté par la ligne de transmission, de sorte que le nombre d'informations à décoder est relativement faible. Selon les capacités du dispositif DD, les informations à décoder peuvent dépendre du type de paquet reçu, par exemple un paquet relatif à une requête ou une réponse. Si le dispositif DD dispose de peu de capacités, les informations à décoder {IAD} ont avantage à être identiques quel que soit le type de paquet reçu. Dans le cas où le service contrôlé par le dispositif DD comporte plusieurs protocoles applicatifs ou de transport, une information extraite par le module DEC est le protocole associé au paquet reçu, appelé par la suite protocole de paquet <P> et pouvant désigner indifféremment un protocole applicatif ou de transport. Comme chaque protocole est généralement structuré en plusieurs types de messages, une autre information extraite par le module DEC est le type de message, pour un protocole donné, associé à chaque paquet reçu, appelé par la suite type de message reçu <TM>.
De manière générale, d'autres informations extraites par le module de décodage sont définies en fonction du service contrôlé. Par exemple, l'ensemble d'informations extraites {IAD} comprend le protocole de paquet <P> et le type de message reçu <TM>.
Si le décodage du paquet reçu échoue, un drapeau <NDEC> indique le niveau de décodage qui a pu être atteint parmi les valeurs ordonnées de manière croissante correspondant aux couches du modèle OSI (Open Systems Interconnection" en anglais) : nul, réseau, transport ou application. Un niveau de décodage est considéré atteint si toutes les informations de l'ensemble {IAD} relatives à ce niveau ont pu être décodées. Par exemple, si l'ensemble {IAD} contient l'adresse IP de source et l'adresse IP de destination du paquet reçu, et que seule l'adresse IP de source a pu être décodée, alors le niveau de décodage réseau n'est pas atteint et le drapeau <NDEC> est positionné à la valeur "nul". Par conséquent, si un niveau de décodage n'a pu être atteint, les niveaux suivants n'ont également pas pu être atteints. Par convention, un paquet décodé complètement par rapport à l'ensemble d'informations {IAD} est associé à un drapeau <NDEC> ayant une valeur "total", qui est équivalent au niveau "application" .
Le module DEC fournit un ensemble d'informations décodées {ID}, contenant par exemple toute information décodée autre que le protocole de paquet <P>, le type de message reçu <TM> et le drapeau <NDEC> . Les informations décodées contenues dans l'ensemble {ID} peuvent être la valeur d'un champ du paquet, le nombre d'occurrences d'un champ du paquet, ou la longueur d'un champ du paquet, ou bien toute combinaison de ces trois types d'informations précitées .
Le module de décodage DEC fournit les informations {ID}, <P>, <TM> et <NDEC>, ainsi que le paquet reçu PAQ au module de filtrage FIL.
A l'étape optionnelle E2, le module de filtrage
FIL reçoit les informations {ID}, <P>, <TM> et
<NDEC>, ainsi que le paquet reçu et applique le cas échéant des règles de filtrage statiques et/ou dynamiques dont les critères de filtrage portent sur les informations {ID}, <P>, <TM> ou <NDEC> .
Les règles de filtrage statiques sont configurées et activées via un plan de gestion supervisé par un administrateur, par exemple dans le cadre d'une procédure d'interception légale. Les règles de filtrage dynamiques sont configurées et activées par les fonctions de traitement haut niveau.
Le module de filtrage FIL applique des règles de filtrage dont les critères de filtrage portent sur les informations {ID}, <P>, <TM> ou <NDEC> extraites par le module de décodage DEC, et n'analyse pas l'ensemble du paquet reçu, de manière à optimiser l'utilisation des ressources du dispositif DD. En variante, le module FIL applique des règles de filtrage statiques à d'autres informations contenues dans le paquet reçu.
Les règles de filtrage sont appliquées en fonction du drapeau <NDEC> . Si le paquet reçu n'a pas été entièrement décodé, c'est-à-dire que le drapeau <NDEC> est différent de "total", des règles de filtrage sont appliquées en fonction du niveau de décodage atteint. Par exemple, si le niveau atteint est "transport", seules des règles de filtrage relatives aux niveaux "réseau" et "transport" sont appliquées, tandis que les règles de filtrage relatives au niveau "application" ne sont pas appliquées .
Une règle de filtrage dynamique, contrairement à une règle de filtrage statique, est associée à un contexte géré par une fonction de traitement haut niveau qui a créé la règle dynamique. Lorsque ce contexte disparaît, la règle dynamique associée est supprimée par le module FIL. Afin d'éviter des attaques par saturation de ressources, le module FIL peut refuser la création d'une nouvelle règle de filtrage dynamique dès lors qu'un seuil de nombre de règles est atteint. Par ailleurs, le module de filtrage peut supprimer une règle de filtrage dynamique qui a été inopérante pendant une durée prédéterminée, c'est-à-dire qu'aucun paquet reçu pendant la durée prédéterminée considérée n'a satisfait des critères d'utilisation de la règle de filtrage dynamique. Chaque règle de filtrage appliquée aux paquets reçus peut exécuter les actions suivantes : suppression d'un paquet reçu, par exemple lorsque le dispositif est en coupure pour éviter les attaques de type déni de service en provenance d'une source donnée; comptage des paquets reçus, par exemple pour informer le module de gestion des traitements GES du volume de données en provenance d'une entité donnée; et - marquage d'un paquet reçu, par exemple pour appliquer à ce dernier une fonction de traitement spécifique telle que l'enregistrement de flux dans le cas d'une procédure d'interception légale. Le module FIL filtre ainsi les paquets reçus et fournit ceux qui n'ont pas été supprimés au module de récupération de type d'entité REC, avec les informations {ID}, <P>, <TM> et <NDEC> . Par souci de simplification dans la suite de la description, les informations <P>, <TM> et <NDEC> sont supposées incluses dans l'ensemble {ID}.
A l'étape E3, le module de récupération de type d'entité REC reçoit les informations {ID} et le paquet reçu correspondant et applique à ces derniers la fonction de récupération de type d'entité fREC afin de déterminer, pour chaque paquet reçu, l'entité émettrice et l'entité destinatrice du paquet reçu.
La fonction de récupération de type d'entité fREC retourne les informations suivantes qui sont un type d'entité <TE>, un sous-type d'entité <STEm,τE>/- avec 1 ≤ m ≤ M, et un ensemble {IE} d'un identificateur et d'un contexte associés à l'entité.
Le type d'entité <TE> prend la valeur "inconnu" = "NC", ou "indéfini" = "IND" ou bien est l'un parmi plusieurs types prédéfinis par l'administrateur du dispositif. Des types prédéfinis sont par exemple <TE> = "terminal mobile", "serveur", ou "terminal fixe". Le cas "inconnu" = "NC" ne peut s'appliquer qu'à une entité destinatrice.
Le sous-type d'entité <STEm,τE> caractérise plus précisément une entité d'un type donné <TE>. Par exemple, si <TE> = "terminal mobile", deux premiers sous-types peuvent être <STE]_,TE> = "mobile GSM" et <STE2,TE> = "mobile UMTS". Par ailleurs, pour le sous-type <STE2,TE> = "mobile UMTS", il est possible de définir deux deuxièmes sous-types <STE]_,2,TE> = "téléphone mobile UMTS" et <STE2,2,TE> = "PDA mobile UMTS". De manière récursive, il est possible de définir des sous-types de sous-type d'entité pour caractériser plus précisément une entité d'un type donné TE.
Chaque entité du réseau RI ou RE dispose d'un identificateur unique et d'un contexte associé, formant l'ensemble d'informations {IE} propre à cette entité .
La fonction de récupération de type d'entité fREC exécute une recherche de correspondance à une sous-étape E31 et une récupération de contexte à une sous-étape E32. A la sous-étape E31, le module de récupération REC lance une recherche de correspondance basée sur un ensemble d'informations {IDX} qui constitue un sous-ensemble total ou partiel de l'ensemble des informations {ID} décodées par le module DEC. Par exemple, l'ensemble d'informations {IDX} est fixe, c'est-à-dire la recherche de correspondance porte toujours sur des mêmes paramètres. En variante, si les ressources de traitement du dispositif DD sont suffisantes, l'ensemble d'informations {IDX} peut être variable, c'est-à-dire la recherche de correspondance porte sur des paramètres différents selon le type de protocole <P> ou le type de message <TM>. La recherche de correspondance consiste à comparer l'ensemble {IDX} à des informations ou clés primaires mémorisées dans la base d'identification d'entité BIE.
Si la base BIE ne contient pas d'informations coïncidant avec l'ensemble {IDX}, la recherche de correspondance est un échec et la sous-étape E32 de récupération de contexte n'est pas exécutée.
Si la base BIE contient des informations coïncidant avec l'ensemble {IDX}, la recherche de correspondance est un succès et la sous-étape E32 de récupération du contexte est exécutée.
Par exemple si l'ensemble {IDX} est constitué d'une adresse réseau et d'un port de transport et la base BIE contient les informations suivantes : {1.2.3.4 ; 5060}, {1.2.3.4 ; 5100}, {1.2.3.6 ; 5200}, alors la recherche de correspondance est un succès pour un paquet reçu tel que {IDX} = {1.2.3.6 ; 5200}, et est un échec pour un paquet reçu tel que {IDX} = {1.2.3.4 ; 5200}. La recherche de correspondance peut être un échec selon les deux cas suivants. L'échec de la recherche de correspondance portant sur l'entité destinatrice signifie que le paquet reçu est destiné à une entité qui n'est pas connue du dispositif DD, et la fonction ÎREC retourne les informations <TE> = "NC", <STE> = "IND" et {IE} = "IND". L ' échec de la recherche de correspondance portant sur l'entité émettrice signifie que le paquet reçu est le premier paquet en provenance d'une nouvelle entité, et la fonction fREC crée alors un nouvel ensemble {IE} d'identificateur et de contexte pour cette entité dans les bases BIE et BCE, et retourne les informations associées <TE> = "IND" et <STE> = "IND". A la sous-étape E32, exécutée si la recherche de correspondance à la sous-étape E31 est un succès, le module de récupération REC lit dans la base d'identification d'entité BIE l'identificateur correspondant aux informations coïncidant avec l'ensemble {IDX}. Puis le module REC récupère le contexte associé à cet identificateur dans la base de contexte d'entité BCE, en notant {IE} l'ensemble constitué de l'identificateur et du contexte associé.
Le module REC récupère ainsi les informations <TE>, <STE> et {IE} qui sont disponibles par la suite pour des fonctions de traitement haut niveau, à la fois par rapport à l'entité émettrice et à l'entité destinatrice du paquet reçu. Par souci de simplification dans la suite de la description, les informations <TE>, <STE> sont supposées incluses dans l'ensemble {IE}.
L'information de type d'entité <TE> permet à des modules du système THN, tels que les modules d'analyse de conformité AC et de collecte COL, d'adapter des traitements au type d'entité considéré. Lorsqu'un paquet reçu n'a pu être totalement décodé par le module de décodage DEC, c'est-à-dire lorsque le drapeau associé <NDEC> est différent de
"total", le module REC effectue des actions selon deux cas .
Dans un premier cas, si les informations de l'ensemble {IDX} font partie des informations qui ont pu être décodées, alors la fonction ÎREC est exécutée selon les principes décrits ci-dessus. Dans un deuxième cas, si certaines informations de l'ensemble {IDX} n'ont pu être décodées, alors la fonction ÎREC n'est pas exécutée selon les principes décrits ci-dessus et effectue un marquage spécifique au paquet reçu en assignant une valeur "IND" aux informations <TE> et {IE}, indiquant aux fonctions en aval que la récupération du type d'entité a échoué.
Le module de récupération REC fournit l'ensemble {IE}, ainsi que le paquet reçu PAQ au module de temporisation TEM, en complément de l'ensemble {ID} fourni par le module de décodage DEC. Par ailleurs le module REC indique si le paquet est transmis du réseau RE vers RI ou inversement.
A l'étape E4, le module de temporisation TEM mémorise les ensembles {IE}, {ID} et le paquet reçu
PAQ en file d'attente dans une mémoire temporaire. Le module TEM coopère avec le module de gestion GES afin qu'une fonction de gestion fcεs détermine un temps de traitement <TT> à allouer à des fonctions des modules du système THN en fonction de caractéristiques de l'entité émettrice du paquet reçu.
La fonction de gestion des traitements fait partie des fonctions de traitement haut niveau. Plus précisément, cette fonction intervient à l'interface entre les modules du système TBN qui opèrent au débit de la ligne de transmission et les modules du système THN qui effectuent des opérations beaucoup plus longues, engendrant un délai et/ou de la gigue dans le traitement des paquets reçus. La fonction de gestion fcεs prend en entrée les différents paramètres suivants : le paquet reçu et les informations {ID} et <NDEC> fournies par le module de décodage DEC; le sens de transmission du paquet reçu, par exemple du réseau RE vers le réseau RI, fourni par le module de récupération de type d'entité REC; l'ensemble {IE} contenant l'identificateur et le contexte associés à l'entité émettrice, fourni par le module REC, cet ensemble {IE} pouvant contenir outre les informations <TE> et <STE> une information <NCE> désignant un niveau de conformité de l'entité émettrice; une connaissance des unités de traitements UT du dispositif DD et des fonctions de traitement haut niveau qui sont rattachées à ces unités; pour chaque unité de traitement, un niveau de remplissage de la file d'attente FIFO(UT) et des ressources disponibles CPU(UT); et - pour chaque unité de traitement, une priorité relative pFj (UT) de la fonction Fj au sein de l'unité de traitement UT, avec 1 ≤ j ≤ J et J étant le nombre de fonctions rattachées à l'unité de traitement. Par exemple, une unité de traitement peut inclure les fonctions de collecte fcoL et de caractérisation du type d'entité fcτ∑-
La fonction de gestion fcεs régule des temps de traitement relatifs à chacun des modules du dispositif de détection DD, pour chaque unité de traitement indépendamment des autres unités de traitement, à intervalle régulier et de manière atemporelle selon des sous-étapes de détermination du temps moyen de traitement E41, de détermination du temps de référence par fonction E42, et d'ajustement du temps de référence par fonction E43.
A la sous-étape E41, le module de gestion GES détermine un temps moyen de traitement par paquet <Tm> à allouer à une unité UT en fonction de la charge CPU(UT) de l'unité UT : <Tm> = fl (CPU(UT)), avec
CPU(UT) qui est un nombre compris entre 0 et 1, où 0 correspond à la charge la plus faible, et fl est une fonction qui prend des valeurs entre 0 et 1 et fournit un résultat également compris entre 0 et 1. Dans le cas le plus simple, fl est une fonction linéaire d'une inconnue x, définie par exemple par f1 (x) = 0,1 + 0,9 x (1 - x). La fonction fl fournit ainsi un résultat <Tm> proche de 0,1 lorsque l'unité UT est saturée, et un résultat <Tm> proche de 1 lorsque l'unité UT est très faiblement chargée .
Optionnellement , le module GES ajuste le temps moyen <Tm> au nombre de paquets en attente pour l'unité de traitement UT en un temps moyen ajusté <Tma>, c'est-à-dire au niveau de remplissage de la file d'attente FIFO(UT) en entrée de l'unité UT : <Tma> = f2 (<Tm>, FIFO(UT)), avec FIFO(UT) est un nombre compris entre 0 et 1, où 0 est par convention le niveau de remplissage le plus faible de la file d'attente, et f2 est une fonction qui prend des valeurs entre 0 et 1 pour les paramètres <Tm> et FIFO(UT) et fournit un résultat également compris entre 0 et 1. Par exemple, la fonction f2 est définie de la manière suivante : f2 (<Tm>, FIFO(UT)) = min (<Tm> x (1 -
FIFO(UT)), 0,1). La fonction f2 fournit ainsi un résultat <Tma> proche de <Tm> lorsque la file d'attente est quasiment vide, et un résultat <Tma> proche de 0,1 lorsque la file d'attente est quasiment pleine .
Par conséquent, le module GES évite une saturation globale du dispositif DD, pouvant entraîner par exemple des durées de traitement inacceptables ou une impossibilité de filtrer des paquets malicieux.
La sous-étape E41 est exécutée à intervalles de temps réguliers par le module GES afin de mettre à jour le temps moyen <Tm> et le cas échéant le temps moyen ajusté <Tma> en fonction des variations de la charge du dispositif ou du niveau de remplissage des files d'attente.
A la sous-étape E42, le module de gestion GES détermine un temps de référence <TmFj> pour chaque fonction Fj rattachée à l'unité de traitement considérée, avec 1 ≤ j ≤ J et J étant le nombre de fonctions rattachées à l'unité de traitement. Le temps de référence <TmFj> d'une fonction Fj est déterminé en fonction du temps moyen de traitement <Tm> ou <Tma> et de la priorité relative <pFj> de cette fonction au sein de l'unité de traitement UT, la priorité relative <pFj> étant fixée pour une implémentation donnée du dispositif DD. Le temps de référence <TmFj> est déterminé en outre en fonction d'un nombre de paquets <npFj> destinés à la fonction Fj. Ce nombre de paquets <npFj> est par exemple déterminé par le module de récupération d'entité REC qui, en fonction du type de l'entité et du sens du paquet, en déduit les fonctions traversées et comptabilise le nombre de paquets destinés à chacune de ces fonctions.. Le temps de référence <TmFj> est par exemple déterminé selon la relation suivante :
J J <Tm> = (^ <npFj>.<TmFj>) / ^ <npFj> (1).
D=I D=I
Le temps de référence <TmFj> peut être écrit comme le produit d'un temps unitaire TU pour toutes les fonctions et de la priorité relative <pFj> : <TmFj> = TU.<pFj> (2) . Par la combinaison des relations (1) et (2), le temps unitaire TU peut s'écrire ainsi :
J J
TU = (<Tm>. ^ <npFj>) / ^ <npFj> . <pFj> (3).
D=I D=I
Puisque les valeurs de <Tm>, <npFj> et <pFj> sont connues du module GES, ce dernier en déduit la valeur de TU selon la relation (3), puis les valeurs de <TmFj> selon la relation (2) .
Par conséquent, le module GES maintient un temps moyen de traitement par paquet Tm prédéterminé, pour une unité de traitement donnée, et répartit équitablement les temps de traitement par fonction d'une unité de traitement, selon la priorité relative de chaque fonction au sein de l'unité de traitement, et du nombre de paquets destinés à cette fonction.
Par exemple, une unité de traitement exécute de manière répartie quatre fonctions d'analyse de conformité relatives à la fonction f^c du module AC de la manière suivante : fonction Fl pour des paquets du réseau RE vers le réseau RI dont le type d'entité est défini, avec une priorité relative <pFl> = 0,8; fonction F2 pour des paquets du réseau RE vers le réseau RI dont le type d'entité est indéfini, avec une priorité relative <pF2> = 1; fonction F3 pour des paquets du réseau RI vers le réseau RE dont le type d'entité est défini, avec une priorité relative <pF3> = 0,4; et fonction F4 pour des paquets du réseau RI vers le réseau RE dont le type d'entité est non- défini, avec une priorité relative <pF4> = 0,6. Si, sur une période d'itération donnée de la fonction fGES/- Ie temps moyen de traitement de l'unité de traitement vaut <Tm> = 0,4 et la file d'attente contient respectivement <npFl> = 600, <npF2> = 500, <npF3> = 200 et <npF4> = 400 paquets pour les fonctions Fl, F2, F3 et F4, alors le temps unitaire vaut TU = 0,52 et les temps de référence par fonction valent respectivement <TmFl> = 0,41, <TmF2> = 0,52, <TmF3> = 0,20 et <TmF4> = 0,31 pour les fonctions Fl, F2, F3 et F4. En corollaire, s'il n'existe qu'une seule fonction Fl pour l'unité de traitement considérée, alors <TmFl> = <Tm>, ce qui revient à court-circuiter la sous-étape E42.
La sous-étape E42 est exécutée à intervalles de temps réguliers par le module GES afin de mettre à jour les valeurs <TmFj> en fonction des variations de <Tm> ou <Tma> et du nombre de paquets <npFj> destinés à chacune des fonctions au sein de l'unité de traitement .
A la sous-étape E43, le module de gestion GES ajuste le temps de référence par fonction <TmFj> en fonction du contexte de l'entité relative au paquet reçu, et notamment d'un niveau de conformité <NCE> de
1 ' entité .
Par exemple, pour une fonction Fj utilisée par l'unité de traitement, le module de gestion GES compte un nombre de paquets <npFj,k> dans la file d'attente qui est destiné à la fonction Fj et dont l'entité émettrice a un niveau de conformité <NCE> égal à k, l ≤ k ≤ K et K étant le nombre des différents niveaux de conformité possibles pour les différentes entités émettrices. Par construction, la relation suivante est vérifiée :
K
<npFj> = ^ <npFj,k> (4). k = l
Le temps de référence par fonction <TmFj> est ajusté en un temps de référence ajusté <TmFj,k>, qui est un temps moyen de traitement des paquets de l'entité dont le niveau de conformité est égal à k, en fonction d'une priorité relative <pFj,k> de la fonction Fj pour des entités de niveau de conformité égal à k. Le temps de référence ajusté <TmFj,k> est par exemple déterminé selon la relation (5) suivante :
K K
<TmFj> = ( ^ <npFj,k> x <TmFj,k>) / ^ <npFj,k>. k=l k=l
Le temps de référence ajusté <TmFj,k> pour un niveau de conformité égal à k peut être écrit comme le produit d'un temps de référence ajusté moyen TRMA de la fonction Fj pour tous les niveaux de conformité et de la priorité relative <pFj,k> pour un niveau de conformité égal à k : <TmFj,k> = TRMA. <pFj , k> (6).
Par la combinaison des deux relations précédentes, le temps de référence ajusté moyen TRMA peut s'écrire ainsi selon la relation (7) suivante:
K K
TRMA = (<TmFj>. ^ <npFj,k>) / ^ <npFj , k> . <pFj , k> . k=l k=l Puisque les valeurs de <TmFj>, <npFj,k> et <pFj,k> sont connues du module GES, ce dernier en déduit la valeur de TRMA selon la relation (7), puis de <TmFj,k> selon la relation (6) .
Par exemple, une fonction Fj ayant un temps de référence <TmFj> égal à 0,41 et un nombre de paquets <npFj> en file d'attente égal à 600, a respectivement <npFj,l> = 100, <npFj,2> = 200, <npFj,3> = 250 et <npFj,4> = 50 paquets en file d'attente <npFj,k> et des priorités relatives valant respectivement <pFj,l> = 1, <pFj,2> = 0,8, <pFj,3> = 0,6 et <pFj,4> = 0,4 pour des niveaux de conformité respectivement égaux à 1, 2, 3 et 4. Alors le temps de référence ajusté moyen TRMA vaut 0,57 et la fonction Fj a des temps de référence ajustés <TmFj,l> = 0,57, <TmFj,2> = 0,46, <TmFj,3> = 0,34 et <TmFj,4> = 0,23 pour des niveaux de conformité respectivement égaux à 1, 2, 3 et 4.
A l'issue des sous-étapes E41 à 43, le module de gestion GES détermine un temps de traitement <TT>, relatif ou absolu, alloué à une fonction utilisé par une unité de traitement UT traitant le paquet reçu
PAQ.
Si l'unité UT ne comporte qu'une seule fonction, alors le temps de traitement <TT> est égal au temps moyen de traitement <Tm>, ou le cas échéant au temps moyen ajusté <Tma>, déterminés à la sous-étape E41.
Si l'unité UT comporte plusieurs fonctions, alors le temps de traitement <TT> d'un paquet destiné à une fonction Fj est égal au temps de référence <TmFj> de la fonction Fj déterminé à la sous-étape
E42.
Indépendamment du nombre de fonctions utilisées par l'unité UT, le module GES adapte éventuellement le temps de traitement <TT> au niveau de conformité <NCE> de l'entité, et le temps de traitement <TT> d'un paquet émis par l'entité de niveau de conformité k destiné à une fonction Fj est égal au temps de référence ajusté <TmFj,k> de la fonction Fj déterminé à la sous-étape E43. Le module GES commande alors le module de temporisation TEM de fournir les ensembles {IE} et {ID} et le paquet reçu PAQ au module d'analyse de conformité AC en allouant un temps de traitement <TT> pour le paquet reçu PAQ à la fonction d'analyse de conformité fAC • Dans la suite de la description, le temps de traitement <TT> désigne indifféremment un temps de traitement absolu, par exemple une durée de 10 millisecondes, ou un temps de traitement relatif qui est utilisé par les fonctions du système THN en amont pour ajuster le nombre de règles sélectionnées. Le temps de traitement <TT> alloué à chacune des fonctions du système THN n'est pas forcément identique, et dépend directement de 1 ' implémentation et du flux de paquets reçus. Ces différents temps de traitement sont notés <TAC>/- <TCTE>/- <TCOL> et <TANC> respectivement pour les fonctions fAO fcTEr f∞L et fANC-
A l'étape E5, le module d'analyse de conformité AC reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction d'analyse de conformité f^c afin d'analyser le paquet reçu en fonction de règles de conformité mémorisées dans la base de règles BR.
La fonction fAC prend également en entrée les différents paramètres suivants : des ensembles {IE} contenant l'identificateur et le contexte respectivement associés aux entités émettrice et destinatrice, contenant notamment les informations <TE> et <STE>; et le temps de traitement <TT> alloué par la fonction de gestion fGES- Par la suite, on note {IE}E et {IE}D les ensembles contenant l'identificateur et le contexte respectivement associés aux entités émettrice et destinatrice, et ces ensembles sont appelés contexte d'émission {IE}E et contexte de destination {IE}D- Par extension, on note respectivement <TE>E, <STEm, TE>E et <NCE>E le type, le sous-type et le niveau de conformité de l'entité émettrice, et respectivement <TE>D et <STEm, TE>D le type et le sous-type de l'entité destinatrice. Par ailleurs, le temps de traitement <TT>, relatif ou absolu, alloué à la fonction f^c est notée <TAC>-
Le module AC lit le type d'entité <TE>E de l'entité émettrice. Si le type d'entité <TE>E est indéfini (<TE>E = IND), alors le module AC exécute une analyse de conformité pour entité indéfinie à l'étape E6. Si le type d'entité <TE>E est défini, alors le module AC exécute une analyse de conformité pour entité définie à l'étape E8. Par conséquent, le module AC adapte des contrôles de conformité sur le paquet reçu selon que l'entité émettrice est définie ou non définie. Par définition, le type d'entité
<TE>E ne peut pas prendre la valeur "inconnu" = "NC".
En variante, le module AC exécute une analyse de conformité pour entité définie à l'étape E8 seulement si le type <TE>E de l'entité émettrice sont définis.
Dans le cas contraire, l'étape E6 est exécutée.
A l'étape E6, le module d'analyse de conformité
AC sélectionne un ensemble de règles d'analyse de conformité {RAC1} mémorisées dans la base de règles BR, pour les entités de type non défini, en fonction notamment du temps de traitement de paquet <iAC>r et optionnellement du protocole de paquet <P> et du type de message reçu <TM>. Le module AC sélectionne en priorité des règles d'analyse de conformité critiques, et optionnellement des règles d'analyse de conformité non-critiques, selon un ordre de priorité de manière à ce que les règles les plus prioritaires soient appliquées au paquet reçu pendant le temps de traitement de paquet <TAC> alloué à la fonction fAC • En particulier, les règles d'analyse de conformité critiques sont prioritaires devant les règles non-critiques.
De manière générale, une règle d'analyse de conformité sélectionnée RACl est appliquée au paquet reçu PAQ, et le module AC prend une décision sur la conformité du paquet PAQ en fonction d'un résultat RESl fourni par la règle d'analyse : RESl = RACl (PAQ) . Par exemple, la règle RACl vérifie que l'entité émettrice transmet des requêtes vers un port de destination autorisé de l'entité destinatrice . A cette fin, la règle compare le port de destination contenu dans le paquet reçu PAQ de la requête courante avec une liste des ports de destination autorisés de l'entité destinatrice et mémorisé dans la base de contexte d'entité BCE.
Par convention, le résultat RESl prend la valeur OK si le paquet est conforme à la règle considérée, la valeur NOK si le paquet est non-conforme. Le résultat RESl prend la valeur IND (indéfini) si la règle n'a pu déterminer si le paquet est conforme ou non, c'est-à-dire si la règle est inapplicable au paquet. Selon l'exemple précédent, le décodage du port de destination contenu dans le paquet reçu PAQ peut être erroné et ininterprétable pour être comparé avec une liste des ports de destination autorisés. Dans ce cas, la conformité du paquet à la règle est indéterminée. Dans un autre exemple, la conformité du paquet à la règle peut être indéterminée lorsque la règle nécessite une information de caractérisation de type ou de sous-type qui n'est pas encore renseignée dans la base BCTE lorsque la règle est exécutée.
Le module d'analyse de conformité AC fournit un résultat global RESGl dépendant des résultats RESl retournés respectivement par les règles RACl.
Si au moins une règle fournit un résultat RESl égal à NOK, alors le résultat global RESGl est égal à NOK et le paquet reçu est non-conforme. Si aucune règle ne fournit de résultat RESl égal à NOK, mais au moins une règle fournit un résultat RESl égal à IND, alors le résultat global RESGl est égal à IND. Le résultat global RESGl est aussi égal à IND si au moins une règle critique sélectionnée n'a pu être appliquée au paquet pendant le temps <TAC>-
Dans tous les autres cas, c'est-à-dire si aucune règle n'a fourni un résultat égal à NOK ou à IND et si toutes les règles critiques sélectionnées ont été exécutées, alors le résultat global RESGl est égal à OK et le paquet reçu est considéré conforme.
A l'issue de l'exécution des règles, le module AC met à jour les informations de conformité relatives à l'entité émettrice considérée dans le contexte { IEJE- En complément, selon le résultat global RESGl, plusieurs actions de sortie peuvent être exécutées :
Si le résultat global RESGl est égal à NOK, le module AC exécute une étape de traitement d'anomalie EAl . Si le résultat global RESGl est égal à NOK ou à IND, le module AC enregistre optionnellement des informations d'historique dans le contexte {IE}E de l'entité émettrice. Si le résultat global RESGl est égal à OK, le module AC fournit une copie du paquet reçu PAQ et les informations associées au module de caractérisation du type d'entité CTE. Le paquet reçu PAQ, considéré comme conforme, est transmis par le dispositif DD au réseau RI.
Indépendamment du résultat global RESGl, une requête de corrélation peut être adressée au module COL afin de mettre à jour des informations dans le contexte de l'entité, en fonction de la réponse éventuelle retournée relativement au paquet analysé.
A l'étape EAl, le module d'analyse de conformité AC détecte une anomalie par exemple en fonction du résultat global RESGl relatif au paquet reçu PAQ. Le module AC peut alors émettre une alarme selon le niveau de l'anomalie observée, en particulier dans le cas où au moins une règle critique d'analyse de conformité a fourni un résultat négatif.
Si le paquet reçu représente un danger élevé pour le service, le module AC peut supprimer le paquet ou commander la suppression de ce dernier par le dispositif DD.
Par ailleurs, le module AC peut ajouter des informations d'historique au contexte d'émission {IE|E dans la base de contexte d'entité BCE.
Enfin, le module AC peut commander l'ajout d'une règle de filtrage dynamique au niveau du module FIL, relative à l'entité émettrice considérée, afin de se protéger de paquets pouvant être émis ultérieurement par cette entité. A l'étape E7, lorsque le résultat global RESGl est égal à OK, le module de caractérisation du type d'entité CTE reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction de caractérisation fcτ∑ afin de déterminer le type <TE>E de l'entité émettrice et les sous-types éventuels, à partir d'un nombre maximal NMPAQ de paquets reçus consécutivement en provenance de la même entité émettrice de type indéfini.
La fonction fcτ∑ prend également en entrée les contextes d'émission {IE}E et de destination {IE}D et un temps de traitement <TCTE> alloué par la fonction de gestion fGES- La fonction fcTE initialise des variables à une sous-étape E71, détermine des règles de caractérisation à une sous-étape E72 et exécute ces règles déterminées à une sous-étape E73.
A la sous-étape E71, pour le premier paquet reçu PAQ en provenance de l'entité émettrice, le module CTE initialise à zéro un nombre de paquets analysés <NPA> .
Le type de l'entité émettrice est supposé appartenir à un ensemble de P types d'entité possibles. Le module CTE initialise à zéro un compteur <CVTp>, avec 1 ≤ p ≤ P, indiquant la vraisemblance que le type de l'entité émettrice corresponde au type "p" d'une entité, parmi les P types d'entité possibles. Par convention, plus la valeur du compteur <CVTp> est élevée, plus la vraisemblance est forte, et inversement. Par extension, le module CTE initialise à zéro un compteur <CVTm?p>, avec 1 ≤ m ≤ M et M le nombre de sous-types de l'entité émettrice, indiquant la vraisemblance que le sous-type de l'entité émettrice corresponde au sous-type "m" du type "p" d'une entité .
Les P types d'entité possibles sont supposés suffisamment dissemblables les uns des autres, afin que l'un des compteurs <CVTp> prenne une valeur plus élevée relativement aux autres compteurs lorsque le nombre de paquets reçus et analysés augmente.
A la sous-étape E72, le module CTE sélectionne un ensemble de règles de caractérisation de type d'entité {RCTE} et/ou un sous-ensemble de règles de caractérisation de sous-type d'entité {RSCTE} parmi un ensemble de règles de caractérisation mémorisées dans la base de règles BR.
Pour optimiser les ressources du dispositif DD, le module CTE sélectionne les règles de caractérisation en fonction du temps de traitement
<TCTE> alloué par le module GES, du nombre de paquets reçus <NPA>, et d'un vecteur de vraisemblance <VV> dont les composantes sont les compteurs <CVTp> et <CVTm,p>.
De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : ({RCTE}, {RSCTE}) = fCTE (<TCTE>, <NPA>, <VV> ) .
Par construction, les paramètres de sélection <TCTE>/- <NPA> et <VV> sont ramenés à des espaces discrets et bornés, de telle sorte que les règles puissent être sélectionnées en utilisant une matrice statique ou des règles logiques simples.
Plus le temps <TCTE> est élevé, plus le nombre de règles sélectionnées pour un paquet donné est élevé, et inversement.
Plus le nombre de paquets reçus <NPA> est élevé et tend vers le nombre maximal NMPAQ, plus le cardinal de l'ensemble {RCSTE} est grand par rapport au cardinal de l'ensemble {RCTE}, signifiant que les premiers paquets servent à déterminer le type de l'entité et les paquets suivants servent à déterminer le ou les sous-types associés.
Plus l'une des composantes <CVTp> du vecteur <VV> est grande par rapport aux autres, plus il est vraisemblable que l'entité soit de type "p", ce qui se traduit par l'augmentation du nombre de règles sélectionnées relatives au type d'entité "p" et au(x) sous-type(s) associé(s). A la sous-étape E73, le module CTE exécute les règles de caractérisation sélectionnées, en privilégiant les règles de l'ensemble {RCTE} dans le respect du temps de traitement alloué <TCTE>-
Chaque règle de caractérisation porte sur des informations sélectionnées parmi les ensembles {ID}, {IE|E et {IE|D fournis par les fonctions de traitement en amont. Optionnellement , la règle de caractérisation peut porter sur des informations contenues dans le paquet reçu, hors de celles extraites par le module de décodage DEC. Chaque règle de caractérisation compare des informations sélectionnées, telles que des attributs du paquet reçu, à celles mémorisées dans la base de caractérisation de type d'entité BCTE. Par exemple, une règle de caractérisation sélectionnée RCTE compare la longueur ou la valeur d'un champ dans le paquet reçu à une longueur ou une valeur de référence contenue dans la base BCTE. Selon d'autres exemples, la règle sélectionnée RCTE compare la position d'un champ relativement à d'autres champs dans le paquet reçu par rapport à une position de référence, ou compare le nombre d'occurrences d'un champ dans le paquet reçu à un nombre maximal d ' occurrences . Suite à l'exécution de chacune des règles sélectionnées, le module CTE modifie le vecteur <VV> en incrémentant certaines composantes <CVTp> ou <CVTm,p>, et décrémentant d'autres composantes. Lorsque le nombre de paquets reçus atteint le nombre maximal NMPAQ, le module CTE vérifie si l'une des composantes <CVTp> a atteint une valeur suffisamment élevée par rapport aux autres composantes pour déterminer le type de l'entité émettrice. Si ce dernier est déterminé, alors le module CTE actualise la valeur du type <TE>E mémorisée dans la base d'identification d'entité BIE, et actualise ainsi le contexte d'émission {IE}E- Par extension, si le type de l'entité émettrice a pu être déterminé, le module CTE vérifie si l'une des composantes <CVTm,p> a atteint une valeur suffisamment élevée par rapport aux autres pour déterminer le ou les sous-types de l'entité émettrice . Par contre, si le type de l'entité émettrice n'a pu être déterminé après un nombre NMPAQ de paquets reçus, le type de l'entité reste à l'état indéfini "IND", ce qui entraîne une nouvelle phase de caractérisation de type d'entité et l'étape E7 est répétée. Optionnellement , le module CTE mémorise des informations d'historique dans le contexte de l'entité dans la base de contexte d'entité BCE.
En outre, le module CTE peut émettre une alarme à une étape EA2 si le type de l'entité émettrice n'a pu être déterminé. Le module CTE détecte alors une anomalie relative aux paquets PAQ de l'entité émettrice, signifiant par exemple que l'entité est de type inconnu et potentiellement dangereuse. A l'étape E8, si le type d'entité <TE>E est considéré comme défini par le module d'analyse de conformité AC à l'issue de l'étape E5, la fonction d'analyse de conformité fAc du module AC détermine des règles d'analyse de conformité à une sous-étape E81 et exécute ces règles déterminées à une sous- étape E82.
A la sous-étape E81, le module AC sélectionne un ensemble de règles d'analyse de conformité {RAC2} mémorisées dans la base de règles BR, en fonction notamment du niveau de conformité <NCE>E de l'entité émettrice, du temps de traitement de paquet <TAC>/- du type d'entité <TE>E de l'entité émettrice, et éventuellement du protocole de paquet <P> et du type de paquet reçu <TM>.
De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : {RAC2} = fAC (<NCE>E, <Tac>, <TE>E, <P>, <TM>).
Plus le niveau de conformité <NCE>E est faible, plus le nombre de règles sélectionnées {RAC2} est élevé. Par ailleurs, pour un niveau de conformité <NCE>E donné, plus le temps <TAc> est élevé, plus le nombre de règles sélectionnées {RAC2} est élevé. Ainsi, bien qu'une entité émettrice ait un niveau de conformité élevé pour lequel le nombre de règles sélectionnées est faible, la valeur élevée du temps de traitement de paquet alloué <TAc> permet de sélectionner un plus grand nombre de règles d'analyse de conformité. La fonction fAc adapte ainsi l'analyse de conformité au niveau de conformité de l'entité émettrice et aux ressources disponibles du dispositif de détection.
En particulier, l'ensemble de règles d'analyse de conformité {RAC2} comprend les deux types de règles suivants : des règles critiques et des règles non-critiques .
Les règles critiques d'analyse de conformité sont prioritaires par rapport aux règles non- critiques. Par ailleurs, les règles critiques servent à détecter des anomalies ou des attaques estimées critiques, c'est-à-dire dangereuses par rapport au service contrôlé.
Par exemple, pour un service de voix sur IP offert par le réseau RI supportant le protocole d'initiation de session SIP, chaque paquet reçu contient des champs "From" et "To" qui désignent respectivement des identificateurs logiques d'émission et de destination et qui sont décodés par le module de décodage DEC. Une règle critique vérifie alors que l'entité émettrice émettant un paquet qui est un message de type "INVITE" a un identificateur d'émission désigné dans le champ "From" du paquet qui est présent dans la base de contexte d'entité BCE. Par exemple, cet identificateur d'émission a été mémorisé dans la base BCE par la fonction de corrélation fcoR ayant établi une corrélation entre une requête de type "REGISTER" émise depuis l'entité émettrice et une réponse à cette requête par l'entité destinatrice, la réponse contenant cet identificateur d'émission dans un champ "To".
Dans un autre exemple, une règle critique vérifie que l'entité émettrice n'émet pas de requête interdite selon le type <TE>E de l'entité. A cette fin, la règle critique compare le type de la requête courante avec une liste de requêtes interdites associées au type <TE>E de l'entité et mémorisée dans la base BCE.
Les règles non-critiques d'analyse de conformité sont moins prioritaires que les règles critiques, et portent sur des anomalies ou des attaques qui sont supposées possibles par l'administrateur du dispositif DD, mais dont les conséquences sont moindres que celles d'une attaque critique. Par exemple, pour un service de voix sur IP supportant le protocole SIP, une règle non-critique vérifie que le paquet reçu PAQ émis par l'entité émettrice est un message de type "SIP" qui est autorisé pour l'entité émettrice selon le type et/ou au moins un sous-type de cette dernière. A cette fin, la règle non-critique compare le type de message "SIP" avec une liste de types de message associée à l'entité émettrice et mémorisée dans la base BCTE. Par exemple, cette liste a été mémorisée dans la base BCTE par la fonction d'apprentissage fAPP-
De manière plus générale, les règles critiques peuvent porter sur des attaques de type déni de service ou usurpation d'identité, tandis que les règles non-critiques peuvent porter sur des attaques de type collecte d'information.
Par ailleurs, les règles critiques, respectivement non-critiques, peuvent être ordonnées entre elles par niveau de priorité.
A la sous-étape E82, le module AC applique les règles d'analyse de conformité sélectionnées au paquet reçu.
Optionnellement , le module AC coopère avec le module de corrélation COR afin d'établir des corrélations entre des paquets reçus. Toutefois, le résultat fourni par la fonction f^c ne peut pas dépendre de règles de corrélation utilisées par le module COR puisque le module AC a besoin de donner un résultat pour chaque paquet reçu. En outre, des règles de corrélation appelées par la fonction f^c servent à actualiser des informations mémorisées dans la base BCE qui sont éventuellement utilisées ultérieurement par le module AC.
Une règle d'analyse de conformité sélectionnée RAC2 est exécutée en fonction du paquet reçu PAQ et des contextes d'émission {IE}E et de destination {IE|D, et le module AC prend une décision sur la conformité du paquet PAQ en fonction d'un résultat RES2 fourni par la règle d'analyse : RES2 = RAC2(PAQ, {IE}E, {IE}D).
Comme à l'étape E6, le résultat RES2 prend la valeur OK si le paquet est conforme à la règle considérée, la valeur NOK si le paquet est non- conforme, et la valeur IND (indéfini) si la règle n'a pu déterminer si le paquet est conforme ou non, c'est-à-dire si la règle est inapplicable au paquet.
Le résultat RES2 prend la valeur IND par exemple lorsque la règle fait référence à un attribut de type d'entité qui n'est pas encore défini lorsque la règle est exécutée.
Le module AC exécute tout ou partie des règles sélectionnées selon un ordre de priorité de manière à ce que les règles les plus prioritaires, en l'occurrence les règles critiques, soient appliquées au paquet reçu pendant le temps de traitement de paquet <TAC> alloué à la fonction fAC • En particulier, même si une règle fournit un résultat négatif, les règles suivantes sont exécutées.
Le module d'analyse de conformité AC fournit un résultat global RESG2 dépendant des résultats RES2 retournés respectivement par les règles RAC2.
Comme à l'étape E6, si au moins une règle fournit un résultat RES2 égal à NOK, alors le résultat global RESG2 est égal à NOK et le paquet reçu est non-conforme. Si aucune règle ne fournit de résultat RES2 égal à NOK, mais au moins une règle fournit un résultat RES2 égal à IND ou si au moins une règle critique sélectionnée n'a pu être appliquées au paquet pendant le temps <TΑc>/- alors le résultat global RESG2 est égal à IND. Dans tous les autres cas, c'est-à-dire si aucune règle n'a fourni un résultat égal à NOK ou à IND et si toutes les règles critiques sélectionnées ont été exécutées, alors le résultat global RESG2 est égal à OK et le paquet reçu est considéré conforme.
Dans tous les cas, le module d'analyse de conformité AC actualise éventuellement le contexte d'émission {IE}E et le niveau de conformité <NCE>E de l'entité émettrice. Plus le nombre de règles ayant donné un résultat non-conforme pour une entité émettrice est élevé, plus le niveau de conformité <NCE>E diminue, et inversement. Dans un premier exemple, le niveau de conformité diminue, respectivement augmente, lorsqu'au moins une règle fournit un résultat négatif, respectivement positif, pour un paquet reçu. Dans un deuxième exemple, le niveau de conformité diminue, respectivement augmente, si un nombre prédéterminé de règles fournit un résultat négatif, respectivement positif, pour un paquet donné, ou pour plusieurs paquets consécutifs, ou encore pour plusieurs paquets reçus parmi un nombre de paquets prédéterminé.
Si le résultat global RESG2 est égal à OK, le module AC fournit une copie du paquet reçu PAQ et les informations associées au module de collecte COL, et le procédé passe à l'étape E9. Le paquet reçu PAQ, considéré comme conforme, est transmis par le dispositif DD au réseau RI. Si le résultat global RESG2 est égal à NOK, c'est-à-dire le paquet reçu est non-conforme, le module AC fournit le paquet reçu PAQ et les informations associées au module d'analyse de non- conformité ANC, et le procédé passe à l'étape EIl. Optionnellement , le module AC émet une alerte comme décrit à l'étape d'alerte EAl. En variante, le module AC ajoute une règle de filtrage dynamique à celles gérées par le module de filtrage FIL afin de bloquer des flux comprenant des paquets similaires au paquet reçu PAQ ou de compter les paquets émis par l'entité émettrice .
Dans tous les cas, en plus du résultat global RESG2, le module AC fournit l'ensemble {RES2} contenant les résultats de chaque règle d'analyse de conformité qui a pu être exécutée, afin d'informer les fonctions de traitement en aval, notamment des modules COL et ANC, sur des détails observés sur le paquet reçu PAQ.
A l'étape E9, si le paquet reçu est considéré conforme par le module AC à l'étape E8, le module de collecte COL reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, ainsi que le paquet reçu PAQ correspondant, et applique à ces derniers la fonction de collecte fcoL afin d'extraire du paquet reçu des attributs de caractérisation de type d'entité destinés à actualiser la base de caractérisation de type d'entité BCTE, via la fonction fAPP-
La fonction fcoL prend également en entrée le contexte d'émission {IE}E récupéré par le module REC et un temps de traitement <TCOL> alloué par la fonction de gestion fGES • La fonction fcoL détermine des règles de collecte à appliquer à une sous-étape E91 et exécute ces règles déterminées à une sous- étape E92.
A la sous-étape E91, le module de collecte COL sélectionne un ensemble de règles de collecte {RCOL} mémorisées dans la base de règles BR, en fonction notamment du type <TE>E de l'entité émettrice et du temps de traitement <TCOL>- La fonction fcoL adapte ainsi un niveau de collecte au type de l'entité émettrice et aux ressources disponibles du dispositif DD.
De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : {RCOL} = fcOL (<TE>E, <TCOL>) •
Une règle de collecte RCOL désigne un ensemble {AA} d'attributs de caractérisation de type ou sous- type à collecter pour le paquet reçu, chaque attribut étant associé à une méthode de collecte.
Par ailleurs, dans le cas où le service contrôlé repose sur plusieurs protocoles, et éventuellement sur plusieurs types de messages par protocole, les règles de collecte peuvent être sélectionnées en outre en fonction du protocole de paquet <P> et du type de message reçu <TM> contenus dans l'ensemble {ID}, dans quel cas : {RCOL} = fcoL (<TE>E, <TC0L>, <P>, <TM>).
Par exemple, pour un service de voix sur IP, des règles de collecte spécifiques sont sélectionnées pour un paquet PAQ reçu selon le protocole d'initiation de session SIP, le paquet pouvant être un message de type "REGISTER" ou de type "INVITE".
A la sous-étape E92, le module de collecte COL exécute les règles de collecte sélectionnées, selon un ordre de priorité prédéfini dans le respect du temps de traitement alloué <TCOL>- Chaque attribut à collecter AA, contenu dans l'ensemble {AA}, est extrait du paquet reçu, puis soumis à la méthode de collecte correspondante.
De manière non exhaustive, un attribut à collecter AA peut désigner la présence, la valeur, la longueur ou le nombre d'occurrences d'un champ dans le paquet reçu, ou bien la longueur ou l'heure de réception du paquet reçu.
En corollaire, une méthode de collecte peut consister à compter un nombre d'événements ou une valeur moyenne sur une période prédéterminée, à déterminer une valeur maximale par exemple du débit de paquets reçus, ou bien à actualiser un attribut déjà appris. La fonction de collecte fcoL fournit un résultat d'erreur si au moins une règle de collecte RCOL n'a pu être exécutée correctement, c'est-à-dire un attribut à collecter AA n'a pu être extrait du paquet reçu, ou que la méthode de collecte correspondante a échoué. Le résultat d'erreur est fourni à titre indicatif au dispositif DD, par exemple pour déceler des entités dont le type a été incorrectement déterminé ou qui présentent un comportement anormal, mais n'entraîne pas la suppression du paquet reçu. Chaque règle de collecte actualise des informations de caractérisation contenues dans le contexte d'émission {IE}E, pouvant porter indifféremment sur le type ou des sous-types de l'entité. Ces informations de caractérisation collectées par la fonction de collecte fcoL sont uniquement initialisées, écrites ou actualisées dans le contexte d'émission {IE}E contenu dans la base de contexte d'entité BCE, mais ne sont pas reportées dans la base de caractérisation de type d'entité BCTE. A l'étape ElO, le module d'apprentissage APP actualise des attributs de type ou de sous-type d'entité ATT mémorisés dans la base de caractérisation de type d'entité BCTE. Le module APP fonctionne de manière asynchrone par rapport aux autres modules du dispositif DD, et sur une période de temps beaucoup plus longue, par exemple de plusieurs heures ou de plusieurs jours. Le fonctionnement asynchrone du module APP dépend directement des ressources disponibles du dispositif DD.
A l'expiration d'une période de rafraîchissement, la fonction d'apprentissage fAPP collecte des attributs de type ou de sous-type d'entité à une sous-étape ElOl et agrège les attributs collectés à une sous-étape E102.
A la sous-étape ElOl, le module d'apprentissage APP sélectionne des attributs de type d'entité ATT contenus dans la base de contexte d'entité BCE correspondant à un type ou sous-type d'entité prédéterminé. Les attributs collectés doivent constituer un ensemble homogène, c'est-à-dire correspondre chacun à une même information de caractérisation, portée par un ensemble d'entités de même type ou sous-type.
Si un nombre d'entités correspondant aux attributs sélectionnés ou un nombre d'attributs sélectionnés pour une entité donnée est inférieur à un seuil prédéterminé, la sous-étape de collecte ElOl se termine par un échec et la sous-étape d'agrégation E102 n'est pas exécutée. L'étape ElO est alors réitérée à la prochaine expiration de la période de rafraîchissement . A la sous-étape E102, le module d'apprentissage APP applique des méthodes d'analyse statistique à l'ensemble d'attributs sélectionnés. Une méthode d'analyse statistique est utilisée en fonction du type ou sous-type d'information de caractérisation constituant l'ensemble d'attributs sélectionnés.
Par exemple, si l'information de caractérisation est une longueur moyenne d'un champ particulier d'un paquet reçu pour des entités de type <TE> et de sous- type <STE> donnés, alors la méthode calcule la moyenne des attributs sélectionnés correspondant chacun à une longueur du champ particulier d'un paquet reçu.
Chaque méthode fournit ainsi un résultat qui est un attribut vraisemblable pour un type d'entité.
Le module APP actualise des attributs de caractérisation de type d'entité dans la base de caractérisation de type d'entité BCTE en fonction des résultats fournis par les méthodes d'analyse statistique, ou bien crée de tels attributs dans la base BCTE lorsque ces derniers n'existent pas. Le module APP actualise donc les attributs de caractérisation de type d'entité en fonction des attributs à apprendre AA extraits du paquet reçu et d'autres attributs extraits de paquets interceptés par le dispositif DD et précédemment émis par d'autres entités de même type que celui de l'entité émettrice. Ces attributs actualisés permettent ainsi au module de caractérisation du type d'entité CTE de préciser la détermination du type d'une autre entité dont des paquets sont ultérieurement reçus par le dispositif DD et dont le type est indéfini.
En outre, le module APP peut émettre une alarme à une étape EA3 en fonction des attributs sélectionnés. Le module APP peut détecter des valeurs anormales d'attributs sélectionnés. Par exemple, une valeur anormale est une valeur exclue d'un intervalle prédéterminé incluant une valeur de référence prédéterminée, telle qu'une moyenne de valeurs d'un ensemble d'attributs sélectionnés. Le module APP détecte ainsi une anomalie relative à l'entité dont un attribut a une valeur anormale.
La détection d'une valeur anormale d'attribut suppose généralement une anomalie relative à l'entité ayant émis le paquet. Cette anomalie peut provenir d'une entité présentant un comportement malveillant non détecté par le module d'analyse de conformité AC, d'une entité mal configurée, ou bien d'une entité dont le type ou le sous-type a été mal déterminé par le module de caractérisation d'entité CTE.
Ainsi, la fonction d'apprentissage, fAPP dont l'exécution est de type long-terme, est complémentaire de la fonction d'analyse de conformité fAC exécutée pour chaque paquet reçu, et de la fonction de caractérisation d'entité fcτ∑ exécutée pour un faible nombre de paquets reçus.
Par conséquent, si au moins une valeur anormale est détectée par le module APP, ce dernier peut alors émettre une alarme selon l'anomalie observée et l'entité y relative, ou ajouter des informations d'historique à la base de contexte d'entité BCE.
A l'étape EIl, si le paquet reçu est considéré comme non-conforme par le module AC à l'étape E8, le module d'analyse de non-conformité ANC reçoit les informations {ID} et <NDEC> fournies par le module de décodage DEC, les contextes {IE}E et {IE}D, le niveau de conformité <NCE>E et le paquet reçu PAQ correspondants, ainsi que les résultats RES2 de chaque règle d'analyse de conformité fournis par le module AC, et applique à ces derniers la fonction d'analyse de non-conformité fANC afin d'établir une corrélation entre des paquets non-conformes émis par l'entité émettrice. Cette corrélation est utile pour caractériser sur le moyen terme un type d'attaque ou de comportement malveillant de l'entité, relativement à un ensemble de paquets non-conformes reçus de cette entité .
La fonction d'analyse de non-conformité fANC prend également en entrée un temps de traitement <TANC> alloué par la fonction de gestion fGES • La fonction fANC détermine des règles d'analyse de non- conformité à une sous-étape ElIl et exécute ces règles déterminées à une sous-étape E112. A la sous-étape ElIl, le module ANC sélectionne un ensemble de règles d'analyse de non-conformité {RANC} mémorisées dans la base de règles BR, en fonction notamment d'un ensemble {RES2}NC des résultats non conformes retournés par les règles d'analyse de conformité et du temps de traitement <TANC>- L'ensemble {RES2}NC dépend donc de règles d'analyse de conformité auxquelles ne sont pas conformes respectivement le paquet reçu et d'autres paquets également émis par l'entité. De manière formelle, l'ensemble de règles sélectionnées peut s'écrire ainsi : {RANC} = fANC ({{RES2}NC}, <TANC>) •
Pour optimiser l'utilisation des ressources du dispositif DD, la fonction fANC est décrite par exemple sous forme d'expressions régulières basées sur des opérateurs logiques simples tels que "AND", "OR" ou "NOT". Chaque expression régulière porte sur tout ou partie de l'ensemble {RES2}NC et, si cette dernière est vérifiée, ajoute une ou plusieurs règles d'analyse de non-conformité à l'ensemble {RANC}. L'ensemble {RANC} peut alors être réduit en fonction des ressources disponibles du dispositif DD et donc du temps de traitement alloué <TANC>-
Par exemple, la base de règles BR contient K règles d'analyse de conformité RAC^, avec 1 ≤ k ≤ K et K = 15. L'ensemble {RES2}NC contient M identificateurs de règles RES2m, avec 1 ≤ m ≤ M et M ≤ K, ayant donné un résultat NOK pour le paquet analysé. La base de règles BR contient N règles d'analyse de non-conformité RANCn, avec 1 ≤ n ≤ N et N = 5. Par exemple, la fonction fANC peut être décrite sous la forme suivante : RES2io OR RES2i2 "> RANCi, RES23 -> RANC2, RES25 AND (NOT RES2]_o) "> RANC3, RANC4, et
RES2χ OR RES22 OR RES24 OR RES25 OR RES2]_o "> RANC5.
Selon ces hypothèses, les ensembles {RANC} de règles d'analyse de non-conformité suivants sont sélectionnés en fonction des ensembles {RES2}NC reçus de la fonction d'analyse de conformité : si {RES2}NC = {RES23, RES24}, alors {RANC} = fANC ({RES23, RES24}) = {RANC2, RANC5 }, si {RES2}NC = {RES25, RES2i0, RES2i2}, alors {RANC} = fANC ({RES25, RES2io, RES2i2}) = { RANCi, RANC5 }, et si {RES2}NC = {RES22, RES25}, alors {RANC} = fANC ({RES22, RES25}) = {RANC3, RANC4, RANC5 } .
A la sous-étape E112, le module ANC applique chaque règle d'analyse de non-conformité sélectionnées RANC de l'ensemble {RANC} au paquet reçu PAQ et aux contextes d'émission {IE}E et de destination {IE}Q associés, et fournit un résultat d'exécution RESC : RESC = RANC(PAQ, {IE}E, {IE}D). Le résultat RESC indique par exemple si la règle d'analyse de non-conformité a pu être correctement exécutée ou si d'autres actions sont nécessaires.
Une règle de non-conformité RANC est exécutée selon les trois phases suivantes :
- une première phase où la règle est invoquée une première fois pour être associée à des informations de conformité contenu dans le contexte d'émission {IE}E, et le paquet reçu correspondant est analysé;
- une deuxième phase où la règle est invoquée à chaque fois qu'un paquet reçu non-conforme engendre la sélection de la règle dans l'ensemble {RANC}; et
- une troisième phase où la règle devient inactive, par exemple à l'expiration d'une temporisation, et les informations de conformité associées à la règle sont supprimées.
Une information de conformité est par exemple le temps écoulé entre l'émission d'une requête et la réception d'une réponse à la requête. Lorsque des informations de conformité contenues dans un contexte d'émission {IE}E sont associées à une règle RANC, cela signifie que la règle RANC est active et exécutée . Le module ANC exécute les règles sélectionnées RANC en tout ou en partie, par exemple selon un ordre de priorité, pendant le temps de traitement <TANC> alloué à la fonction d'analyse de non-conformité fANC • Le module ANC actualise éventuellement des informations de conformité du contexte d'émission {IE|E et le niveau de conformité <NCE>E de l'entité émettrice. Pendant la deuxième phase d'exécution ou à la fin d'exécution d'une règle RANC, le module ANC peut ajouter des informations d'historique à la base de contexte d'entité BCE, ou coopérer avec le module de corrélation COR afin d'établir des corrélations entre le paquet reçu analysé et d'autres paquets reçus. Optionnellement , le module ANC ajoute une règle de filtrage dynamique à celles gérées par le module de filtrage FIL afin de bloquer par exemple des flux comprenant des paquets similaires au paquet reçu .
En outre, le module ANC peut émettre une alarme à une étape EA4 en fonction des règles sélectionnées RANC. Par exemple, le module ANC détecte une anomalie si l'une des règles sélectionnées RANC fournit un résultat négatif.
Ainsi, la fonction fANO dont l'exécution est de type moyen-terme, est complémentaire de la fonction d'analyse de conformité fAC exécutée pour chaque paquet reçu et permet de détecter des attaques discrètes qui sont réparties sur une plus longue période de temps, par exemple de quelques minutes ou de quelques heures.
En variante, les étapes du procédé selon l'invention sont exécutées pour une analyse de conformité du trafic émis à la fois par les entités de service ES vers les entités clientes EC et par les entités clientes EC vers les entités de service ES. L'analyse de conformité du trafic émis par les entités de service ES vers les entités clientes EC permet notamment d ' initialiser de nouvelles entités de service ES rattachées au réseau interne RI et de détecter éventuellement un comportement malveillant ou une mauvaise configuration de ces dernières.
L'invention décrite ici concerne un procédé et un dispositif pour détecter des anomalies dans le trafic émis par une entité vers une autre entité. Selon une implémentation, les étapes du procédé de l'invention sont déterminées par les instructions d'un programme d'ordinateur incorporé dans un processeur du dispositif de détection selon l'invention. Le programme comporte des instructions de programme qui, lorsque ledit programme est exécuté dans le processeur 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 enregistré sur ou dans un support d'enregistrement lisible par un ordinateur et tout dispositif de traitements de données, 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'enregistrement peut être n'importe quelle entité ou dispositif capable de stocker le programme. Par exemple, le support peut comporter un moyen de stockage sur lequel est enregistré le programme d'ordinateur selon l'invention, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore une clé USB, ou un moyen d'enregistrement magnétique, par exemple une disquette (floppy dise) ou un disque dur.
D'autre part, le support d'enregistrement 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'enregistrement 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 l'invention.

Claims

REVENDICATIONS
1 - Procédé pour détecter une anomalie dans le trafic émis par une entité (EC; ES), comprenant une récupération (E3) d'un contexte de l'entité en fonction d'un paquet (PAQ) intercepté dans le trafic, caractérisé en ce que, ledit contexte récupéré comprenant au moins un type et un niveau de conformité de l'entité, ledit procédé comprend : une sélection (E6; E81) d'au moins l'une de premières règles prédéterminées (RACl; RAC2) en fonction du type et du niveau de conformité de l'entité et de ressources disponibles d'un dispositif (DD) ayant intercepté ledit paquet, une décision (E6; E82) sur la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, , et une actualisation du contexte de l'entité en fonction de la décision prise sur la conformité du paquet intercepté.
2 - Procédé conforme à la revendication 1, caractérisé en ce que, si le type de l'entité n'est pas défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, l'actualisation (E7) du contexte de l'entité est faite en fonction du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par 1 ' entité .
3 - Procédé conforme à la revendication 2, comprenant en outre une détermination (E7) du type de l'entité en fonction du paquet intercepté et d'autres paquets interceptés dans le trafic émis par l'entité, et une détection (EA2) d'une anomalie si le type de l'entité est indéterminable.
4 - Procédé conforme à la revendication 1, selon lequel si un type de l'entité est défini dans le contexte de l'entité, la sélection de ladite au moins une première règle dépend d'un niveau de conformité de l'entité contenu dans le contexte de l'entité, ledit niveau de conformité dépendant de la conformité d'au moins un autre paquet de l'entité intercepté préalablement audit paquet intercepté à au moins une autre première règle.
5 - Procédé conforme à la revendication 4, selon lequel le contexte de l'entité est actualisé en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée.
6 - Procédé conforme à la revendication 4 ou 5, comprenant en outre, si le type de l'entité est défini et si le paquet intercepté n'est pas conforme à ladite au moins une première règle sélectionnée, une sélection (ElIl) d'au moins une deuxième règle en fonction du contexte de l'entité et de ladite au moins une première règle à laquelle n'est pas conforme le paquet intercepté et une détection (EA4) d'une anomalie en fonction d'une conformité du paquet intercepté et d'au moins un autre paquet intercepté dans le trafic émis par l'entité à ladite au moins une deuxième règle sélectionnée.
7 - Procédé conforme à la revendication 4 ou 5, comprenant en outre, si le type de l'entité est défini et si le paquet intercepté est conforme à ladite au moins une première règle sélectionnée, une extraction (E9) d'attributs (AA) du paquet intercepté et une mémorisation des attributs extraits dans le contexte de l'entité.
8 - Procédé conforme à la revendication 7, comprenant en outre une actualisation (ElO) d'attributs de type d'entité (ATT) en fonction des attributs extraits mémorisés (AA) et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, et une détection (EA3) d'anomalie si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits .
9 - Procédé conforme à l'une quelconque des revendications 1 à 8, selon lequel les premières règles sélectionnées comprennent des règles critiques et des règles non-critiques, les règles critiques étant appliquées au paquet intercepté de manière prioritaire par rapport aux règles non-critiques, et selon lequel la conformité du paquet intercepté est indéterminée si au moins une des règles critiques n'a pas pu être appliquée au paquet intercepté pendant un temps de traitement prédéterminé.
10 - Dispositif pour détecter une anomalie dans le trafic émis par une entité (EC; ES) présentant un contexte récupéré en fonction d'un paquet (PAQ) intercepté dans le trafic, caractérisé en ce que, ledit contexte récupéré comprenant au moins un type et un niveau de conformité de l'entité, il comprend :
- un moyen (AC) pour sélectionner au moins l'une de premières règles prédéterminées (RACl; RAC2) en fonction du type et du niveau de conformité de l'entité récupéré et de ressources disponibles du dispositif (DD),
- un moyen (AC) pour décider la conformité du paquet intercepté à ladite au moins une première règle sélectionnée, la conformité du paquet intercepté étant indéterminée si ladite au moins une première règle sélectionnée est inapplicable au paquet intercepté, et une actualisation du contexte de l'entité en fonction de la décision prise sur la conformité du paquet intercepté.
11 - Dispositif conforme à la revendication 10, comprenant :
- un moyen (AC) pour détecter une anomalie en fonction de la conformité du paquet intercepté à ladite au moins une première règle sélectionnée,
- un moyen (ANC) pour détecter une anomalie en fonction d'au moins une deuxième règle qui est sélectionnée en fonction du contexte de l'entité et d'au moins une première règle à laquelle n'est pas conforme le paquet intercepté,
- un moyen (CTE) pour détecter une anomalie si un type de l'entité contenu dans le contexte de l'entité est indéterminable, et
- un moyen (APP) pour détecter une anomalie en fonction d'attributs (AA) extraits du paquet intercepté et d'autres attributs extraits de paquets interceptés émis par d'autres entités de même type que celui de ladite entité, si la valeur de l'un des attributs extraits est exclue d'un intervalle prédéterminé dépendant des attributs extraits. 12 - Dispositif conforme à la revendication 11, lié à une base de données (BCE) comprenant le contexte de l'entité et les attributs (AA) extraits des paquets interceptés, et lié en outre à une autre base de données (BCTE) comprenant des attributs de type d'entité (ATT) qui sont actualisés en fonction des attributs extraits des paquets interceptés et qui servent à déterminer le type de l'entité.
13 - Programme d'ordinateur caractérisé en ce qu'il comprend des instructions pour la mise en œuvre du procédé selon l'une quelconque des revendications 1 à 9, lorsque le programme est exécuté par un processeur .
14 - Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur comprenant des instructions pour l'exécution des étapes du procédé selon l'une quelconque des revendications 1 à 9.
PCT/FR2008/051067 2007-06-15 2008-06-13 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets WO2009004234A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0755800A FR2917556A1 (fr) 2007-06-15 2007-06-15 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets
FR0755800 2007-06-15

Publications (1)

Publication Number Publication Date
WO2009004234A1 true WO2009004234A1 (fr) 2009-01-08

Family

ID=39246756

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2008/051067 WO2009004234A1 (fr) 2007-06-15 2008-06-13 Detection d'anomalie dans le trafic d'entites de service a travers un reseau de paquets

Country Status (2)

Country Link
FR (1) FR2917556A1 (fr)
WO (1) WO2009004234A1 (fr)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111417116A (zh) * 2020-03-10 2020-07-14 国家体育总局体育科学研究所 通过att、读写和异常处理来适配的通信方法及系统

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279113B1 (en) * 1998-03-16 2001-08-21 Internet Tools, Inc. Dynamic signature inspection-based network intrusion detection
US20050044406A1 (en) * 2002-03-29 2005-02-24 Michael Stute Adaptive behavioral intrusion detection systems and methods
US20070074272A1 (en) * 2005-09-29 2007-03-29 Fujitsu Limited Network security apparatus, network security control method and network security system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6279113B1 (en) * 1998-03-16 2001-08-21 Internet Tools, Inc. Dynamic signature inspection-based network intrusion detection
US20050044406A1 (en) * 2002-03-29 2005-02-24 Michael Stute Adaptive behavioral intrusion detection systems and methods
US20070074272A1 (en) * 2005-09-29 2007-03-29 Fujitsu Limited Network security apparatus, network security control method and network security system

Cited By (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111417116A (zh) * 2020-03-10 2020-07-14 国家体育总局体育科学研究所 通过att、读写和异常处理来适配的通信方法及系统
CN111417116B (zh) * 2020-03-10 2023-09-19 国家体育总局体育科学研究所 通过att、读写和异常处理来适配的通信方法及系统

Also Published As

Publication number Publication date
FR2917556A1 (fr) 2008-12-19

Similar Documents

Publication Publication Date Title
US10218740B1 (en) Fuzzy hash of behavioral results
US8775521B2 (en) Method and apparatus for detecting zombie-generated spam
EP3087701A1 (fr) Procede de diagnostic de fonctions service dans un reseau ip
EP3871392A1 (fr) Système de sécurité de réseau avec analyse de trafic améliorée basée sur une boucle de rétroaction
Aiello et al. Profiling DNS tunneling attacks with PCA and mutual information
WO2021152262A1 (fr) Procede de surveillance de donnees echangees sur un reseau et dispositif de detection d&#39;intrusions
FR2974965A1 (fr) Procede de detection d&#39;intrusions
US10003602B2 (en) Determining email authenticity
US11743272B2 (en) Low-latency identification of network-device properties
FR2902954A1 (fr) Systeme et procede de stockage d&#39;un inventaire des systemes et/ou services presents sur un reseau de communication
WO2009004234A1 (fr) Detection d&#39;anomalie dans le trafic d&#39;entites de service a travers un reseau de paquets
WO2016055750A1 (fr) Procede d&#39;ajustement dynamique d&#39;un niveau de verbosite d&#39;un composant d&#39;un reseau de communications
EP4009584A1 (fr) Procédé de détermination de classifieurs pour la détection d&#39;attaques dans un réseau de communication, dispositif de détermination associé
EP4066461B1 (fr) Procédé de coordination de la mitigation d&#39;une attaque informatique, dispositif et système associés
EP3598330B1 (fr) Procédé et dispositif de détection d&#39;anomalie
EP3644146B1 (fr) Dispositif d&#39;enregistrement d&#39;intrusion informatique
EP3375143B1 (fr) Analyse asynchrone d&#39;un flux de données
US8996690B1 (en) Time-based analysis of data streams
FR3093258A1 (fr) Procede de protection d’un reseau prive d’ordinateurs
FR3083659A1 (fr) Identification de protocole d&#39;un flux de donnees
EP3035639B1 (fr) Procédé de détection de balayage de ports non-autorisé dans un réseau informatique, produit programme d&#39;ordinateur et dispositif associés
EP4009209A1 (fr) Procédé de détermination de quantités pour la détection d&#39;attaques dans un réseau de communication, dispositif de détermination associé
WO2023036847A1 (fr) Procede et système de surveillance et gestion du trafic de données
EP3835985A1 (fr) Procédé de surveillance de données transitant par un équipement utilisateur
FR3086822A1 (fr) Procede de gestion d&#39;un reseau de communication local, gestionnaire central et programme d&#39;ordinateur correspondants.

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 08806002

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 08806002

Country of ref document: EP

Kind code of ref document: A1