EP4066460A1 - Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes - Google Patents

Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes

Info

Publication number
EP4066460A1
EP4066460A1 EP20824303.0A EP20824303A EP4066460A1 EP 4066460 A1 EP4066460 A1 EP 4066460A1 EP 20824303 A EP20824303 A EP 20824303A EP 4066460 A1 EP4066460 A1 EP 4066460A1
Authority
EP
European Patent Office
Prior art keywords
attack
protection
protection service
domain
service
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Pending
Application number
EP20824303.0A
Other languages
German (de)
English (en)
Inventor
Mohamed Boucadair
Christian Jacquenet
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Orange SA
Original Assignee
Orange SA
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 Orange SA filed Critical Orange SA
Publication of EP4066460A1 publication Critical patent/EP4066460A1/fr
Pending legal-status Critical Current

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
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/14—Network architectures or network communication protocols for network security for detecting or protecting against malicious traffic
    • H04L63/1441—Countermeasures against malicious traffic
    • H04L63/1458—Denial of Service
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0263—Rule management
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L2463/00—Additional details relating to network architectures or network communication protocols for network security covered by H04L63/00
    • H04L2463/141—Denial of service attacks against endpoints in a network
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L63/00—Network architectures or network communication protocols for network security
    • H04L63/02—Network architectures or network communication protocols for network security for separating internal from external traffic, e.g. firewalls
    • H04L63/0227—Filtering policies
    • H04L63/0236—Filtering by address, protocol, port number or service, e.g. IP-address or URL

Definitions

  • the invention relates to the general field of telecommunications.
  • the invention applies in particular to computer attacks of the denial of service (DoS) or DDoS (for “Distributed DoS”) type.
  • DoS attack is an attempt to making resources in a computing domain, such as for example network or computing resources, unavailable to their users.
  • DDoS attacks are often massive and likely to compromise several hundred thousand user equipment (fixed or mobile terminals, connected objects, servers, network resources, etc.), which can in turn be used as relays for amplify the harmful power of these attacks.
  • the company Symantec in its annual report for 2019, reports nearly 24,000 applications embedded in mobile devices blocked daily by such attacks, a 600% increase between 2016 and 2017 in attacks targeting objects. connected, and an increase in the volume of attack traffic between 2016 and 2017, which represented 5% of global web traffic in 2016 against 7.8% in 2017.
  • DDoS attacks are more and more frequent and intense, and can target several hundred thousand computer machines.
  • DPS protection services for "DDoS Protection Services" in English.
  • filtering policies i.e. capable of isolating the traffic coming from all the affected machines.
  • FIG. 1 represents, by way of illustration, a client IT domain CL connected to two forwarding networks TN1 and TN2 providing it with access to the Internet network.
  • Each of the forwarding networks hosts a dedicated DPS protection service, referenced by DPS1 for the forwarding network TN1 and by DPS2 for the forwarding network TN2.
  • DPS1 for the forwarding network TN1
  • DPS2 for the forwarding network TN2.
  • PI for “Provider-Independent” in English
  • DPS protection offers are based on services hosted in the “cloud” and not only within the infrastructures operated by providers of access to the Internet network. These deployments in the cloud pose technical problems, particularly concerning the early detection of attacks because the components of the DPS service involved in the detection or resolution of attacks and hosted in the cloud are not necessarily present on the different paths taken by the traffic. attack, so that they are not able to inspect and filter this traffic.
  • certain protection services may have limited treatment and mitigation capacity and not be able to process attacks of high amplitude or corresponding to a volume of infected traffic exceeding a certain threshold.
  • a protection service against computer attacks must coordinate the operations of routing traffic to the client computer domain that it protects, so that legitimate traffic destined for this the latter is routed normally to this one.
  • the protection service must identify suspicious traffic and then isolate it so that it does not get routed to the customer IT domain. To this end, it can rely on a center or a so-called cleaning (or "scrubbing" in English) function, which can turn out to be undersized to handle attacks requiring CPU (Central Processing Unit) or capacity resources. consequent.
  • the effectiveness of the mitigation implemented by the protection service is then reduced and the client IT domain continues to be attacked despite the intervention of the protection service.
  • an AG agent of the client IT domain CL requests the two protection services DPS1 and DPS2 for the mitigation of the attack.
  • the DPS1 service quickly implements an effective mitigation plan because it has detection and mitigation mechanisms adapted to the type of attack in progress, while the DPS2 service fails to set up a plan effective mitigation, for example because it does not have the traffic detection and identification mechanism characteristic of this attack.
  • the attack traffic is then blocked by the forwarding network TN1, but continues to be routed to the client domain CL via the forwarding network TN2.
  • the client domain CL is still the victim of the attack despite the mitigation plan put in place by the DPS1 system.
  • the client domain CL uses addresses known as PA (Provider-Aggregatable), that is to say if the addresses used on the interconnection links which connect the customer domain CL to the forwarding networks TN1 and TN2 are those provided by each of the connectivity providers which operate these TN1 and TN2 forwarding networks.
  • PA Provide-Aggregatable
  • the invention makes it possible in particular to remedy the drawbacks of the state of the art by proposing an assistance method implemented by a device managing resources of a computer domain, said resources being protected by a plurality of protection services against computer attacks, this method comprising:
  • the invention also relates to a device managing resources of a computer domain, configured to communicate with a plurality of protection services against computer attacks protecting said resources of the computer domain, this device comprising:
  • a determination module configured to determine an inability of a first protection service of the plurality of protection services, to process a computer attack targeting at least one resource in the computer domain;
  • a development module configured to develop a mitigation plan for said attack from a mitigation plan obtained from a second protection service of the plurality of protection services or using assistance provided by at least the second protection service;
  • a transmission module configured to transmit the mitigation plan thus developed to the first protection service to handle the attack.
  • the invention proposes to exploit the subscription by the IT domain to a plurality of protection services (which may be in particular, for all or part of them, managed by separate administrative entities) to dynamically provide a assistance to a protection service incapable of managing a data-processing attack detected in the data-processing field (first protection service within the meaning of the invention, also designated hereinafter by “incapacitated protection service”).
  • This assistance takes the form of a mitigation plan drawn up and supplied to the incapable protection service, based on a mitigation plan set up or determined by another protection service (second protection service within the meaning of invention) in response to the attack, thus making it possible to remedy a functional insufficiency of the incapable protection service, or relying on the assistance of another protection service (second protection service within the meaning of (invention), thus making it possible to remedy a lack of capacity in the incapable protection service.
  • the term “mitigation plan” denotes a set of actions developed for the resolution of an attack. The purpose of these actions is to prevent the attack traffic from spreading into the IT domain. These may be actual mitigation actions put in place or developed by a protection service, but also include assistance provided by a protection service to extend the capabilities of the incapacitated protection service and enable it to resolve the attack, etc.
  • the invention is not limited to a local application of the mitigation plan developed within the IT field, an application which is not always possible depending on the state of the resources affected by the attack; but it also provides for the transmission of the mitigation plan drawn up to the incapacitated protection service to remedy its deficiencies.
  • This makes it possible, when the protection service protects resources such as interconnection links of the IT domain with the Internet network or transit networks, to block the attack traffic in advance, upstream and / or inbound. of the customer IT domain.
  • the invention is not restricted to a first protection service protecting resources in the IT domain targeted by the attack. It can also be applied to a first protection service protecting resources of the IT domain involved in the routing of traffic from the attack to the resources targeted by the latter. Thus, an attack is considered here falling within the scope of action of the first protection service.
  • the mitigation plan transmitted to the incapable protection service is prepared by a device managing the resources of the IT domain which are protected by the plurality of protection services, also sometimes referred to here as " customer domain ”or even“ customer IT domain ”.
  • customer domain also sometimes referred to here as " customer domain ”or even“ customer IT domain ”.
  • the protection services can be managed by separate administrative entities, they are not necessarily aware of the mitigation actions implemented by the other protection services protecting resources in the client domain.
  • the client domain has global visibility on the actions implemented to protect its resources, and the invention advantageously exploits this visibility to coordinate and improve the effectiveness of the mitigation efforts undertaken by the protection services in the presence.
  • an attack detected in the client domain is a better reaction time and attack processing time as well as an increased speed of execution of mitigation actions. In this way, the continuity of the services offered by the IT sector is guaranteed.
  • the invention makes it possible to exploit the knowledge of the attack by the protection service DPS2 and an effective mitigation plan thereof by developing and providing the DPS1 protection service with a mitigation plan drawn up from the mitigation plan implemented by the DPS2 protection service.
  • the protection services DPS1 and DPS2 protecting the interconnection links of the client domain CL affected by the attack are able to set up policies for filtering attack traffic entering the CL client domain.
  • the management of the attack affecting the IT domain is therefore improved, not only individually at the level of each protection service, but also at the level of the overall action carried out by all of the protection services. It should be noted that this improvement is advantageously obtained without having to modify or extend the visibility of the traffic available to each of the protection services. Concretely, the various protection services continue to have only partial visibility of the traffic associated with the customer domain and not the global traffic. of said customer domain.
  • the invention thus enables rapid, automatic and reliable resolution of computer attacks liable to affect the resources of a computer domain. Thanks to the use of the mitigation actions implemented by various protection services, the invention offers the possibility of dealing with attacks affecting all the resources of the IT domain.
  • the second protection service set up a mitigation plan in response to the attack
  • the mitigation plan sent to the first protection service is drawn up by adapting the mitigation plan set up by the second protection service to the resources of the IT domain protected by the first protection service.
  • This embodiment makes it possible more particularly to manage a functional incapacity of the first protection service, while the second protection service is able to deal with this attack and has put in place an effective mitigation plan for this purpose.
  • the mitigation plan provided to the first protection service is then derived from the mitigation plan put in place by the second protection service.
  • the derived mitigation plan is not necessarily an identical copy of the mitigation plan provided by a first protection service. It can be inspired by it and / or take up and / or adapt all or part of the actions indicated therein, for example to take account of constraints which are specific to the first protection service.
  • the method further comprises:
  • This embodiment also aims to overcome a functional deficiency of the first protection service.
  • the attack falls only within the scope of action of the first protection service (in other words, the attack targets IT resources protected by the first protection service or that of the first protection service). This protects resources from the IT domain involved in routing attack traffic to the resources targeted by the attack).
  • the second protection service was not directly concerned by the attack affecting the IT sector, it did not, strictly speaking, put in place any mitigation action against this attack.
  • the invention in this embodiment by ordering the second protection service to emulate the attack on the resources of the computing domain that it protects and to propose a mitigation plan in response to this attack.
  • the mitigation plan proposed by the second protection service corresponds to the resources of the IT domain protected by the second protection service (typically identified by dedicated IP addresses or prefixes), and not to the resources of the IT domain. resources protected by the first protection service targeted by the attack.
  • the development of a miti gation plan intended for the first protection service then consists in particular of an adaptation by the device managing the resources of the IT domain of the mitigation plan proposed by the second protection service to the resources protected by the first service. protection.
  • the inability of the first protection service stems from a lack of resources available at the level of the first protection system to mitigate the attack, the method comprising a step of obtaining from of the second protection service of at least one item of information allowing establishment of a communication between the first protection system and the second protection system to assist it in the mitigation of the attack, the mitigation plan transmitted to the first system protection comprising said at least one item of information obtained.
  • the assistance provided by the second protection service is then in this embodiment a capacity assistance to handle the attack, making it possible to alleviate an insufficiency of resources of the first protection service to resolve the attack, by example because of the magnitude of the attack.
  • This embodiment makes it possible to artificially extend the resources of the first protection service in order to effectively resolve the attack. Thanks to the communication established between the first and the second protection service, the first protection service can for example redirect part of the traffic intended for the IT domain to the second protection service so that the latter filters it.
  • the capacity assistance provided to the first protection service can come from several protection services among the plurality of protection services protecting the resources of the computer domain.
  • the method comprises:
  • the interrogation can be done for example upstream of the detection of an attack.
  • This embodiment makes it possible to anticipate the problems linked to a capacity failure of one of the protection services. From the stored information, when it is informed of such a failure, the device managing the resources of the client IT domain can act more quickly to set up assistance with the failing protection service.
  • the interrogation step can be implemented following the detection of an attack targeting at least one resource in the IT domain.
  • This embodiment makes it possible to obtain up-to-date information, representative of a current state of the protection services capable of providing their assistance.
  • the information provided by the protection services able to provide assistance can be of different types. They include for example at least one element among:
  • the device indicates to the questioned protection services a minimum capacity which a protection service declaring itself capable of providing assistance must have.
  • the device can rely on traffic forecasting mechanisms (or "traffic forecast” in English), known per se. This minimum capacity can then be reassessed on a case-by-case basis according to the needs of a failing protection service.
  • traffic forecasting mechanisms or "traffic forecast” in English
  • This embodiment makes it possible to avoid the selection by the device of the client IT domain of a protection service that does not have sufficient capacity resources to provide assistance to a faulty protection service, and therefore a loss of time in the execution of the method according to the invention.
  • the method comprises, after detection of the attack, a step of sending to all or part of the protection services of the plurality of protection services having a perimeter of action in which is finds at least one resource in the IT domain targeted by the attack, with a request to obtain a mitigation plan set up by these protection services in response to the attack.
  • the protection services provide their mitigation plans set up if necessary against the detected attack, in response to a request from the device of the client IT domain.
  • the device managing the resources of the IT domain can for this purpose, for example, register with each protection service to be informed by it of the mitigation plans that it implements.
  • the method comprises:
  • the device managing the resources of the client IT domain thus coordinates the mitigation actions put in place by the various protection services concerned by the attack (in other words, in the scope of action to which the attack falls) so to avoid inconsistencies between these actions.
  • the protection services being likely to be managed by separate administrative entities, they have no mutual visibility on the actions implemented by the other protection services in the presence of a attack, unlike client IT domain.
  • one (or more) protection service can make mitigation decisions that can have negative implications on the service provided to the client IT domain, in particular because they are not consistent with other decisions taken by another service. protection in response to the attack. For example, decisions made by two (or more) different protection services can lead to the establishment of a routing loop that prevents legitimate traffic from being routed to the customer IT domain.
  • the invention is based on the device managing the resources of the computing domain which are protected by various protection services against computer attacks, but also on the action of the latter .
  • the invention also relates to a method for obtaining, by a first protection service, a plurality of protection services against computer attacks protecting resources of a computer domain, of a plan for mitigating a computer attack targeting at least one of the resources of the computer domain, this method comprising, following a detection of an inability of the first protection service to process the attack:
  • the invention also relates to a device of a first protection service of a plurality of protection services against computer attacks protecting resources of a computer domain, at least one of the resources of the computer domain being targeted. by a computer attack, said device comprising modules activated following detection of an inability of the device to process the attack, these modules comprising:
  • a reception module configured to receive a mitigation plan produced by a device managing said resources of the IT domain from a mitigation plan obtained from a second protection service of said plurality of protection services or using assistance provided by at least said second protection service;
  • an implementation module configured to set up in response to said attack a mitigation plan derived from the mitigation plan received from the device to process the attack.
  • the method for obtaining and the device of the first protection service benefit from the same advantages mentioned above as the assistance method and the device in the IT field.
  • the step of setting up the mitigation plan comprises, when the mitigation plan uses assistance provided by at least the second protection service, a routing of data suspected of being associated attack to the second protection service for processing this data.
  • the data is for example routed to the second protection service via a secure tunnel established with the second protection service by means of information contained in the mitigation plan received from the device.
  • the assistance provided by the second protection service allows the first protection service to relieve some of the suspicious traffic that it is not able to process and to route it to the second protection service so that it applies an appropriate mitigation plan to this suspicious traffic.
  • the assistance method and / or the obtaining method are implemented by a computer.
  • the assistance method and / or the obtaining method are implemented by a computer not directly connected to the IT domain (eg, a smartphone) but able to manage the resources of said IT domain.
  • the invention also relates to a first computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a device managing the resources of a compliant client IT domain. to the invention and includes instructions adapted to the implementation of an assistance method as described above.
  • the invention also relates to a second computer program on a recording medium, this program being capable of being implemented in a computer or more generally in a device of a first service for protection against attacks.
  • computer systems in accordance with the invention and comprises instructions adapted to the implementation of a method of obtaining as described above.
  • Each of these programs 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 desirable shape.
  • the invention also relates to an information medium or a recording medium readable by a computer, and comprising instructions of the first, second or third computer program mentioned above.
  • the information or recording media can be any entity or device capable of storing the programs.
  • the media can comprise a storage means, such as a ROM, for example a CD ROM or a microelectronic circuit ROM, or else a magnetic recording means, for example a hard disk, or a flash memory.
  • the information or recording media can be transmitted media such as an electrical or optical signal, which can be routed via an electrical or optical cable, by radio link, by link. wireless optics or other means.
  • the programs according to the invention can in particular be downloaded over an Internet type network.
  • each information or recording medium can be an integrated circuit in which a program is incorporated, the circuit being adapted to execute or to be used in the execution of the communication method, according to the invention. , or of the selection method, in accordance with the invention.
  • the invention is also aimed at a system for protecting an IT domain comprising:
  • said plurality of protection services comprising at least:
  • a first protection service comprising a device according to the invention incapable of processing a computer attack targeting at least one resource in the computer domain;
  • a second protection service having set up a mitigation plan for said attack or capable of providing assistance to the first protection service to deal with said attack on which said device managing said resources of the IT domain relies to develop and transmit said first protection service a mitigation plan for the attack.
  • the second protection service comprises:
  • an emulation module activated at the request of the computer domain device when the attack falls within the scope of action of the first protection service only, said emulation module being configured to emulate said attack on at least one resource of the computing domain protected by the second protection service;
  • a transmission module configured to transmit to the computer domain device an attack mitigation plan proposed by the second protection service during the emulation of said attack by the emulation module.
  • the second protection service comprises a supply module, activated at the request of the device managing the resources of the IT domain when said attack is within the scope of action of the second protection service, said supply module being configured to provide the device managing the resources of the IT domain with a mitigation plan set up by the second protection service in response to the attack.
  • the system according to the invention benefits from the same advantages mentioned above for the assistance method, the obtaining method, the device in the IT field and the device of the first protection service according to the invention.
  • the assistance method, the obtaining method, the device managing the resources of the IT domain, the device of the first protection service and the system according to The invention exhibit in combination all or part of the aforementioned characteristics.
  • FIG. 1 already described, represents a computer domain protected by two services for protection against computer attacks, according to the state of the art
  • FIG. 2 represents a system for protecting a computer domain according to the invention in a particular embodiment
  • FIG. 3 represents the hardware architecture of a device managing the resources of the computer domain protected by the protection system of FIG. 2, in a particular embodiment
  • FIG. 4 represents the hardware architecture of a server device of a protection service of the protection system of FIG. 2, in a particular embodiment
  • FIG. 5 represents the main steps of an assistance method according to the invention as they are implemented, in a particular embodiment, by the device of FIG. 3;
  • FIG. 6 represents the main steps of a method of obtaining according to the invention as they are implemented, in a particular embodiment, by a server device of the protection system of FIG. 2;
  • FIG. 7 represents steps that can be implemented, in a particular embodiment, by a server device of the protection system of FIG. 2.
  • FIG. 2 represents a system 1 for protecting a computer domain 2 against computer attacks, in accordance with the invention, in a particular embodiment.
  • IT domain also referred to as “client IT domain or client domain”, is understood here to mean a set of computer resources (including in particular re- resources. buckets such as routers, switches, servers, terminals, etc.), placed under the responsibility of a given administrative entity.
  • a computer domain is for example a company network, a home network or an autonomous system or AS (for “Autonomous System”) using the BGP (for “Border Gateway Protocol”) protocol.
  • AS for “Autonomous System”
  • BGP for “Border Gateway Protocol” protocol
  • the computer domain 2 is connected to the public Internet network, directly or via one or more forwarding networks. It has various computer resources (CPU resources, memory resources, network resources, interconnection links with other networks, etc.), protected by a plurality of protection services against computer attacks SP1, SP2, etc. , SPN, to which the administrator or the owner of the IT domain 2 has subscribed, N denoting an integer greater than 1. For the sake of simplicity, in Figure 2, three protection services SP1, SP2 and SP3 are shown, however the number N can be any integer greater than 1.
  • All or part of the protection services SP1, SP2, ..., SPN, protecting the resources of the IT domain 2, and in particular in the example considered here SP1, SP2 and SP3, are managed by administrative entities (for example, by separate network operators. In other words, each of these administrative entities has no visibility on the attack mitigation actions implemented by the other administrative entities and their own protection services (i.e. no prior knowledge of these mitigation actions).
  • the term “mitigation plan” is understood to mean actions proposed or implemented by a protection service for the resolution of an attack, in particular with a view to preventing the traffic of the attack from spreading. to achieve one or more targets in the IT field 2.
  • protection services SPk, k 1, ..., N, we mean here both the service itself supplied to the computer domain 2 and the device or devices hosting the logic of this service. Also, no assumption is made as to the functional and organic structure of a DPS service.
  • DDoS distributed denial of service
  • the IT domain 2 comprises one (or more) functions for detecting DDoS attacks.
  • the invention applies to any type of computer attack (denial of service, identity theft, ransomware, etc.).
  • no limitation is attached to the nature of the resources which may be the target of an attack; it may for example be an IP address, an IP prefix, a machine, an alias, a fully qualified domain name (FQDN for Fully Qualified Domain Name), etc.
  • the protection system 1 is based on a DOTS client / server architecture (for "DDoS Open Threat Signaling") as defined by ITETF (Internet Engineering Task Force).
  • DOTS architecture for "DDoS Open Threat Signaling" as defined by ITETF (Internet Engineering Task Force).
  • ITETF Internet Engineering Task Force
  • the DOTS architecture specified by the IETF aims to provide a signaling mechanism for detecting suspicious traffic or even a proven attack, so that appropriate mitigation measures can be implemented as quickly as possible.
  • it allows a client called DOTS client which manages a computer domain to inform a server called DOTS server of the detection of suspicious traffic potentially characteristic of an ongoing DDoS attack and that appropriate mitigation actions are taken. required.
  • the DOTS server can then set up or coordinate various actions so that, by For example, the traffic associated with the denial of service attack is no longer routed to the IT domain of the DOTS client, and only authorized (i.e. legitimate) traffic is routed to said IT domain.
  • the DOTS client is not necessarily a network element of the IT domain in question, but can be connected indirectly to the latter; it can be for example a control network or a terminal (for example, a smartphone) of an administrator of the IT domain, etc.
  • DOTS communication channels are defined between the DOTS client and the DOTS server:
  • DOTS Signal Channel (“DOTS Signal Channel”): this channel is used only for the duration of DDoS attacks.
  • the DOTS client can use this channel to request assistance from the DOTS server by informing it that an attack is in progress.
  • Table 1 illustrates an example of a mitigation request that can be sent via a DOTS “draft-ietf-dots-signal-channel” signaling channel (corresponding to a target of the attack identified by the attribute “ietf-dots-signal - channel: mitigation-scope "in table 1), by a DOTS client identified by a unique identifier CUID (for" Client Unique Identifier ")" mydotsclient ", to its DOTS server, to inform it that the prefix" 1.2.
  • CUID for" Client Unique Identifier
  • DOTS Data Channel this channel is used if and only no attack is in progress.
  • the DOTS client can for example use this channel to install filtering rules (or ACL for “Access Control List”) such as filtering traffic received from certain addresses or intended for a given machine.
  • filtering rules or ACL for “Access Control List”
  • Table 2 provides an example of a message sent on a “draft-ietf-dots-data-channel” DOTS data channel (corresponding to a filter characterized by the attribute “ietf-dots-data-channel: access- lists ”in table 2), by a DOTS client with CUID“ mydotsclient ”, asking a DOTS server to block (“ actions ”: ⁇ “ forwar- ding ”:“ drop ” ⁇ ) all traffic destined for the prefix "1.2.3.0/24".
  • DOTS is therefore an architecture intended to facilitate the handling of attack mitigation requests sent by a DOTS client and received by a DOTS server, such as for example a server operated by a service provider for protection against attacks computer science.
  • the IT domain 2 comprises a device 3, in accordance with the invention, in charge of the management and monitoring of all the IT resources of the IT domain 2, and the protection services SP1, ..., SPN, comprise devices 4-1, ..., 4-N respectively, also according to the invention, the device 3 and the devices 4-1, ..., 4-N being capable of interact with each other according to the principles which have just been described and characteristics of the DOTS client / server architecture.
  • the device 3 acts as a DOTS client (hereinafter referred to as “client device 3”) and the devices 4-1, 4-2, ..., 4-N like DOTS servers.
  • client device 3 the devices 4-1, 4-2, ..., 4-N like DOTS servers.
  • the invention however applies to other architectures and / or to other protocols allowing devices 3, 4-1, ..., 4-N to communicate with each other.
  • DOTS communications between a DOTS client and a DOTS server can be done via relays (or “DOTS Gateways”). These relays can be hosted within the domain of the DOTS client (also referred to as “client domain”) or within the domain of the server (also referred to as “server domain”) or both.
  • a DOTS relay located in a domain of the client is considered by a DOTS server as a DOTS client.
  • a DOTS relay located in a server domain is considered by a DOTS client as a DOTS server.
  • DOTS server in the event of the presence of a DOTS relay in a server domain, the authentication of DOTS clients is the responsibility of the relay.
  • a DOTS server must be configured with the list of active DOTS relays within its domain; he can then delegate some of his functions to these trusted relays.
  • the DOTS server can safely use the information provided by a relay appearing in a list declared with the DOTS server and maintained by the latter, by means of an ad hoc authentication procedure (for example, explicit configuration of the list. relays by the authorized administrator of the server, retrieval of the list from an AAA server (for “Authentication, Authorization and Accounting” in English), etc.).
  • the client device 3 is configured to establish with the server devices 4-1, ..., 4-N protection services SP1, ..., SPN (or DOTS relays located in the computer domains hosting the server devices 4-1, ..., 4-N) secure DOTS sessions in accordance with the aforementioned IETF specification entitled "Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Specification".
  • the sessions are established here using the DTLS protocol (for “Datagram Transport Layer Security” in English), or the TLS protocol (for “Transport Layer Security” in English).
  • DTLS protocol for “Datagram Transport Layer Security” in English
  • TLS protocol for “Transport Layer Security” in English
  • DOTS agents clients, servers and relays
  • the various DOTS agents that is to say the DOTS client device 3 and the DOTS server devices 4-1 , ..., 4-N or relay between these DOTS devices
  • the DOTS client device 3 and the DOTS server devices 4-1 , ..., 4-N or relay between these DOTS devices are configured to authenticate each other.
  • requests from DOTS client devices not authorized to access the service offered by the DOTS server device 4-1, ..., 4-N considered are ignored by the latter.
  • the DOTS client device 3 has the hardware architecture of a computer, as shown in FIG. 3. It comprises in particular a processor 5, a RAM 6, a ROM 7 , a non-volatile memory 8, and communication means 9 allowing it in particular to communicate, using in particular the DOTS protocol, with the server devices 4-1, ..., 4-N of the protection services SP1, .. ., SPN.
  • These communication means 9 are based on a wired or wireless communication interface, known per se and not described in more detail here.
  • the read only memory 7 of the client device 3 constitutes a recording medium according to the invention, readable by the processor 5 and on which is recorded a computer program PROG3 according to the invention, comprising instructions for the execution of the steps of an assistance method according to the invention.
  • the PROG3 program defines functional modules of the client device 3, which are based on or control the hardware elements 5 to 9 of the client device 3 mentioned above, and which include in particular (see FIG. 2):
  • a determination module 3A configured to determine an inability of a first protection service among the plurality of protection services SP1, ..., SPN, to process a computer attack targeting at least one resource of the computer domain 2, and falling within the scope of action of the first protection service;
  • a development module 3B configured to develop a mitigation plan for said attack from a mitigation plan obtained from a second protection service among the plurality of protection services SP1, ..., SPN, or using assistance provided by at least said second protection service; and a 3C transmission module, configured to transmit the mitigation plan developed to the first protection service to process the attack.
  • the client device 3 can also include a DDoS attack detection function. In the embodiment described here, however, it is assumed that this DDoS attack detection function is hosted by another device 10 in the IT domain 2 (cf. FIG. 2).
  • modules 3A to 3C of the client device 3 are detailed in more detail later.
  • each DOTS server device 4-1, ..., 4- N has the hardware architecture of a computer, as shown in FIG. 4. It comprises in particular a processor 11, a random access memory 12, a read only memory 13, a non-volatile memory 14, and means of communication 15 allowing it in particular to communicate, using in particular the DOTS protocol, with the client device 3.
  • These means of communication 15 are based on a wired or wireless communication interface, known per se and not described in more detail here.
  • computer PROG4 in accordance with the invention, comprising instructions for executing the steps of an obtaining method according to the invention.
  • the PROG4 program defines functional modules of the 4-k server device, which are based on or control the hardware elements 11 to 15 mentioned above, and which notably include (cf. FIG. 2) a reception module 4A and a setting module. place 4B, activated following a detection of an inability of the server device 4-k to deal with a computer attack targeting one or more resources of the computer domain 2.
  • the implementation module 4B is for its part configured to set up in response to the computer attack a mitigation plan derived from the mitigation plan received from the client device 3.
  • a 4D emulation module activated at the request of the client device 3, and configured to emulate a computer attack on at least one resource of the computer domain 2 protected by the protection service SPk, as well as a transmission module 4E configured for transmit to the client device 3 an attack mitigation plan proposed by the protection service SPk during the emulation of the attack by the emulation module 4D.
  • FIG. 5 thus illustrates the steps of an assistance method according to the invention, as implemented by the client device 3 in a particular embodiment.
  • an ATTACK computer attack has been detected on at least one resource in the computer domain 2 by the function for detecting computer attacks, in a manner known per se.
  • This attack is signaled by the detection function 10 to the client device 3 (step E10).
  • the detection function 10 supplies various information on the ATTACK attack to the client device 3, such as for example the characteristics of the traffic of the attack (source address (es), destination address (es), identifia nt ( s) protocols (for example ICMP (for Internet Control Message Protocol), TCP (for Transmission Control Protocol), etc.), the nature of the attack (here DDoS attack), etc.
  • This information can be supplemented by information of attack traffic volume, obtained for example by function 10 via the collection of SNMP (Simple Network Management Protocol) counters on the affected interfaces.
  • SNMP Simple Network Management Protocol
  • the client device 3 On receipt of this signal, the client device 3 sends a DOTS request to all or part of the devices 4-1, ..., 4-N to signal the detected ATTACK computer attack and ask them for help to resolve this attack (step E20).
  • the DOTS request sent is for example a DOTS “Request Mitigation” request known from the state of the art, similar or identical to the request given by way of illustration in table 1. It is sent by the client device 3 to everyone. server devices 4-1, ..., 4-N or only to server devices among server devices 4-1, ..., 4-N protecting the resources targeted by the attack or involved in the routing of traffic from the attack to the computer domain 2. This sending can be done in parallel to each of the server devices or sequentially.
  • the server (s) device (s) contacted (step F10) by the client device 3, and which is (are) able to process this attack (“yes” response).
  • "In test step F20) acknowledges the attack mitigation request received from the client device 3 by sending it a DOTS" 2.01 Created “message (step F30).
  • the server device has the functional capacity (that is to say it knows the attack, knows how to identify it and to mitigate it) and has the material and / or software resources (in appropriate quantity) to treat and mitigate it.
  • Each server device of a protection service capable of processing the attack also sets up a mitigation plan to process the traffic intended for the IT domain 2 of which it has visibility (in other words intended for or passing through the resources of the computer domain 2 for which it ensures the protection) (step F40). It informs the client device 3 that it has successfully implemented a mitigation plan against the attack.
  • the protection service SP1 is able to process the attack, successfully sets up a mitigation plan against this attack and informs the client device 3 thereof.
  • one of the protection services contacted is not able to process this attack (response "no" to test step F20), it informs the client device 3 by sending it by example an error message such as a DOTS message “5.03 (Service Unavailable)” (step F70).
  • the protection service SP2 is not able to process the attack, and informs the client device 3 thereof.
  • the client device 3 requests the protection service (s) having set up a mitigation plan against the attack (“SPk / ATTACK OK” branch) to provide it with this. (s) mitigation plan (step E30). To this end, it sends for example, to each server device concerned, a DOTS GET request containing an attribute (“Uri-Path”) newly introduced for the needs of the invention and called here “mplan”.
  • Uri-Path an attribute
  • An example of such a query is provided by way of illustration in Table 3 below.
  • the request can include an attack mitigation identifier, "mid” (for "Mitigation IDentifier”), here assumed equal for the ATTACK attack to "12332". If this identifier is not entered in the request then, in the embodiment described here, the server device must communicate all the mitigation plans of all the mitigation actions being executed by the associated protection service. .
  • the server device On receipt of this request (step F50), the server device supplies the client device 3, via its supply module 4B, with the technical characteristics of the mitigation plan set up against the ATTACK attack (or of all mitigation plans being executed if no attack mitigation identifier is specified in the GET request (step F60).
  • the mitigation plan is provided in the form of a list (which can be ordered) comprising one or more rules, each rule defining (that is to say characterizing) the traffic that one wishes to treat (for example the traffic identified as suspect), and the action (s) to be applied to the traffic characterized by the rule.
  • Such actions are, for example, a rejection of the traffic defined by the rule associated with the action, a redirection of the traffic, a limitation of the traffic flow, etc.
  • the mitigation plan is provided in the "mpian” attribute, in the body of the response.
  • the "mpian” attribute can be structured according to a formalism similar or identical to that of the ACLs (Access Control Lists) defined in the specification of the DOTS protocol, or according to an ECA chronology (Event, Condition, Action), etc.
  • ACLs Access Control Lists
  • ECA chronology Event, Condition, Action
  • the plan described in table 5 contains an ACE entry (for “Access Control Entry”), that is to say a filtering action whose name is “ruiel”: this action consists in rejecting (as 'indicates the "forwarding” clause positioned at "drop” to reject without notification to the source) all the traffic defined by the attribute "matches”, namely here the traffic sent from any address of the network associated with the prefix " 192.0.2.0/24 "and intended for the resources associated with the prefix” 1.2.3.0/24 ".
  • a mitigation plan can alternatively include several ACE inputs; indeed, distinct actions such as redirection, rate reduction, etc. can be executed by the same mitigation service in response to an attack.
  • a mitigation plan can also or as a variant, comprise one or more information making it possible to implement assistance provided by a protection service for the treatment of an attack.
  • the client device 3 stores locally, for example in its non-volatile memory 8, all the mitigation plans received from the protection services competent to process the ATTACK attack in association with the server devices and / or the protection services itself. having provided these plans (step E40).
  • mplan (SPk, mid # j) denotes the mitigation plan set up by the protection service SPk (and its server device 4-k) in response to the attack identified by the attack mitigation identifier mid # j, j designating an integer greater than 1. It is noted that distinct mitigation identifiers can be used for the same attack to facilitate the management of the mitigation plans during or after their execution.
  • the protection service SP2 is unable to process the ATTACK attack falling within its scope of action (“SPk / ATTACK NOK” branch).
  • the server device 4-2 of the protection service SP2 notifies the client device 3 of this inability during step F750 described above by sending it an error message in response to its “5.03 (Service Unavailable)” mitigation request.
  • the error message “5.03 (Service Unavailable)” advantageously comprises, in a “status” parameter introduced in the specification of the DOTS protocol for the needs of the invention, the cause of the error. .
  • the ATTACK attack is unknown to the SPkO protection service, in other words, it does not have the means to identify the traffic of the attack and / or does not know how to deal with this attack.
  • the SPkO protection service is therefore not capable of implementing an adapted mitigation plan in response to the detected attack. This reason is codified in the error message by a "status" parameter valued for example at "unknown-attack"; or
  • the SPkO protection service is aware of the attack but suffers from insufficient resources available to mitigate the attack (capacity problem, due to lack of adequate resources and / or resources in sufficient quantity to mitigate the attack, for example if it is of great magnitude). This reason is then codified in the error message by a “status” parameter having for example the value “attack-exceeded-capacity”.
  • the client device 3 can in this way detect, by means of its determination module 3A, not only the inability of the protection service SP2 to process the ATTACK attack, but also to determine the cause of this inability by examining the value of the “status” parameter included in the error message received from the server device 4-2 (step E50).
  • the client device 3 can detect this incapacity other than by information received directly from the server device 4-2.
  • the client device 3 can detect (directly or indirectly through information received from another entity in the IT domain 2 or by an external entity) that the IT domain 2 is still receiving the attack traffic. from resources protected by the protection service SP2 while an explicit mitigation request has been issued by the client device 3 to the latter, etc.
  • the client device 3 selects in its non-volatile memory 8 one of these mitigation plans (step E70).
  • the client device 3 has requested the protection services by means of the GET request to obtain their mitigation plans as soon as the attack is detected.
  • it can send the GET request upon detection of the inability of the SP1 protection service to set up a mitigation plan (this can make it possible to have a more up-to-date version of the mitigation plan if the attack has progressed for example), or following the detection of the attack and following the detection of the incapacity of the SP1 protection service, or even periodically, etc.
  • No limitation is attached to the number of times or to the times when the client device 3 can request the protection services to know the mitigation plans that they are carrying out.
  • the client device 3 adapts the mitigation plan provided by the protection service SP1 so that it applies resources protected by the SP2 protection service.
  • Table 7 shows in bold characters the adaptation carried out by the client device 3 to develop a mitigation plan adapted to the protection service SP2 (change in the identification of the resources targeted by the attack).
  • the client device 3 can select any one of these plans (randomly, or the first provided , or the one corresponding to a particular protection service (for example the most attractive in terms of cost), etc.), aggregate the different plans received, or as a variant take into account a predetermined selection criterion, such as for example the mitigation plan that requires the least adaptation to be able to suit the incapable protection service.
  • the client device 3 transmits it via its transmission module 3C and its communication means 9 to the protection service SP2 in capable and more particularly to the server device 4-2 belonging to the protection service SP2 (step E90). For this purpose, it can send to the server device 4-2 a DOTS “Request Mitigation” miti gation request as described previously comprising the mitigation plan g (mplan (SP1)).
  • the inability of the protection service SP2 comes from an ignorance of the ATTACK attack (branch (I) in FIG. 5), but the attack falls only within the scope of action of the incapable SP2 protection service (in other words the resources targeted by the ATTACK attack or involved in the routing of the traffic of the AT TACK attack are protected by a single protection service among the plurality of protection services SP1, ..., SPN protecting the resources of the computer domain 2, namely SP2) (response "no" to step E60), then this means that none of the protection services requested from among the most of the protection services during step E30 did not set up an effective mitigation plan against the ATTACK attack and a fortiori did not provide such a mitigation plan to the client device 3 during step E40 . In other words, the client device 3 does not have in its non-volatile memory 9 any already “known” mitigation plan against the ATTACK attack.
  • the client device 3 sends to at least one of the protection services SPk, k12, protecting resources of the computer domain 2, and more particularly to the server device 4- k from this protection service, a request to emulate the ATTACK attack on the resources protected by this protection service and to obtain a mitigation plan set up as part of this emulation by the protection service in response to the ATTACK attack (step E100).
  • DOTS mitigation request "Request Mitigation” as described previously in which the client device 3 inserts an attribute, newly defined for the needs of the invention (named for example “emulate "), Requiring an emulation of the ATTACK attack, and the mplan attribute requiring the mitigation plan proposed, if necessary, by the protection service during the emulation.
  • the “emulate” attribute can be used for other purposes, for example for purposes of stress testing in the IT domain 2, not detailed further here.
  • the emulation of the attack is carried out on the resources of the computer domain 2 protected by the protection service executing the emulation.
  • the mitigation request sent by the client device 3 to the server device of the protection service must therefore be adapted. ted to be compatible with the perimeter of the protection service to which it is addressed.
  • the target addresses of the attack mentioned in the request must be those of resources protected by the protection service and validated with the latter.
  • Such an address validation mechanism is known in the context of the DOTS protocol and is not described in detail here.
  • FIG. 7 illustrates the main steps implemented by the protection service SP1 on receipt of this request, and more particularly here by the 4D emulation module of its server device 4-1.
  • the server device 4-1 On receipt of the emulation request (step G10), the server device 4-1 triggers the emulation of the ATTACK attack on the resources that it protects (step G20).
  • Such an emulation consists in reproducing the ATTACK attack undergone by the computer domain 2 according to the characteristics provided by the client device 3 in the emulation request, and in particular in generating a similar attack traffic.
  • the server device can for this purpose rely on a library of attack traffic collected over time.
  • the server device 4-1 derives from this simulation of the actions appropriate mitigation measures in response to this attack.
  • the mplan_emul (SPl) mitigation plan, if applicable, developed during emulation is then supplied to the client device 3 in response to its emulation request (step G40).
  • the server device 4-1 in informs the client device 3 by sending in response to its emulation request an error message as described above (step G50).
  • the client device 3 examines the response (s) received to its emulation request (depending on whether one or more protection services have been contacted to emulate the attack. ) (test step E1 10), in other words in the illustrative example considered here, the response of the protection service SP1.
  • the client device 3 then works out from this mitigation plan (or from one of the mitigation plans received and selected for example arbitrarily or according to the wealth of information contained in the mitigation plans received), a mitigation plan intended for the incapable protection service, SP2 in the example considered.
  • the client device 3 develops from the mplan_emul (SPl) plan a plan g (mplan_emul (SPl)): it does this in the same way as what was described previously for the 'step E80.
  • the plan thus prepared g (mplan_emul (SP1)) is then transmitted to the server device 4-2 of the protection service SP2 (step E90).
  • the client device 3 can reiterate its requests by providing more details on the attack or by sending captures of the traffic of attack on protection services.
  • the server device 4-2 sets up, in response to the ATTACK attack , a mitigation plan for this attack derived from the mitigation plan g (mplan (SPl)) or g (mplan_emul (SPl)) received from the client device 3 (step F90).
  • the mitigation plan put in place can be identical to the plan received from the client device 3, be prepared by the server device 4-2 from all or part of the information (mitigation rules and actions in particular) contained in the mitigation plan received from the client device 3, or be inspired by the logic of the plan received.
  • the invention is not limited to an execution as such by the server device 4-2 of the mitigation plan received from the client device 3, but also includes a suitable version thereof.
  • the client device 3 is informed thereof. (either by the server device 4-2 directly, or by another means), and can then develop and communicate to the server device 4-2 another mitigation plan derived from a mitigation plan provided by a protection service other than the protection service SP1.
  • the branch (I) of FIG. 5 which has just been described refers to a functional inability of the protection service SP2 to process the ATTACK attack targeting the resources of the computer domain 2 that it protects, and to the assistance provided by the client device 3 to the protection service SP2 to deal with the ATTACK attack in the event of such a functional incapacity.
  • the inability of the protection service SP2 can alternatively stem from a capacity insufficiency, in other words, the protection service SP2 does not have sufficient resources to mitigate the attack, for example because it is of great magnitude.
  • the client device 3 on receipt of the error message transmitted by the server device 4-2, interrogates at least one other protection service among the protection services SP1 , ..., SPk, ..., SPN, k12, protecting resources of computer domain 2, to determine whether it is able to provide capacity assistance to the protection service SP2 to mitigate the ATTACK attack (step E120) .
  • it sends, in the embodiment described here, to at least one of the protection services SP1, ..., SPk, ..., SPN, k12, a DOTS assistance request.
  • this assistance request is sent to the protection service SP1 and more particularly to its server device 4-1. It should be noted that such a request does not exist in the current version of the DOTS protocol and needs to be defined for the needs of the invention.
  • Such a request is for example named “Request Assisted Mitigation”.
  • the body of the request for assistance “Request Assisted Mitigation” comprises in particular the following attributes:
  • the server device 4-1 On receipt of such a request for assistance by the server device 4-1, the latter checks whether the protection service SP1 has the capacity necessary for setting up the required assistance. If such is the case and if the protection service SP1 agrees to provide this assistance, the server device 4-1 responds to the client device 3 with a DOTS response message "2.01 Created", in which it includes information for the establishment of the assistance offered by the SP1 protection service.
  • an attribute named for example “Scrubbing_Endpoint (s)” is included in the body of the response message and contains the IP address or addresses (or the domain name or names) of the entity or entities with which the server device 4-2 can establish a communication to benefit from the assistance provided by the protection service SP2 to resolve the ATTACK attack.
  • Such an entity is for example a cleaning center (more commonly called a “scrubbing center”) of the protection service SP1 in charge of filtering all or part of the suspicious traffic which reaches it.
  • Other information may be included in the response, such as for example a capacity available at the level of the protection service providing its assistance, one or more security keys intended to be used during this assistance (for example in the framework of a secure communication tunnel established between the incapacitated protection service and the protection service providing its assistance), a lifetime of the assistance provided by the protection service, etc.
  • the client device 3 On receipt of the information provided by the protection service (s) declaring itself capable of providing assistance to the protection service SP2 unable to process the attack, the client device 3 stores them in its non-volatile memory 9 (step E130) . It should be noted that depending on the lifetime associated, if applicable, with the assistance offered by the protection services, this information is intended to be used to process the ATTACK attack and to provide assistance to the SP2 protection service unable to. process the ATTACK attack, but also if necessary later for this same protection service or another.
  • step E140 it develops, by means of its development module 3B, a mitigation plan intended for the protection service SP2 using the assistance of one or more protection services having declared themselves capable of providing. such assistance.
  • this mitigation plan includes the information provided by the protection service SP1 to establish a communication between the protection service SP2 and the protection service SP1 in order to allow it to benefit from the assistance of the protection service SP1. for the mitigation of the ATTACK attack. If several protection services have responded favorably to provide assistance to the protection service SP2, the mitigation plan may include the information indicated to the client device 3 by all or part of these protection services capable of providing their assistance.
  • the mitigation plan comprising the information allows both the protection service SP2 to benefit from the assistance of one or more other protection services to mitigate the attack is transmitted by the client device 3 to the server device 4-1 of the protection service SP1 in a DOTS mitigation request “Request Mitigation” comprising in particular as attributes the mitigation identifier of the attack “mid” and an attribute called “assist-on” comprising the information supplied by the protection service or services having offered their assistance in establishing a communication with him or them (SP1 here) (step E150).
  • DOTS mitigation request Mitigation comprising in particular as attributes the mitigation identifier of the attack “mid” and an attribute called “assist-on” comprising the information supplied by the protection service or services having offered their assistance in establishing a communication with him or them (SP1 here)
  • the server device 4-2 on receipt of this mitigation plan (step F80), the server device 4-2, by means of its installation module 4B, then sets up, in response to the ATTACK attack targeting the resources of the computer domain 2 that it protects, a mitigation plan for this attack derived from the mitigation plan received from the client device 3 (step F90).
  • This mitigation plan consists in particular of establishing a communication that can be secured (for example a secure tunnel) with the entity or entities of the SP1 protection service identified in the information provided in the mitigation plan (“scrubbing center” of the SP1 protection service) and to be redirected via the communication thus established, all or part of the suspicious traffic (ie, data suspected of being associated with the attack) to the scrubbing center of the SP1 protection service for treatment or filtering.
  • a communication that can be secured (for example a secure tunnel) with the entity or entities of the SP1 protection service identified in the information provided in the mitigation plan (“scrubbing center” of the SP1 protection service) and to be redirected via the communication thus established, all or part of the suspicious traffic (ie, data suspected of being associated with the attack) to the scrubbing center of the SP1 protection service for treatment or filtering.
  • the suspect traffic redirected and routed to the protection service SP1 is then processed by the latter. Traffic considered legitimate can be returned to the protection service SP2 or be routed directly to the IT domain 2 by the protection service SP1.
  • the client device 3 requests the protection services SP1,
  • the client device 3 can preconfigure the assistance likely to be provided by the protection services SP1, ..., SPN.
  • the client device 3 can optionally also include in the request an estimate of the capacity necessary for the assistance required. Such an estimate can be carried out by means of a heuristic based on the analysis of SNMP (Simple Network Management Protocol) or NETCONF counters making it possible to estimate the volume of data packets exchanged over a network.
  • the sending of this request to the protection services can be done simultaneously or sequentially.
  • a server device of a protection service concerned On receipt of this request by a server device of a protection service concerned, the latter checks whether it has the necessary capacity for setting up such assistance, as described above. If the assistance request is accepted by the protection service, the server device responds with a “2.01 Created” message, including in the body of the response the information described previously allowing communication with the protection service to be established. A lifetime of the support offered may also be included in the response message. The reception and storage of this information by the client device 3 in its non-volatile memory 9 completes the pre-configuration of the assistance.
  • the client device 3 can then, as soon as the “Request Mitigation” is sent to the protection services protecting the resources. affected by the attack, request the intervention of these protection services while including in the request the preconfigured assistance offer offered by the protection services (in other words, the information transmitted by the latter to allow establishing a communication with them for the purpose of providing this assistance), as long as it still has a valid lifespan.
  • each mitigation service executes a mitigation plan by putting in place countermeasures against the attack. If it is unable to process the suspect traffic for capacity reasons, it can thus redirect part of the excess traffic to one or more protection services which have offered its assistance.
  • the failing protection service can redirect excess suspicious traffic that it cannot handle to a supporting protection service. This excess is then managed by the protection service providing assistance, while legitimate traffic can be returned to the failing protection service or be taken directly to IT domain 2.
  • the invention therefore generally makes it possible to provide assistance to a faulty protection service by relying on the other protection services protecting the resources of the computer domain 2, whatever the reason for this failure.
  • a capacitor-type failure or a functional failure has been mentioned, however these examples are not limiting in themselves and other types of failures can be envisaged.
  • the client device 3 is also able, when the attack falls within the scope of action of several protection services among the protection services SP1, ..., SPN, to check the compatibility of the mitigation plans put in place by each of the protection services concerned by the attack, and to coordinate, if necessary, the consistency of these mitigation plans between them .
  • the client device 3 at the end of step E30, when the client device 3 has been informed of all the mitigation plans put in place by the protection services concerned by the attack, it can check whether the plans mitigation methods obtained are compatible with each other in order to treat the ATTACK attack.
  • An example of incompatibility is the creation of a routing loop by the association of uncoordinated mitigation plans set up by several protection services.
  • a routing loop is created: legitimate traffic can no longer be routed to the CL client domain. However, this routing loop is not detectable by the DPS1 and DPS2 protection services.
  • the client device 3 has at the end of step E40 mitigation plans put in place by the various protection services in response to the ATTACK attack, the client device 3 has the possibility of detecting such a routing loop, or more generally an incompatibility between the mitigation plans put in place.
  • the client domain CL can also detect such an anomaly by observing the traffic entering / leaving the computer domain 2 (a routing loop as described above can typically manifest itself by an absence of traffic entering the domain. computer science).
  • the client device 3 coordinates, in a particular embodiment, an adjustment of all or part incompatible mitigation plans so as to eliminate the incompatibility. To this end, it can proceed, for example, according to one or other of the following variant embodiments.
  • the client device 3 selects at least one of the “conflicting” protection services (for example SPkl) and notifies the server device (4-kl) of the latter of the incompatibility. between mitigation plans (for example the existence of a routing loop).
  • the notified protection service can be arbitrarily selected from among the conflicting protection services, or it is conceivable to select, for example, the one presenting the plan. least effective mitigation.
  • the client device 3 can send it a mitigation DOTS request with an attribute, newly introduced in the DOTS protocol for the purposes of the invention, named here “Thirdparty-dps-conflict” aiming to require an adjustment, in other words an update, of the mitigation plan proposed by the protection service in question (SPkl here).
  • This request may also contain elements necessary to identify the conflict, such as for example all or part of the mitigation plans that are incompatible with that of the protection service in question (typically the conflicting rules and actions).
  • the 4-kl server device modifies its mitigation plan to avoid the incompatibility and transmits its modified plan to the client device 3.
  • the client device 3 checks whether the incompatibility is effectively resolved and whether none further incompatibility was created due to the adjustment of the SPkl protection service plan.
  • the client device 3 notifies all the server devices of the protection services involved in the incompatibility detected to ask them to adjust their mitigation plans. In the illustrative example considered above, it thus notifies the 4-kl and 4-k2 server devices. For this purpose, it can use a mitigation request with a “thirdparty-dps-conflict” attribute as described above.
  • each server device On receipt of this request, each server device makes an adjustment to its mitigation plan to resolve the detected incompatibility and transmits its adjusted mitigation plan to the client device 3.
  • the client device 3 checks the compatibility of the control plans. mitigation adjusted and in case of incompatibility proceeds again according to the first variant or the second variant.
  • the invention thus offers an efficient solution making it possible to enhance the use of a plurality of protection services to protect the resources of a client IT domain. It is applied in an advantageous but nonlimiting manner when the protection services are managed by separate administrative entities. This invention is advantageously based on the visibility available to the client IT domain to coordinate the actions of the protection services.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer Hardware Design (AREA)
  • Computing Systems (AREA)
  • General Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Business, Economics & Management (AREA)
  • General Business, Economics & Management (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Computer And Data Communications (AREA)

Abstract

Procédé d'assistance pour la gestion d'une attaque informatique, dispositif et système associés Le procédé d'assistance selon l'invention est mis en œuvre par un dispositif (3) gérant des ressources d'un domaine informatique (2), ces ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ce procédé comprenant : - une étape de détermination d'une incapacité d'un premier service de protection parmi ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique; - une étape d'élaboration d'un plan de mitigation de ladite attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection parmi ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection; et - une étape de transmission du plan de mitigation élaboré au premier service de protection pour traiter l'attaque.

Description

Description
Titre de l'invention : Procédé d'assistance pour la gestion d'une attaque informatique, dispositif et système associés.
Technique antérieure
[0001] L'invention se rapporte au domaine général des télécommunications.
[0002] Elle concerne plus particulièrement la résolution d'attaques informatiques susceptibles d'affecter les ressources d'un domaine informatique bénéficiant d'une connectivité au réseau public Internet.
[0003] L'invention s'applique notamment aux attaques informatiques de type déni de service (DoS, (pour « Déniai of Service » en anglais) ou DDoS (pour « Distributed DoS » en anglais). Une attaque DoS est une tentative de rendre des ressources d'un domaine informatique, telles que par exemple des ressources réseau ou de calcul, indisponibles pour leurs utilisateurs.
[0004] Les attaques DDoS sont souvent massives et de nature à compromettre plusieurs centaines de milliers d'équipements utilisateurs (terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, etc.), qui peuvent à leur tour être utilisés comme relais pour amplifier le pouvoir de nuisance de ces attaques. A titre indicatif, la société Symantec, dans son rapport annuel de 2019, fait état de près de 24000 applications embarquées dans des terminaux mobiles bloquées quotidiennement par de telles attaques, d'une augmentation de 600% entre 2016 et 2017 des attaques ciblant des objets connectés, et d'une augmentation de la volumétrie du trafic d'attaque entre 2016 et 2017 qui représentait 5% du trafic web global en 2016 contre 7.8% en 2017.
[0005] Les attaques DDoS sont de plus en plus fréquentes et intenses, et peuvent cibler plusieurs centaines de milliers de machines informatiques. Pour protéger leurs ressources informatiques contre de telles attaques, de nombreuses sociétés souscrivent à des offres de services de protection DPS (pour « DDoS Protection Services » en anglais). Toutefois, lorsqu'autant de machines sont impliquées dans l'exécution des attaques, la mise en place de politiques de filtrage adaptées, c'est-à- dire capables d'isoler le trafic en provenance de l'ensemble des machines affectées, est d'autant plus compliquée que ces machines peuvent être réparties sur plusieurs réseaux distincts. Ces réseaux sont eux-mêmes susceptibles d'être protégés par des offres DPS distinctes proposées et gérées par des entités administratives distinctes (indépendantes).
[0006] La figure 1 représente, à titre illustratif, un domaine informatique client CL connecté à deux réseaux transitaires TN1 et TN2 lui fournissant un accès au réseau Internet. Chacun des réseaux transitaires héberge un service de protection DPS dédié, référencé par DPS1 pour le réseau transitaire TN1 et par DPS2 pour le réseau transitaire TN2. On suppose, dans l'exemple envisagé à la figure 1, que le domaine client CL utilise pour ses liens d'interconnexion avec les réseaux transitaires TN1 et TN2 des adresses dites PI (pour « Provider-Independent » en anglais) : un même plan d'adressage est ainsi utilisé par le domaine client CL sur l'ensemble de ses liens d'interconnexion avec les réseaux transitaires TN1 et TN2, indépendamment du plan d'adressage utilisé par ces réseaux transitaires.
[0007] Il convient par ailleurs de noter que de plus en plus d'offres de protection DPS s'appuient sur des services hébergés dans le « cloud » et pas seulement au sein des infrastructures exploitées par les fournisseurs d'accès au réseau Internet. Ces déploiements dans le cloud posent des problèmes techniques notamment concernant la détection anticipée des attaques car les composantes du service DPS impliquées dans la détection ou la résolution d'attaques et hébergées dans le cloud ne sont pas forcément présentes sur les différents chemins empruntés par le trafic d'attaque, de sorte qu'elles ne sont pas en mesure d'inspecter et de filtrer ce trafic.
[0008] Les considérations précédentes ne se limitent pas bien entendu aux attaques DDoS, et restent valables pour d'autres types d'attaques, telles que des attaques par usurpation d'identité (par exemple à des fins de vol de données), des malwares de rançonnage (ou « ransomware » en an glais), etc.
[0009] Les attaques informatiques subies par les systèmes informatiques aujourd'hui sont donc protéi formes, tant par leur nature que par leur dimensionnement (volumétrie du trafic de l'attaque, am plitude de l'attaque, etc.) et leur portée de nuisance (une seule machine visée, ou plusieurs en vi sant le réseau local d'une entreprise, le réseau d'un opérateur, etc.). Les cibles de ces attaques ou les relais utilisés pour les propager sont en outre extrêmement variés : terminaux fixes ou mobiles, objets connectés, serveurs, ressources réseau, etc.
[0010] Il s'ensuit que certains services de protection contre les attaques informatiques (services DPS ou autres suivant les attaques subies) peuvent rencontrer des difficultés pour traiter et mitiger ces at taques.
[0011] Ainsi, certains services de protection peuvent avoir une capacité de traitement et de mitigation li mitée et ne pas être en mesure de traiter les attaques de forte amplitude ou correspondant à une volumétrie de trafic infecté dépassant un certain seuil. En effet, en plus de sa fonction de mitiga tion, un service de protection contre des attaques informatiques doit assurer la coordination des opérations d'acheminement du trafic vers le domaine informatique client qu'il protège, pour que le trafic légitime à destination de ce dernier soit acheminé normalement vers celui-ci. Pour ce faire, le service de protection doit identifier le trafic suspect puis l'isoler pour qu'il ne soit pas acheminé vers le domaine informatique client. A cet effet, il peut s'appuyer sur un centre ou une fonction dite de nettoyage (ou « scrubbing » en anglais), qui peut s'avérer sous-dimensionnée pour traiter des attaques sollicitant des ressources CPU (Central Processing Unit) ou capacitaires conséquentes. L'efficacité de la mitigation mise en œuvre par le service de protection est alors diminuée et le do maine informatique client continue de subir l'attaque en dépit de l'intervention du service de pro tection.
[0012] D'autres services de protection peuvent avoir une carence fonctionnelle en termes de détection et de mitigation de nouvelles attaques et échouer à mettre en place un plan de mitigation efficace contre de telles attaques, parce qu'ils ne disposent pas de mécanismes de détection et d'identifica tion du trafic caractéristiques de ces attaques, par exemple. Les attaques les plus récentes sont en effet de plus en plus complexes à caractériser car elles peuvent faire intervenir des millions de sources, adopter une stratégie d'attaque dynamique telles que l'exploitation de plusieurs proto coles, etc.
[0013] Ces carences capacitaires ou fonctionnelles des services de protection peuvent avoir un impact non négligeable sur la mitigation (incluant le délai nécessaire à mettre en place les actions de mitiga tion) d'une attaque ciblant les ressources d'un domaine informatique client. A titre illustratif, consi dérons l'exemple de la figure 1.
[0014] Sur détection d'une attaque au sein du domaine informatique client CL et affectant en particulier l'ensemble des liens d'interconnexion raccordant le domaine client CL aux réseaux transitaires TN1 et TN2 (on note que ces liens sont impliqués dans l'acheminement du trafic de l'attaque mais ils ne sont pas forcément la cible de l'attaque), un agent AG du domaine informatique client CL sollicite les deux services de protection DPS1 et DPS2 pour la mitigation de l'attaque.
[0015] On suppose ici que le service DPS1 met en œuvre rapidement un plan de mitigation efficace car il dispose de mécanismes de détection et de mitigation adaptés au type d'attaque en cours, alors que le service DPS2 échoue à mettre en place un plan de mitigation efficace, par exemple parce qu'il ne dispose pas de mécanisme de détection et d'identification du trafic caractéristique de cette attaque. Le trafic de l'attaque est alors bloqué par le réseau transitaire TN1, mais continue d'être acheminé jusqu'au domaine client CL via le réseau transitaire TN2. Ainsi, le domaine client CL est toujours victime de l'attaque en dépit du plan de mitigation mis en place par le système DPS1.
[0016] On note qu'une attaque similaire peut être mise en œuvre si le domaine client CL utilise des adresses dites PA (Provider-Aggregatable), c'est-à-dire si les adresses utilisées sur les liens d'inter connexion qui raccordent le domaine client CL aux réseaux transitaires TN1 et TN2 sont celles four nies par chacun des fournisseurs de connectivité qui exploitent ces réseaux transitaires TN1 et TN2.
Exposé de l'invention
[0017] L'invention permet notamment de remédier aux inconvénients de l'état de la technique en propo sant un procédé d'assistance mis en œuvre par un dispositif gérant des ressources d'un domaine informatique, lesdites ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ce procédé comprenant :
- une étape de détermination d'une incapacité d'un premier service de protection parmi ladite plu ralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique ;
- une étape d'élaboration d'un plan de mitigation de l'attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection de la pluralité de services de protection ou utilisant une assis tance fournie par au moins le deuxième service de protection ; et
- une étape de transmission du plan de mitigation ainsi élaboré au premier service de protection pour traiter l'attaque.
[0018] Corrélativement, l'invention vise aussi un dispositif gérant des ressources d'un domaine informa tique, configuré pour communiquer avec une pluralité de services de protection contre des at taques informatiques protégeant lesdites ressources du domaine informatique, ce dispositif com prenant :
- un module de détermination, configuré pour déterminer une incapacité d'un premier service de protection de la pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique;
- un module d'élaboration, configuré pour élaborer un plan de mitigation de ladite attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection de la pluralité de services de protection ou utilisant une assistance fournie par au moins le deuxième service de protection ; et
- un module de transmission, configuré pour transmettre le plan de mitigation ainsi élaboré au premier service de protection pour traiter l'attaque.
[0019] Ainsi, l'invention propose d'exploiter la souscription par le domaine informatique à une pluralité de services de protection (pouvant être notamment, pour tout ou partie d'entre eux, gérés par des entités administratives distinctes) pour fournir dynamiquement une assistance à un service de pro tection incapable de gérer une attaque informatique détectée dans le domaine informatique (pre mier service de protection au sens de l'invention, désigné aussi par la suite par « service de protec tion incapable »). Cette assistance se traduit sous la forme d'un plan de mitigation élaboré et fourni au service de protection incapable, à partir d'un plan de mitigation mis en place ou déter miné par un autre service de protection (deuxième service de protection au sens de l'invention) en réponse à l'attaque, permettant ainsi de remédier à une insuffisance fonctionnelle du service de protection incapable, ou s'appuyant sur l'assistance d'un autre service de protection (deuxième ser vice de protection au sens de l'invention), permettant ainsi de remédier à une insuffisance capaci- taire du service de protection incapable.
[0020] Dans la suite, on désigne par « plan de mitigation » un ensemble d'actions élaborées pour la réso lution d'une attaque. Ces actions ont pour but d'empêcher le trafic de l'attaque de se propager dans le domaine informatique. Il peut s'agir d'actions de mitigation à proprement parler mises en place ou élaborées par un service de protection, mais également inclure une assistance fournie par un service de protection pour étendre les capacités du service de protection incapable et lui per mettre de résoudre l'attaque, etc.
[0021] Aucune limitation n'est attachée à la nature des ressources qui peuvent être la cible d'une at taque ; il peut s'agir par exemple d'une adresse IP, d'un préfixe IP, d'une machine, d'un alias, d'un nom de domaine pleinement qualifié (FQDN pour Fully Qualified Domain Name en anglais), etc.
[0022] Ainsi, l'invention ne se limite pas à une application locale du plan de mitigation élaboré au sein du domaine informatique, application qui n'est pas toujours possible selon l'état des ressources affec tées par l'attaque ; mais elle prévoit également la transmission du plan de mitigation élaboré au service de protection incapable pour pallier ses carences. Cela permet, lorsque le service de protec tion protège des ressources telles que des liens d'interconnexion du domaine informatique avec le réseau Internet ou des réseaux transitaires, de bloquer de manière anticipée le trafic de l'attaque, en amont et/ou en entrée du domaine informatique client.
[0023] On note que l'invention n'est pas restreinte à un premier service de protection protégeant des res sources du domaine informatique ciblées par l'attaque. Elle peut également s'appliquer à un pre mier service de protection protégeant des ressources du domaine informatique impliquées dans l'acheminement du trafic de l'attaque vers les ressources ciblées par celle-ci. Ainsi, on envisage ici une attaque relevant du périmètre d'action du premier service de protection.
[0024] Ces considérations s'appliquent également au deuxième service de protection. On note toutefois que dans certains modes de réalisation décrits plus en détail ultérieurement, l'attaque peut ne pas relever du périmètre d'action du deuxième service de protection.
[0025] Avantageusement, conformément à l'invention, le plan de mitigation transmis au service de protec tion incapable est élaboré par un dispositif gérant les ressources du domaine informatique qui sont protégées par la pluralité de services de protection, aussi parfois désigné ici par « domaine client » ou encore « domaine informatique client ». Les services de protection pouvant être gérés par des entités administratives distinctes, ils n'ont pas nécessairement connaissance des actions de mitiga tion mises en œuvre par les autres services de protection protégeant des ressources du domaine client. Au contraire, le domaine client dispose d'une visibilité globale sur les actions mises en œuvre pour protéger ses ressources, et l'invention exploite avantageusement cette visibilité pour coordonner et améliorer l'efficacité des efforts de mitigation entrepris par les services de protection en présence d'une attaque détectée dans le domaine client. Il résulte de ce pilotage par le domaine client un meilleur temps de réaction et de traitement des attaques ainsi qu'une rapidité d'exécution accrue des actions de mitigation. On garantit de la sorte la continuité des services offerts par le domaine informatique.
[0026] A titre illustratif, dans l'exemple précédemment décrit en référence à la figure 1, en cas de carence fonctionnelle du service de protection DPS1, l'invention permet d'exploiter la connaissance de l'at taque par le service de protection DPS2 et d'un plan de mitigation efficace de celle-ci en élaborant et en fournissant au service de protection DPS1 un plan de mitigation élaboré à partir du plan de mitigation mis en œuvre par le service de protection DPS2. Ainsi, il est possible de bloquer effica cement l'attaque ciblant le domaine informatique puisque dès lors, les services de protection DPS1 et DPS2 protégeant les liens d'interconnexion du domaine client CL affectés par l'attaque sont en mesure de mettre en place des politiques de filtrage du trafic de l'attaque entrant dans le domaine client CL.
[0027] Grâce à l'invention, la gestion de l'attaque affectant le domaine informatique est donc améliorée, non seulement individuellement au niveau de chaque service de protection, mais également au ni veau de l'action globale menée par l'ensemble des services de protection. On note que cette amé lioration est avantageusement obtenue sans avoir à modifier ou à étendre la visibilité du trafic dont dispose chacun des services de protection. Concrètement, les différents services de protection con tinuent de n'avoir qu'une visibilité partielle du trafic associé au domaine client et non le trafic global dudit domaine client.
[0028] L'invention permet ainsi une résolution rapide, automatique et fiable des attaques informatiques susceptibles d'affecter les ressources d'un domaine informatique. Grâce à l'exploitation des actions de mitigation mises en œuvre par différents services de protection, l'invention offre la possibilité de traiter des attaques affectant l'ensemble des ressources du domaine informatique.
[0029] On note qu'aucune limitation n'est attachée à la nature des attaques informatiques concernées (déni de service, usurpation d'identité, ransomware, etc.), ni à la nature des ressources informa tiques du domaine impactées (ressources de calcul, ressources réseau, liens d'interconnexion avec d'autres réseaux, etc.).
[0030] Dans un mode particulier de réalisation :
- le deuxième service de protection a mis en place un plan de mitigation en réponse à l'attaque ;
- ladite incapacité du premier service de protection provient d'une méconnaissance de l'attaque par le premier service de protection ; et
- le plan de mitigation transmis au premier service de protection est élaboré en adaptant le plan de mitigation mis en place par le deuxième service de protection aux ressources du domaine informa tique protégées par le premier service de protection.
[0031] Ce mode de réalisation permet plus particulièrement de gérer une incapacité fonctionnelle du pre mier service de protection, alors que le deuxième service de protection est en mesure de traiter cette attaque et a mis en place un plan de mitigation efficace à cet effet. Le plan de mitigation fourni au premier service de protection est alors dérivé du plan de mitigation mis en place par le deuxième service de protection. On note que le plan de mitigation dérivé n'est pas forcément une copie à l'identique du plan de mitigation fourni par un premier service de protection. Il peut être inspiré de celui-ci et/ou reprendre et/ou adapter tout ou partie des actions indiquées dans celui-ci, pour tenir compte par exemple de contraintes qui sont propres au premier service de protection.
[0032] Dans un autre mode de réalisation, lorsque l'attaque relève du périmètre d'action du premier ser vice de protection uniquement et l'incapacité du premier service de protection provient d'une mé connaissance de l'attaque par le premier service de protection, le procédé comprend en outre :
- une étape d'envoi au deuxième service de protection d'une requête d'émulation de l'attaque sur au moins une ressource du domaine informatique protégée par le deuxième service de protection ; et
- une étape d'obtention d'un plan de mitigation proposé lors de l'émulation de l'attaque par le deu xième service de protection pour traiter cette attaque ; le plan de mitigation transmis au premier dispositif étant élaboré à partir du plan de mitigation ob tenu lors de l'étape d'obtention en l'adaptant aux ressources du domaine informatique protégées par le premier service de protection.
[0033] Ce mode de réalisation vise également à pallier une carence fonctionnelle du premier service de protection. Toutefois, il vise un contexte dans lequel l'attaque relève uniquement du périmètre d'action du premier service de protection (en d'autres termes, l'attaque vise des ressources du do maine informatique protégées par le premier service de protection ou celui-ci protège des res sources du domaine informatique impliquées dans l'acheminement du trafic de l'attaque vers les ressources ciblées par cette dernière). Le deuxième service de protection n'étant pas concerné di rectement par l'attaque affectant le domaine informatique, il n'a pas mis en place à proprement parler d'action de mitigation contre cette attaque. Cela ne l'empêche pas pour autant d'être en me sure de traiter cette attaque (autrement dit d'identifier le trafic de l'attaque et de savoir comment le filtrer efficacement), et c'est cette capacité qu'exploite l'invention dans ce mode de réalisation, en ordonnant au deuxième service de protection d'émuler l'attaque sur les ressources du domaine informatique qu'il protège et de proposer un plan de mitigation en réponse à cette attaque. [0034] Il convient de noter que le plan de mitigation proposé par le deuxième service de protection cor respond alors aux ressources du domaine informatique protégées par le deuxième service de pro tection (typiquement identifiées par des adresses ou préfixes IP dédiés), et non aux ressources protégées par le premier service de protection ciblées par l'attaque. L'élaboration d'un plan de miti gation destiné au premier service de protection consiste alors notamment en une adaptation par le dispositif gérant les ressources du domaine informatique du plan de mitigation proposé par le deu xième service de protection aux ressources protégées par le premier service de protection.
[0035] Dans un autre mode de réalisation, l'incapacité du premier service de protection provient d'une in suffisance de ressources disponibles au niveau du premier système de protection pour mitiger l'at taque, le procédé comprenant une étape d'obtention auprès du deuxième service de protection d'au moins une information permettant un établissement d'une communication entre le premier système de protection et le deuxième système de protection pour l'assister dans la mitigation de l'attaque, le plan de mitigation transmis au premier système de protection comprenant ladite au moins une information obtenue.
[0036] L'assistance fournie par le deuxième service de protection est alors dans ce mode de réalisation une assistance capacitaire pour traiter l'attaque, permettant de pallier à une insuffisance de res sources du premier service de protection pour résoudre l'attaque, par exemple en raison de l'ampli tude de l'attaque. Ce mode de réalisation permet d'étendre artificiellement les ressources du pre mier service de protection pour résoudre de manière efficace l'attaque. Grâce à la communication établie entre le premier et le deuxième service de protection, le premier service de protection peut par exemple rediriger une partie du trafic destiné au domaine informatique vers le deuxième ser vice de protection pour que celui-ci le filtre.
[0037] On peut bien entendu envisager d'établir une communication sécurisée entre les deux services de protection, par exemple au moyen d'un tunnel sécurisé.
[0038] On note en outre que l'assistance capacitaire fournie au premier service de protection peut prove nir de plusieurs services de protection parmi la pluralité de services de protection protégeant les ressources du domaine informatique.
[0039] Dans un mode particulier de réalisation, le procédé comprend :
- une étape d'interrogation de tout ou partie de la pluralité de services de protection protégeant des ressources du domaine informatique pour déterminer les services de protection aptes à fournir une assistance pour mitiger une attaque informatique à au moins un autre service de protection de la pluralité de services de protection ; et
- une étape de mémorisation, pour chaque service de protection se déclarant apte, d'au moins une information fournie par ce service de protection permettant une mise en œuvre de cette assistance.
[0040] L'interrogation peut se faire par exemple en amont de la détection d'une attaque. Ce mode de réa lisation permet d'anticiper les problèmes liés à une défaillance capacitaire de l'un des services de protection. A partir des informations mémorisées, lorsqu'il est informé d'une telle défaillance, le dispositif gérant les ressources du domaine informatique client peut agir plus rapidement pour mettre en place une assistance auprès du service de protection défaillant.
[0041] En variante, l'étape d'interrogation peut être mise en œuvre suite à la détection d'une attaque ci blant au moins une ressource du domaine informatique.
[0042] Ce mode de réalisation permet d'obtenir des informations à jour, représentatives d'un état courant des services de protection aptes à fournir leur assistance.
[0043] Les informations fournies par les services de protection aptes à fournir une assistance peuvent être de différentes natures. Elles comprennent par exemple au moins un élément parmi :
- une capacité disponible au niveau dudit service de protection apte à fournir une assistance et utilisée par ladite assistance, de façon à faciliter la sélection d'un service de protection approprié pour fournir une assistance à un service de protection défaillant ; - une information permettant l'établissement d'une communication avec ledit service de protection apte à fournir une assistance ;
- au moins une clé de sécurité destinée à être utilisée lors de ladite assistance avec le service de protection apte à fournir une assistance, ou tout autre élément permettant de sécuriser la communication entre le service de protection apte à fournir une assistance et le service de protection défaillant ;
- une durée de vie de l'assistance fournie par ledit service de protection apte à fournir une assistance. De la sorte, lorsque cette durée de vie a expiré, le dispositif du domaine informatique client se tourne vers un autre service de protection et le service de protection qui n'est plus apte à fournir une telle assistance n'est pas sollicité inutilement.
[0044] Cette liste n'est bien entendu pas limitative.
[0045] Dans un mode particulier de réalisation, lors de l'étape d'interrogation, le dispositif indique aux services de protection interrogés une capacité minimale dont doit disposer un service de protection se déclarant apte pour fournir l'assistance.
[0046] Pour évaluer cette capacité minimale, le dispositif peut s'appuyer sur des mécanismes de prévision de trafic (ou « traffic forecast » en anglais), connus en soi. Cette capacité minimale peut être ensuite réévaluée au cas par cas suivant les besoins d'un service de protection défaillant.
[0047] Ce mode de réalisation permet d'éviter la sélection par le dispositif du domaine informatique client d'un service de protection n'ayant pas des ressources capacitaires suffisantes pour fournir une assistance à un service de protection défaillant, et donc une perte de temps dans l'exécution du procédé selon l'invention.
[0048] Dans un mode particulier de réalisation, le procédé comprend, après détection de l'attaque, une étape d'envoi à tout ou partie des services de protection de la pluralité de services de protection ayant un périmètre d'action dans lequel se trouve au moins une ressource du domaine informatique ciblée par l'attaque, d'une requête d'obtention d'un plan de mitigation mis en place par ces services de protection en réponse à l'attaque.
[0049] Autrement dit, dans ce mode de réalisation, les services de protection fournissent leurs plans de mitigation mis en place le cas échéant contre l'attaque détectée, en réponse à une sollicitation du dispositif du domaine informatique client.
[0050] En variante, on peut envisager la mise en place d'un mécanisme d'annonce spontanée par les services de protection des plans de mitigation en cours d'exécution. Le dispositif gérant les ressources du domaine informatique peut à cet effet par exemple s'inscrire auprès de chaque service de protection pour être informé par celui-ci des plans de mitigation qu'il met en place.
[0051] Dans un mode particulier de réalisation, lorsque l'attaque cible des ressources protégées par plusieurs services de protection de la pluralité de services de protection, le procédé comprend :
- une étape de vérification de la compatibilité des plans de mitigation mis en place en réponse à ladite attaque par lesdits plusieurs services de protection ; et
- si au moins une incompatibilité est détectée entre des plans de mitigation lors de l'étape de vérification, une étape de coordination d'un ajustement de tout ou partie des plans de mitigation incompatibles de sorte à éliminer ladite au moins une incompatibilité.
[0052] Le dispositif gérant les ressources du domaine informatique client coordonne ainsi les actions de mitigation mises en place par les différents services de protection concernés par l'attaque (autrement dit, dans le périmètre d'action dont relève l'attaque) de sorte à éviter des incohérences entre ces actions.
[0053] En effet, comme mentionné précédemment, les services de protection étant susceptibles d'être gérés par des entités administratives distinctes, ils n'ont aucune visibilité mutuelle sur les actions mises en œuvre par les autres services de protection en présence d'une attaque, contrairement au domaine informatique client. Ainsi, un (ou plusieurs) service de protection peut prendre des décisions de mitigation qui peuvent avoir des implications négatives sur le service fourni au domaine informatique client, notamment parce qu'elles ne sont pas cohérentes avec d'autres décisions prises par un autre service de protection en réponse à l'attaque. Par exemple, des décisions prises par deux (ou plus) services de protection différents peuvent conduire à l'établissement d'une boucle de routage qui empêche le trafic légitime d'être acheminé vers le domaine informatique client.
[0054] Au vu de ce qui précède, il apparait que l'invention s'appuie sur le dispositif gérant les ressources du domaine informatique qui sont protégées par différents services de protection contre des attaques informatiques, mais également sur l'action de ces derniers.
[0055] Ainsi, selon un autre aspect, l'invention vise également un procédé d'obtention, par un premier service de protection d'une pluralité de services de protection contre des attaques informatiques protégeant des ressources d'un domaine informatique, d'un plan de mitigation d'une attaque informatique ciblant au moins une des ressources du domaine informatique, ce procédé comprenant, suite à une détection d'une incapacité du premier service de protection à traiter l'attaque :
- une étape de réception d'un plan de mitigation élaboré par le dispositif à partir d'un plan de mitigation obtenu d'un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins le deuxième service de protection ; et
- une étape de mise en place, en réponse à l'attaque, d'un plan de mitigation de l'attaque dérivé du plan de mitigation reçu du dispositif pour traiter l'attaque.
[0056] Corrélativement, l'invention concerne aussi un dispositif d'un premier service de protection d'une pluralité de services de protection contre des attaques informatiques protégeant des ressources d'un domaine informatique, au moins une des ressources du domaine informatique étant ciblée par une attaque informatique, ledit dispositif comprenant des modules activés suite à une détection d'une incapacité du dispositif à traiter l'attaque, ces modules comprenant :
- un module de réception, configuré pour recevoir un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique à partir d'un plan de mitigation obtenu d'un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et
- un module de mise en place, configuré pour mettre en place en réponse à ladite attaque un plan de mitigation dérivé du plan de mitigation reçu du dispositif pour traiter l'attaque.
[0057] Le procédé d'obtention et le dispositif du premier service de protection bénéficient des mêmes avantages cités précédemment que le procédé d'assistance et le dispositif du domaine informatique.
[0058] Dans un mode particulier de réalisation, l'étape de mise en place du plan de mitigation comprend, lorsque le plan de mitigation utilise une assistance fournie par au moins le deuxième service de protection, un acheminement de données suspectées d'être associées à l'attaque vers le deuxième service de protection pour un traitement de ces données.
[0059] Les données sont par exemple acheminées vers le deuxième service de protection via un tunnel sécurisé établi avec le deuxième service de protection au moyen d'informations contenues dans le plan de mitigation reçu du dispositif.
[0060] L'assistance fournie par le deuxième service de protection (et éventuellement d'autres services de protection) permet au premier service de protection de se délester d'une partie du trafic suspect qu'il n'est pas en mesure de traiter et de l'acheminer vers le deuxième service de protection pour qu'il applique un plan de mitigation approprié à ce trafic suspect.
[0061] Dans un mode particulier de réalisation de l'invention, le procédé d'assistance et/ou le procédé d'obtention sont mis en œuvre par un ordinateur. [0062] Dans un mode particulier de réalisation de l'invention, le procédé d'assistance et/ou le procédé d'obtention sont mis en œuvre par un ordinateur non directement connecté au domaine informa tique (par ex., un smartphone) mais apte à gérer les ressources dudit domaine informatique.
[0063] L'invention vise également un premier programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif gérant les ressources d'un domaine informatique client conforme à l'invention et com porte des instructions adaptées à la mise en œuvre d'un procédé d'assistance tel que décrit ci-des- sus.
[0064] L'invention vise aussi un deuxième programme d'ordinateur sur un support d'enregistrement, ce programme étant susceptible d'être mis en œuvre dans un ordinateur ou plus généralement dans un dispositif d'un premier service de protection contre des attaques informatiques conforme à l'in vention et comporte des instructions adaptées à la mise en œuvre d'un procédé d'obtention tel que décrit ci-dessus.
[0065] Chacun de ces programmes 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.
[0066] L'invention vise aussi un support d'information ou un support d'enregistrement lisibles par un ordi nateur, et comportant des instructions du premier, du deuxième ou du troisième programme d'ordi nateur mentionné ci-dessus.
[0067] Les supports d'information ou d'enregistrement peuvent être n'importe quelle entité ou dispositif capable de stocker les programmes. Par exemple, les supports peuvent comporter un moyen de stockage, tel qu'une ROM, par exemple un CD ROM ou une ROM de circuit microélectronique, ou encore un moyen d'enregistrement magnétique, par exemple un disque dur, ou une mémoire flash.
[0068] D'autre part, les supports d'information ou d'enregistrement peuvent être des supports transmis sibles tels qu'un signal électrique ou optique, qui peut être acheminé via un câble électrique ou op tique, par lien radio, par lien optique sans fil ou par d'autres moyens.
[0069] Les programmes selon l'invention peuvent être en particulier téléchargés sur un réseau de type In ternet.
[0070] Alternativement, chaque support d'informations ou d'enregistrement peut être un circuit intégré dans lequel un programme est incorporé, le circuit étant adapté pour exécuter ou pour être utilisé dans l'exécution du procédé de communication, conforme à l'invention, ou du procédé de sélection, conforme à l'invention.
[0071] L'invention vise aussi un système de protection d'un domaine informatique comprenant :
- une pluralité de services de protection contre des attaques informatiques protégeant des ressources du domaine informatique ;
- un dispositif gérant lesdites ressources du domaine informatique conforme à l'invention et configuré pour communiquer avec lesdits services de protection ; ladite pluralité de services de protection comprenant au moins :
- un premier service de protection comportant un dispositif selon l'invention incapable de traiter une attaque informatique ciblant au moins une ressource du domaine informatique ; et
- un deuxième service de protection ayant mis en place un plan de mitigation de ladite attaque ou apte à fournir une assistance au premier service de protection pour traiter ladite attaque sur lequel ledit dispositif gérant lesdites ressources du domaine informatique s'appuie pour élaborer et trans mettre audit premier service de protection un plan de mitigation de l'attaque.
[0072] Dans un mode particulier de réalisation, le deuxième service de protection comprend :
- un module d'émulation, activé sur requête du dispositif du domaine informatique lorsque l'attaque relève du périmètre d'action du premier service de protection uniquement, ledit module d'émulation étant configuré pour émuler ladite attaque sur au moins une ressource du domaine informatique protégée par le deuxième service de protection ; et
- un module de transmission, configuré pour transmettre au dispositif du domaine informatique un plan de mitigation de l'attaque proposé par le deuxième service de protection lors de l'émulation de ladite attaque par le module d'émulation.
[0073] Dans un mode particulier de réalisation, le deuxième service de protection comprend un module de fourniture, activé sur requête du dispositif gérant les ressources du domaine informatique lorsque ladite attaque se trouve dans le périmètre d'action du deuxième service de protection, ledit module de fourniture étant configuré pour fournir au dispositif gérant les ressources du domaine informatique un plan de mitigation mis en place par le deuxième service de protection en réponse à l'attaque.
[0074] Le système selon l'invention bénéficie des mêmes avantages cités précédemment pour le procédé d'assistance, le procédé d'obtention, le dispositif du domaine informatique et le dispositif du premier service de protection selon l'invention.
[0075] On peut également envisager, dans d'autres modes de réalisation, que le procédé d'assistance, le procédé d'obtention, le dispositif gérant les ressources du domaine informatique, le dispositif du premier service de protection et le système selon l'invention présentent en combinaison tout ou partie des caractéristiques précitées.
Brève description des dessins
[0076] D'autres caractéristiques et avantages de la présente invention ressortiront de la description faite ci-dessous, en référence aux dessins annexés qui en illustrent un exemple de réalisation dépourvu de tout caractère limitatif. Sur les figures :
[Fig. 1] la figure 1, déjà décrite, représente un domaine informatique protégé par deux services de protection contre des attaques informatiques, selon l'état de la technique ;
[Fig. 2] la figure 2 représente un système de protection d'un domaine informatique conforme à l'invention dans un mode particulier de réalisation ;
[Fig. 3] la figure 3 représente l'architecture matérielle d'un dispositif gérant les ressources du domaine informatique protégées par le système de protection de la figure 2, dans un mode particulier de réalisation ;
[Fig. 4] la figure 4 représente l'architecture matérielle d'un dispositif serveur d'un service de protection du système de protection de la figure 2, dans un mode particulier de réalisation ;
[Fig. 5] la figure 5 représente les principales étapes d'un procédé d'assistance selon l'invention telles qu'elles sont mises en œuvre, dans un mode particulier de réalisation, par le dispositif de la figure 3 ;
[Fig. 6] la figure 6 représente les principales étapes d'un procédé d'obtention selon l'invention telles qu'elles sont mises en œuvre, dans un mode particulier de réalisation, par un dispositif serveur du système de protection de la figure 2 ; et
[Fig. 7] la figure 7 représente des étapes pouvant être mises en œuvre, dans un mode particulier de réalisation, par un dispositif serveur du système de protection de la figure 2.
Description de l'invention
[0077] La figure 2 représente un système 1 de protection d'un domaine informatique 2 contre des attaques informatiques, conforme à l'invention, dans un mode particulier de réalisation.
[0078] On entend ici par domaine informatique, aussi désigné par domaine informatique client ou domaine client, un ensemble de ressources informatiques (incluant notamment des ressources ré- seaux telles que des routeurs, commutateur, serveurs, terminaux, etc.), placées sous la responsabi lité d'une entité administrative donnée. Un tel domaine informatique est par exemple un réseau d'entreprise, un réseau domestique ou un système autonome ou AS (pour « Autonomous Sys tem ») utilisant le protocole BGP (pour « Border Gateway Protocol » en anglais). Toutefois, aucune limitation n'est attachée à la nature du domaine ni au type de protocoles utilisés au sein du do maine informatique 2.
[0079] Le domaine informatique 2 est connecté au réseau public Internet, directement ou via un ou plu sieurs réseaux transitaires. Il possède diverses ressources informatiques (ressources CPU, res sources mémoires, ressources réseau, liens d'interconnexion avec d'autres réseaux, etc.), proté gées par une pluralité de services de protection contre des attaques informatiques SP1, SP2, ..., SPN, auxquels a souscrit l'administrateur ou le propriétaire du domaine informatique 2, N désignant un nombre entier supérieur à 1. Par souci de simplification, sur la figure 2, trois services de protec tion SP1, SP2 et SP3 sont représentés, toutefois le nombre N peut être un entier quelconque supé rieur à 1.
[0080] Tout ou partie des services de protection SP1, SP2, ..., SPN, protégeant les ressources du domaine informatique 2, et en particulier dans l'exemple envisagé ici SP1, SP2 et SP3, sont gérés par des entités administratives (par exemple, par des opérateurs de réseaux) distinctes. En d'autres termes, chacune de ces entités administratives n'a pas de visibilité sur les actions de mitigation d'attaques mises en place par les autres entités administratives et leurs propres services de protec tion (c'est-à-dire pas de connaissance a priori de ces actions de mitigation). Dans la suite de la description, on entend par « plan de mitigation » des actions proposées ou mises en place par un service de protection pour la résolution d'une attaque, en vue notamment d'empêcher le trafic de l'attaque de se propager pour atteindre une ou plusieurs cibles dans le domaine informatique 2.
[0081] Aucune limitation n'est attachée à la localisation de ces services de protection SP1, SP2, ..., SPN.
Ils peuvent être hébergés sur un ou plusieurs dispositifs (par exemple sur un ou des serveurs) se trouvant dans un système informatique en nuage (plus communément désigné par « cloud »), dans le réseau Internet, ou dans des réseaux transitaires fournissant au domaine informatique client 2 un accès au réseau Internet, etc. Ainsi, par services de protection SPk, k=l, ..., N, on en tend ici aussi bien le service en lui-même fourni au domaine informatique 2 que le ou les dispositifs hébergeant la logique de ce service. Aussi, aucune hypothèse n'est faite quant à la structure fonc tionnelle et organique d'un service DPS.
[0082] On considère ici, à titre illustratif, l'exemple d'attaques de dénis de service distribué (ou DDoS) et on suppose que le domaine informatique 2 comprend une (ou plusieurs) fonctions de détection d'attaques DDoS. Toutefois, l'invention s'applique à tout type d'attaque informatique (déni de ser vice, usurpation d'identité, ransomware, etc.). En outre, aucune limitation n'est attachée à la na ture des ressources qui peuvent être la cible d'une attaque ; il peut s'agir par exemple d'une adresse IP, d'un préfixe IP, d'une machine, d'un alias, d'un nom de domaine pleinement qualifié (FQDN pour Fully Qualified Domain Name en anglais), etc.
[0083] Dans le mode de réalisation décrit ici, le système de protection 1 s'appuie sur une architecture client/serveur DOTS (pour « DDoS Open Threat Signaling ») telle que définie par ITETF (Internet Engineering Task Force). De façon connue, l'architecture DOTS spécifiée par l'IETF a pour objectif de fournir un mécanisme de signalisation de détection de trafic suspect voire d'attaque avérée, de sorte que des mesures de mitigation appropriées puissent être mises en œuvre le plus rapidement possible. Plus particulièrement, elle permet à un client dit client DOTS qui gère un domaine infor matique d'informer un serveur dit serveur DOTS de la détection d'un trafic suspect potentiellement caractéristique d'une attaque DDoS en cours et que des actions de mitigation appropriées sont re quises. Le serveur DOTS peut alors mettre en place ou coordonner diverses actions pour que, par exemple, le trafic associé à l'attaque de déni de service ne soit plus acheminé vers le domaine in formatique du client DOTS, et que seul le trafic consenti (c'est-à-dire légitime) soit acheminé vers ledit domaine informatique. On note que le client DOTS n'est pas nécessairement un élément ré seau du domaine informatique en question, mais peut être connecté indirectement à ce dernier ; il peut s'agir par exemple d'un réseau de contrôle ou d'un terminal (par exemple, un smartphone) d'un administrateur du domaine informatique, etc.
[0084] A cet effet, deux canaux de communication DOTS sont définis entre le client DOTS et le serveur DOTS :
- un canal de signalisation DOTS (« DOTS Signal Channel », en anglais) : ce canal est utilisé seule ment pendant la durée des attaques DDoS. Ainsi, le client DOTS peut utiliser ce canal pour demander de l'aide au serveur DOTS en l'informant qu'une attaque est en cours. La table 1 illustre un exemple de requête de mitigation pouvant être envoyée via un canal de signalisation DOTS « draft-ietf-dots- signal-channel » (correspondant à une cible de l'attaque identifiée par l'attribut « ietf-dots-signal- channel:mitigation-scope» dans la table 1), par un client DOTS identifié par un identifiant unique CUID (pour « Client Unique Identifier ») « mydotsclient », à son serveur DOTS, pour l'informer que le préfixe « 1.2.3.0/24 » (identifié dans le champ « target-prefix ») subit une attaque DDoS. Sur réception d'une telle requête de mitigation (reconnaissable à la nature de la requête (PUT) et à la présence des attributs Uri-Path ("mitigate") et (« mid »)), le serveur DOTS, après vérification que ce client est autorisé à demander des actions pour « 1.2.3.0/24 », prend les mesures adéquates pour mettre fin à l'attaque si cette demande n'est pas en conflit avec d'autres demandes provenant d'autres clients du même domaine informatique ou avec une règle de filtrage installée par un autre client DOTS du domaine, et si le serveur est habilité à/configuré pour honorer la dernière requête de miti gation reçue. En cas de conflit, le serveur renvoie un message d'erreur « 4.09 Conflict » pour informer le client ; et
- un canal de données DOTS (« DOTS Data Channel » en anglais) : ce canal est utilisé si et seulement aucune attaque n'est en cours. Le client DOTS peut par exemple utiliser ce canal pour installer des règles de filtrage (ou ACL pour « Access Control List ») telles que le filtrage du trafic reçu de certaines adresses ou destiné à une machine donnée. La table 2 fournit l'exemple d'un message envoyé sur un canal de données DOTS « draft-ietf-dots-data-channel » (correspondant à un filtre caractérisé par l'attribut « ietf-dots-data-channel:access-lists » dans la table 2), par un client DOTS ayant comme identifiant CUID « mydotsclient », demandant à un serveur DOTS de bloquer (« actions » : {"forwar- ding": "drop"}) tout le trafic à destination du préfixe « 1.2.3.0/24 ». Sur réception d'une telle de mande (reconnaissable à la nature de la requête (POST), de la « Request-URI » (« /rest- conf/data/ietf-dots-data-hannel:dots-data/dots-client= mydotsclient »), après vérification que ce client DOTS est autorisé à demander l'installation de règles de filtrage pour le préfixe « 1.2.3.0/24 », le serveur DOTS procède à l'installation des règles de filtrage si cette demande n'est pas en conflit avec d'autres demandes provenant d'autres clients du même domaine informatique ou avec une règle de filtrage existante. En cas de conflit avec d'autres règles maintenues par le serveur DOTS, ce dernier renvoie un message d'erreur "4.09 Conflict" pour informer le client DOTS.
[0085] Ces différents canaux sont décrits plus en détail respectivement dans les documents de T. Reddy et al. intitulé « Distributed Denial-of-Service Open Threat Signaling (DOTS) Signal Channel Spécifica tion », et de M. Boucadair et al. intitulé « Distributed Denial-of-Service Open Threat Signaling (DOTS) Data Channel Spécification », édités par l'IETF en 2019.
[0086] Table [1]
[0087] Table [2]
[0088] DOTS est donc une architecture destinée à faciliter la prise en charge de requêtes de mitigation d'attaques émises par un client DOTS et reçues par un serveur DOTS, comme par exemple un serveur exploité par un fournisseur de service de protection contre des attaques informatiques.
[0089] On suppose ici que le domaine informatique 2 comprend un dispositif 3, conforme à l'invention, en charge de la gestion et de la surveillance de l'ensemble des ressources informatiques du domaine informatique 2, et les services de protection SP1, ..., SPN, comprennent des dispositifs 4-1, ..., 4-N respectivement, également conformes à l'invention, le dispositif 3 et les dispositifs 4-1, ..., 4-N étant susceptibles d'interagir entre eux selon les principes qui viennent d'être décrits et caractéristiques de l'architecture client/serveur DOTS. Dans ce mode de fonctionnement, le dispositif 3 agit comme un client DOTS (on le désigne par souci de simplification dans la suite par « dispositif client 3 ») et les dispositifs 4-1, 4-2, ..., 4-N comme des serveurs DOTS. L'invention s'applique toutefois à d'autres architectures et/ou à d'autres protocoles permettant aux dispositifs 3, 4-1, ..., 4-N de communiquer entre eux.
[0090] On note que par souci de simplification, dans l'exemple envisagé sur la figure 2, le dispositif client 3 et les dispositifs serveurs 4-1, ..., 4-N communiquent directement entre eux (après éventuellement une authentification préalable du dispositif client DOTS 3 par les dispositifs serveurs DOTS 4- 1, ..., 4-N). En variante, les communications DOTS entre un client DOTS et un serveur DOTS peuvent se faire via des relais (ou « DOTS Gateways » en anglais). Ces relais peuvent être hébergés au sein du domaine du client DOTS (désigné aussi par « domaine client ») ou au sein du domaine du serveur (désigné aussi par « domaine serveur ») ou dans les deux. Un relai DOTS localisé dans un domaine du client est considéré par un serveur DOTS comme un client DOTS. Un relai DOTS localisé dans un domaine serveur est considéré par un client DOTS comme un serveur DOTS.
[0091] On note par ailleurs qu'en cas de présence d'un relai DOTS dans un domaine serveur, l'authentification des clients DOTS est de la responsabilité du relai. Un serveur DOTS doit être configuré avec la liste des relais DOTS actifs au sein de son domaine ; il peut alors déléguer certaines de ses fonctions à ces relais de confiance. De plus, le serveur DOTS peut utiliser en toute sécurité les informations fournies par un relai figurant dans une liste déclarée auprès du serveur DOTS et maintenue par celui-ci, moyennant une procédure d'authentification ad hoc (par exemple, configuration explicite de la liste des relais par l'administrateur habilité du serveur, récupération de la liste auprès d'un serveur AAA (pour « Authentication, Authorization and Accounting » en anglais), etc.).
[0092] Dans le mode de réalisation décrit ici, le dispositif client 3 est configuré pour établir avec les dispositifs serveurs 4-1, ..., 4-N des services de protection SP1, ..., SPN (ou des relais DOTS localisés dans les domaines informatiques hébergeant les dispositifs serveurs 4-1, ..., 4-N) des sessions DOTS sécurisées conformément à la spécification IETF précitée intitulée « Distributed Denial-of- Service Open Threat Signaling (DOTS) Signal Channel Spécification ». En particulier, les sessions sont établies ici en utilisant le protocole DTLS (pour « Datagram Transport Layer Security » en anglais), ou le protocole TLS (pour « Transport Layer Security » en anglais). Les détails des échanges TLS/DTLS et ceux concernant la gestion d'éventuelles clés de sécurité ne sont pas reproduits ici.
[0093] En outre, dans le mode de réalisation décrit ici, on suppose que les différents agents (clients, serveurs et relais) DOTS impliqués (c'est-à-dire le dispositif client DOTS 3 et les dispositifs serveurs DOTS 4-1, ..., 4-N ou relais entre ces dispositifs DOTS) sont configurés pour s'authentifier mutuellement. On s'assure ainsi que les messages DOTS reçus d'une machine usurpant l'identité d'un dispositif serveur DOTS 4-1, ..., 4-N légitime sont rejetés par le dispositif client 3 DOTS. De la même manière, les demandes de dispositifs clients DOTS non-autorisés à accéder au service offert par le dispositif serveur DOTS 4-1, ..., 4-N considéré sont ignorées par ce dernier.
[0094] Dans le mode de réalisation décrit ici, le dispositif client DOTS 3 a l'architecture matérielle d'un ordinateur, telle que représentée à la figure 3. Il comprend notamment un processeur 5, une mémoire vive 6, une mémoire morte 7, une mémoire non volatile 8, et des moyens de communication 9 lui permettant notamment de communiquer, en utilisant en particulier le protocole DOTS, avec les dispositifs serveurs 4-1, ..., 4-N des services de protection SP1, ..., SPN. Ces moyens de communication 9 s'appuient sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici.
[0095] La mémoire morte 7 du dispositif client 3 constitue un support d'enregistrement conforme à l'invention, lisible par le processeur 5 et sur lequel est enregistré un programme d'ordinateur PROG3 conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'assistance selon l'invention. Le programme PROG3 définit des modules fonctionnels du dispositif client 3, qui s'appuient ou commandent les éléments matériels 5 à 9 du dispositif client 3 cités précédemment, et qui comprennent notamment (cf. figure 2) :
- un module de détermination 3A, configuré pour déterminer une incapacité d'un premier service de protection parmi la pluralité de services de protection SP1, ..., SPN, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique 2, et relevant du périmètre d'action du premier service de protection ;
- un module d'élaboration 3B, configuré pour élaborer un plan de mitigation de ladite attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection parmi la pluralité de services de protection SP1, ..., SPN, ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et - un module de transmission 3C, configuré pour transmettre le plan de mitigation élaboré au premier service de protection pour traiter l'attaque.
[0096] On note que le dispositif client 3 peut également comprendre une fonction de détection d'attaque DDoS. Dans le mode de réalisation décrit ici, on suppose toutefois que cette fonction de détection d'attaque DDoS est hébergée par un autre dispositif 10 du domaine informatique 2 (cf. figure 2).
[0097] Les différentes fonctions mises en œuvre par les modules 3A à 3C du dispositif client 3 sont détaillées davantage ultérieurement.
[0098] De façon similaire, dans le mode de réalisation décrit ici, chaque dispositif serveur DOTS 4-1, ..., 4- N a l'architecture matérielle d'un ordinateur, telle que représentée à la figure 4. Il comprend notamment un processeur 11, une mémoire vive 12, une mémoire morte 13, une mémoire non volatile 14, et des moyens de communication 15 lui permettant notamment de communiquer, en utilisant en particulier le protocole DOTS, avec le dispositif client 3. Ces moyens de communication 15 s'appuient sur une interface de communication filaire ou sans fil, connue en soi et non décrite plus en détail ici.
[0099] La mémoire morte 13 de chaque dispositif serveur 4-k, k=l,...N constitue ici un support d'enregistrement conforme à l'invention, lisible par le processeur 11 et sur lequel est enregistré un programme d'ordinateur PROG4 conforme à l'invention, comportant des instructions pour l'exécution des étapes d'un procédé d'obtention selon l'invention. Le programme PROG4 définit des modules fonctionnels du dispositif serveur 4-k, qui s'appuient ou commandent les éléments matériels 11 à 15 cités précédemment, et qui comprennent notamment (cf. figure 2) un module de réception 4A et un module de mise en place 4B, activés suite à une détection d'une incapacité du dispositif serveur 4-k à traiter une attaque informatique ciblant une ou des ressources du domaine informatique 2.
[0100] Plus particulièrement, le module de réception 4A est configuré pour recevoir un plan de mitigation élaboré par le dispositif client 3 à partir d'un plan de mitigation obtenu d'un autre service de protection (deuxième service au sens de l'invention) SPj, j= 1...N et j¹k ou utilisant une assistance fournie par au moins un tel autre service de protection. Le module de mise en place 4B est quant à lui configuré pour mettre en place en réponse à l'attaque informatique un plan de mitigation dérivé du plan de mitigation reçu du dispositif client 3.
[0101] Dans le mode de réalisation décrit ici, chaque dispositif serveur 4-k, k=l...N, comporte également les modules fonctionnels (et logiciels ici) suivants :
- un module de fourniture 4C, le cas échéant, d'un plan de mitigation mis en place par le dispositif serveur 4-k en réponse à une attaque détectée sur les ressources du domaine informatique 2 relevant du périmètre d'action du service de protection SPk ;
- un module d'émulation 4D, activé sur requête du dispositif client 3, et configuré pour émuler une attaque informatique sur au moins une ressource du domaine informatique 2 protégée par le service de protection SPk, ainsi qu'un module de transmission 4E configuré pour transmettre au dispositif client 3 un plan de mitigation de l'attaque proposé par le service de protection SPk lors de l'émulation de l'attaque par le module d'émulation 4D.
[0102] Les différentes fonctions mises en œuvre par les modules 4A à 4E de chaque dispositif serveur 4-k, k=l... N sont détaillées davantage ultérieurement. On note que par souci de simplification, les modules 4A à 4E des dispositifs serveurs 4-k, k=l... N ne sont représentés sur la figure 2 que pour le dispositif serveur 4-1.
[0103] Nous allons maintenant décrire, en référence aux figures 5 et 6, les principales étapes mises en œuvre respectivement par le dispositif client 3 et par les dispositifs serveur 4-k, k=l... N pour améliorer la gestion des attaques informatiques ciblant des ressources du domaine informatique 2 con- formément à l'invention. La figure 5 illustre ainsi les étapes d'un procédé d'assistance selon l'inven tion, telles que mises en œuvre par le dispositif client 3 dans un mode particulier de réalisation. La figure 6 illustre ainsi les étapes d'un procédé d'obtention selon l'invention telles que mises en œuvre par un dispositif serveur 4-k0 d'un service de protection SPkO parmi les services de protec tion SP1, ..., SPN protégeant les ressources du domaine informatique 2, ainsi que les étapes mises en œuvre par les autres dispositifs serveurs 4-k, k=l,...N, k¹k0 dans ce mode particulier de réali sation.
[0104] En référence à la figure 5, on suppose ici qu'une attaque informatique ATTACK a été détectée sur au moins une ressource du domaine informatique 2 par la fonction de détection 10 d'attaques in formatiques, de façon connue en soi. Cette attaque est signalée par la fonction de détection 10 au dispositif client 3 (étape E10). Lors de ce signalement, la fonction de détection 10 fournit diverses informations sur l'attaque ATTACK au dispositif client 3, comme par exemple les caractéristiques du trafic de l'attaque (adresse(s) source, adresse(s) destination, identifia nt(s) de protocoles (par exemple ICMP (pour Internet Control Message Protocol), TCP (pour Transmission Control Protocol), etc.), la nature de l'attaque (ici attaque DDoS), etc. Ces informations peuvent être complétées par des informations de volumétrie du trafic d'attaque, obtenues par exemple par la fonction 10 via la collecte de compteurs SNMP (pour Simple Network Management Protocol) sur les interfaces incri minées.
[0105] Sur réception de ce signalement, le dispositif client 3 envoie une requête DOTS à tout ou partie des dispositifs 4-1, ..., 4-N pour signaler l'attaque informatique ATTACK détectée et leur demander de l'aide pour résoudre cette attaque (étape E20). La requête DOTS envoyée est par exemple une re quête DOTS « Request Mitigation » connue de l'état de la technique, similaire ou identique à la re quête donnée à titre illustratif dans la table 1. Elle est envoyée par le dispositif client 3 à tous les dispositifs serveurs 4-1, ..., 4-N ou seulement aux dispositifs serveurs parmi les dispositifs serveurs 4-1, ..., 4-N protégeant les ressources ciblées par l'attaque ou impliquées dans l'acheminement du trafic de l'attaque vers le domaine informatique 2. Cet envoi peut être effectué en parallèle vers chacun des dispositifs serveurs ou séquentiellement.
[0106] A titre uniquement illustratif, on suppose ici que l'attaque ATTACK relève du périmètre d'action des services de protection SP1 et SP2, et plus particulièrement cible des ressources protégées par les services de protection SP1 et SP2, et que la requête DOTS est envoyée par le dispositif client 3 aux dispositifs serveurs 4-1 et 4-2 seulement.
[0107] En référence à la figure 6, le ou les dispositifs) serveur(s) contacté(s) (étape F10) par le disposi tif client 3, et qui est (sont) en mesure de traiter cette attaque (réponse « oui » à l'étape test F20), acquitte(nt) la requête de mitigation de l'attaque reçue du dispositif client 3 en lui envoyant un message DOTS « 2.01 Created » (étape F30). Par « en mesure de traiter cette attaque » ou « ca pable de traiter cette attaque », on entend ici que le dispositif serveur a la capacité fonctionnelle (c'est-à-dire il connaît l'attaque, sait comment l'identifier et la mitiger) et dispose des ressources matérielles et/ou logicielles (en quantité appropriée) pour la traiter et la mitiger.
[0108] Chaque dispositif serveur d'un service de protection capable de traiter l'attaque met en outre en place un plan de mitigation pour traiter le trafic destiné au domaine informatique 2 dont il a la visi bilité (autrement dit destiné ou passant par les ressources du domaine informatique 2 dont il as sure la protection) (étape F40). Il informe le dispositif client 3 qu'il a mis en place avec succès un plan de mitigation contre l'attaque.
[0109] Dans l'exemple illustratif introduit précédemment, on suppose ici que le service de protection SP1 est en mesure de traiter l'attaque, met en place avec succès un plan de mitigation contre cette at taque et en informe le dispositif client 3.
[0110] Si en revanche, l'un des services de protection contacté n'est pas en mesure de traiter cette at taque (réponse « non » à l'étape test F20), il en informe le dispositif client 3 en lui envoyant par exemple un message d'erreur tel qu'un message DOTS « 5.03 (Service Unavailable) » (étape F70).
[0111] Dans l'exemple illustratif introduit précédemment, on suppose ici que le service de protection SP2 n'est pas en mesure de traiter l'attaque, et en informe le dispositif client 3.
[0112] En référence à la figure 5, le dispositif client 3 demande au(x) service(s) de protection ayant mis en place un plan de mitigation contre l'attaque (branche « SPk/ATTACK OK ») de lui fournir ce(s) plan de mitigation (étape E30). A cet effet, il envoie par exemple, à chaque dispositif serveur concerné, une requête DOTS GET contenant un attribut (« Uri-Path ») nouvellement introduit pour les besoins de l'invention et appelé ici « mplan ». Un exemple d'une telle requête est fourni à titre illustratif dans la table 3 ci-dessous.
[Table 3]
[0113] La requête peut comprendre un identifiant de mitigation de l'attaque, « mid » (pour « Mitigation IDentifier »), supposé égal ici pour l'attaque ATTACK à « 12332 ». Si cet identifiant n'est pas renseigné dans la requête alors, dans le mode de réalisation décrit ici, le dispositif serveur doit communiquer tous les plans de mitigation de l'ensemble des actions de mitigation en cours d'exécution par le service de protection associé.
[0114] Sur réception de cette requête (étape F50), le dispositif serveur fournit au dispositif client 3, via son module de fourniture 4B, les caractéristiques techniques du plan de mitigation mis en place contre l'attaque ATTACK (ou de l'ensemble des plans de mitigation en cours d'exécution si aucun identifiant de mitigation d'attaque n'est précisé dans la requête GET) (étape F60). Le plan de mitigation est fourni sous la forme d'une liste (qui peut être ordonnée) comprenant une ou plusieurs règles, chaque règle définissant (c'est-à-dire caractérisant) le trafic que l'on souhaite traiter (par exemple le trafic identifié comme suspect), et la ou les actions devant être appliquées au trafic caractérisé par la règle. De telles actions sont par exemple, un rejet du trafic défini par la règle associée à l'action, une redirection du trafic, une limitation du débit du trafic, etc.
[0115] Un exemple de réponse fournie par le dispositif serveur est illustré à la table 4.
[Table 4]
[0116] Selon cet exemple, le plan de mitigation est fourni dans l'attribut "mpian", dans le corps de la réponse. L'attribut « mpian » peut être structuré selon un formalisme similaire ou identique à celui des listes ACL (Access Control Lists) définies dans la spécification du protocole DOTS, ou selon une chronologie ECA (Event, Condition, Action), etc.. A titre illustratif, un exemple de plan de mitigation est donné ci-après dans la table 5.
Table 5]
[0117] Le plan décrit dans la table 5 contient une entrée ACE (pour « Access Control Entry »), c'est-à-dire une action de filtrage dont le nom est « ruiel » : cette action consiste à rejeter (comme l'indique la clause « forwarding » positionnée à « drop » pour rejeter sans notification à la source) tout le trafic défini par l'attribut « matches », à savoir ici le trafic émis depuis n'importe quelle adresse du réseau associé au préfixe "192.0.2.0/24" et à destination des ressources associées au préfixe "1.2.3.0/24".
[0118] On note qu'un plan de mitigation peut en variante inclure plusieurs entrées ACE ; en effet, des actions distinctes telles que la redirection, la réduction de débit, etc. peuvent être exécutées par un même service de mitigation en réponse à une attaque.
[0119] Dans la suite de la description, un plan de mitigation est identifié selon le formalisme suivant, lorsqu'il contient une ou plusieurs règles : mplan=LIST_RULES(match, action, ...), LIST_RULES désignant une liste de règles, chaque règle étant définie par une ou plusieurs conditions (« match ») permettant d'identifier le trafic concerné par la règle, et une ou plusieurs actions (« action ») préconisées par la règle pour le trafic ainsi identifié. On note qu'au sens de l'invention, un plan de mitigation peut également ou en variante, comprendre une ou plusieurs informations permettant de mettre en œuvre une assistance fournie par un service de protection pour le traitement d'une attaque.
[0120] Le dispositif client 3 mémorise localement, par exemple dans sa mémoire non volatile 8, tous les plans de mitigation reçus des services de protection compétents pour traiter l'attaque ATTACK en association avec les dispositifs serveurs et/ou les services de protection lui ayant fourni ces plans (étape E40). Dans la suite de la description, on désigne par mplan(SPk,mid#j) le plan de mitigation mis en place par le service de protection SPk (et son dispositif serveur 4-k) en réponse à l'attaque identifiée par l'identifiant de mitigation d'attaque mid#j, j désignant un entier supérieur à 1. On note que des identifiants de mitigation distincts peuvent être utilisés pour une même attaque pour faciliter la gestion des plans de mitigation pendant ou après leur exécution.
[0121] Ainsi, dans l'exemple illustratif envisagé ici où le service de protection SP1 a mis un plan de mitigation en place pour traiter l'attaque ATTACK, le dispositif client 3 reçoit ce plan de mitigation du dispositif serveur 4-1 et le mémorise sous la forme mplan(SPl,mid=12332) dans sa mémoire non volatile, 12332 désignant l'identifiant de mitigation de l'attaque ATTACK.
[0122] On note que dans le mode de réalisation décrit ici, les plans de mitigation mis en place le cas échéant par les services de protection SPk, k=l,..., N sont obtenus par le dispositif client 3 suite à la détection de l'attaque ATTACK. En variante, on peut envisager que le dispositif client 3 sollicite les services de protection SPk, k=l,..., N de façon décorrélée par rapport à la détection d'une attaque ATTACK, ou suite à la détection d'une anomalie dans le domaine informatique 2 (par exemple une boucle de routage entre les domaines transitaires, la perte de trafic entrant/sortant du domaine informatique 2, la dégradation des services accessibles au domaine), etc.
[0123] Dans une autre variante encore, on peut envisager que le dispositif client 3 souscrive auprès des services de protection SPk, k=l,...,N à un service de notification des différentes actions de mitigation mises en œuvre par ces derniers pour protéger les ressources du domaine informatique 2, et/ou de la mise à jour ou de l'évolution de ces actions (cessation de l'action, mise en place d'actions) de mitigation additionnelle(s), etc.).
[0124] Dans l'exemple illustratif envisagé ici, comme mentionné précédemment, on suppose que le service de protection SP2 est incapable de traiter l'attaque ATTACK relevant de son périmètre d'action (branche « SPk/ ATTACK NOK »). Le dispositif serveur 4-2 du service de protection SP2 notifie le dispositif client 3 de cette incapacité lors de l'étape F750 décrite précédemment en lui transmettant un message d'erreur en réponse à sa requête de mitigation « 5.03 (Service Unavailable) ». Dans le mode de réalisation décrit ici, le message d'erreur « 5.03 (Service Unavailable) » comprend avantageusement, dans un paramètre « status » introduit dans la spécification du protocole DOTS pour les besoins de l'invention, la cause de l'erreur.
[0125] Dans le mode de réalisation décrit ici, on suppose qu'un service de protection SPkO donné peut s'avérer incapable de traiter une attaque informatique dont il est notifié par le dispositif client 3 et de mettre en place un plan de mitigation de cette attaque pour deux raisons :
- l'attaque ATTACK est méconnue du service de protection SPkO, autrement dit, il ne dispose pas de moyens d'identifier le trafic de l'attaque et/ou ne sait pas comment traiter cette attaque. Le service de protection SPkO n'est donc pas capable de mettre en œuvre un plan de mitigation adapté en réponse à l'attaque détectée. Cette raison est codifiée dans le message d'erreur par un paramètre « status » valorisé par exemple à « unknown-attack » ; ou
- le service de protection SPkO connaît l'attaque mais souffre d'une insuffisance de ressources disponibles pour mitiger l'attaque (problème capacitaire, par manque de ressources adéquates et/ou de ressources en quantité suffisante pour mitiger l'attaque, par exemple si celle-ci est de grande am pleur). Cette raison est alors codifiée dans le message d'erreur par un paramètre « status » ayant par exemple la valeur « attack-exceeded-capacity ».
[0126] Aucune limitation n'est attachée toutefois au nombre de raisons ni aux raisons pour lesquelles un service de protection peut s'avérer incapable de traiter une attaque.
[0127] Le dispositif client 3 peut de cette sorte détecter, au moyen de son module 3A de détermination, non seulement l'incapacité du service de protection SP2 à traiter l'attaque ATTACK, mais également déterminer la cause de cette incapacité en examinant la valeur du paramètre « status » inclus dans le message d'erreur reçu du dispositif serveur 4-2 (étape E50).
[0128] L'envoi de la requête de mitigation au dispositif serveur 4-2 et la réception du message d'erreur en réponse à cette requête constituent ainsi conjointement une étape de détermination de l'incapacité du service de protection SP2 à traiter l'attaque ATTACK par le dispositif client 3 au sens de l'inven tion.
[0129] Dans une variante de réalisation, le dispositif client 3 peut détecter cette incapacité autrement que par une information reçue directement du dispositif serveur 4-2. Par exemple, le dispositif client 3 peut détecter (directement ou indirectement par le biais d'une information reçue d'une autre entité du domaine informatique 2 ou par une entité externe) que le domaine informatique 2 reçoit tou jours le trafic de l'attaque depuis des ressources protégées par le service de protection SP2 alors qu'une demande de mitigation explicite a été émise par le dispositif client 3 vers ce dernier, etc.
[0130] Si selon le paramètre « status » du message d'erreur, l'incapacité du service de protection SP2 pro vient d'une méconnaissance de l'attaque ATTACK (branche (I) sur la figure 5), et par ailleurs, au moins un autre service de protection concerné par l'attaque a mis en place un plan de mitigation efficace en réponse à cette attaque (réponse « oui » à l'étape test E60), le dispositif client 3 sélec tionne dans sa mémoire non volatile 8 l'un de ces plans de mitigation (étape E70). Dans l'exemple illustratif envisagé ici, le service de protection SP1 a mis en place un tel plan de mitigation (plan de mitigation mplan(SPl,mid= 12332)) et l'a communiqué lors de l'étape F60 au dispositif client 3.
[0131] On note que dans le mode de réalisation décrit ici, le dispositif client 3 a sollicité les services de protection au moyen de la requête GET pour obtenir leurs plans de mitigation dès la détection de l'attaque. En variante, il peut envoyer la requête GET sur détection de l'incapacité du service de protection SP1 à mettre en place un plan de mitigation (cela peut permettre d'avoir une version plus à jour du plan de mitigation si l'attaque a évolué par exemple), ou suite à la détection de l'at taque et suite à la détection de l'incapacité du service de protection SP1, ou encore de manière périodique, etc. Aucune limitation n'est attachée au nombre de fois ni aux moments où le dispositif client 3 peut solliciter les services de protection pour connaître les plans de mitigation qu'ils exécu tent.
[0132] Puis, le dispositif client 3 élabore, au moyen de son module d'élaboration 3B, à partir du plan de mitigation sélectionné (mplan(SPl,mid= 12332) ici), un plan de mitigation adapté aux ressources protégées par le service de protection incapable de traiter l'attaque aussi désigné par « service de protection incapable » dans la suite de la description par souci de simplification (SP2 dans l'exemple illustratif considéré) (étape E80).
[0133] Si les ressources du domaine informatique 2 protégées par le service de protection incapable sont également protégées par le service de protection (SP1 dans l'exemple) ayant fourni le plan de miti gation sélectionné, le plan élaboré par le dispositif client 3 peut alors consister en la reprise à l'identique du plan de mitigation sélectionné mplan(SPl,mid= 12332), ou en la reprise uniquement des règles et des actions correspondant aux ressources protégées par le service de protection inca pable SP2 (dans l'hypothèse par exemple où le service de protection SP1 protège d'autres res sources en plus de celles protégées par le service de protection incapable SP2).
[0134] Si les ressources du domaine informatique 2 protégées par le service de protection incapable SP2 diffèrent au moins en partie des ressources du domaine informatique 2 protégées par le service de protection SP1 ayant fourni le plan de mitigation sélectionné, alors le dispositif client 3 adapte le plan de mitigation fourni par le service de protection SP1 pour qu'il s'applique aux ressources protégées par le service de protection SP2. Cette adaptation peut consister notamment à adapter les règles définissant les caractéristiques du trafic traité. Par exemple, si le plan de mitigation mplan(SPl,mid= 12332) contient des adresses IP uniquement protégées par le service de protection SP1 (par exemple identifiant des ressources d'interconnexion avec le réseau auquel appartient le service de protection SP1 alors que le service de protection SP2 protège des ressources d'interconnexion avec un autre réseau), le dispositif client 3 remplace ces adresses par celles protégées par le service de protection SP2.
[0135] Les tables 6 et 7 illustrent un exemple d'adaptation pouvant être réalisé par le dispositif client 3 pour élaborer à partir du plan de mitigation mplan(SPl,mid= 12332) un plan de mitigation destiné au service de protection SP2.
[0136] La table 6 ci-dessous propose à titre illustratif un exemple de plan de mitigation mplan(SPl,mid= 12332) mis en place et fourni par le service de protection SP1.
Table 6]
[0137] La table 7 montre en caractères gras l'adaptation réalisée par le dispositif client 3 pour élaborer un plan de mitigation adapté au service de protection SP2 (changement de l'identification des ressources ciblées par l'attaque).
[Table 7]
[0138] D'autres types de modifications peuvent être envisagés pour être en cohérence avec le contexte d'une mitigation, comme par exemple la modification d'un filtre IPv4 en un filtre IPv6, la modification d'un filtre portant sur des numéros de port et non une plage d'adresses, la création de filtres pour chacune des adresses si les adresses protégées par le service de protection incapable ne peu vent pas être agrégées, le remplacement de certaines actions, etc.
[0139] Dans la suite de la description on désigne par g(mplan(SPl)) le plan élaboré par le dispositif client 3 à partir du plan mplan(SPl,mid= 12332).
[0140] On note que si plusieurs services de protection ont fourni au dispositif client 3 des plans de mitiga tion de l'attaque ATTACK, le dispositif client 3 peut sélectionner l'un quelconque de ces plans (de manière aléatoire, ou le premier fourni, ou encore celui correspondant à un service de protection particulier (par exemple le plus attractif en termes de coût), etc.), agréger les différent plans reçus, ou en variante tenir compte d'un critère de sélection prédéterminé, comme par exemple le plan de mitigation qui requiert le moins d'adaptation pour pouvoir convenir au service de protection inca pable.
[0141] Une fois le plan g(mplan(SPl)) élaboré, le dispositif client 3 le transmet par l'intermédiaire de son module de transmission 3C et de ses moyens de communication 9 au service de protection SP2 in capable et plus particulièrement au dispositif serveur 4-2 appartenant au service de protection SP2 (étape E90). Il peut à cet effet envoyer à destination du dispositif serveur 4-2 une requête de miti gation DOTS « Request Mitigation » telle que décrite précédemment comprenant le plan de mitiga tion g(mplan(SPl)).
[0142] Si selon le paramètre « status » du message d'erreur, l'incapacité du service de protection SP2 pro vient d'une méconnaissance de l'attaque ATTACK (branche (I) sur la figure 5), mais l'attaque relève uniquement du le périmètre d'action du service de protection incapable SP2 (autrement dit les res sources ciblées par l'attaque ATTACK ou impliquées dans l'acheminement du trafic de l'attaque AT TACK sont protégées par un unique service de protection parmi la pluralité de services de protec tion SP1, ..., SPN protégeant les ressources du domaine informatique 2, à savoir SP2) (réponse « non » à l'étape E60), alors cela signifie qu'aucun des services de protection sollicité parmi la plu ralité de services de protection lors de l'étape E30 n'a mis en place un plan de mitigation efficace contre l'attaque ATTACK et a fortiori n'a fourni un tel plan de mitigation au dispositif client 3 lors de l'étape E40. En d'autres termes, le dispositif client 3 ne dispose dans sa mémoire non volatile 9 d'aucun plan de mitigation déjà « connu » contre l'attaque ATTACK.
[0143] Dans le mode de réalisation décrit ici, dans ce cas, le dispositif client 3 envoie à au moins l'un des services de protection SPk, k¹2, protégeant des ressources du domaine informatique 2, et plus particulièrement au dispositif serveur 4-k de ce service de protection, une requête d'émulation de l'attaque ATTACK sur les ressources protégées par ce service de protection et d'obtention d'un plan de mitigation mis en place dans le cadre de cette émulation par le service de protection en réponse à l'attaque ATTACK (étape E100).
[0144] A cet effet, il peut par exemple utiliser une requête DOTS de mitigation « Request Mitigation » telle que décrite précédemment dans laquelle le dispositif client 3 insère un attribut, nouvellement défini pour les besoins de l'invention (nommé par exemple « emulate »), requérant une émulation de l'attaque ATTACK, et l'attribut mplan requérant le plan de mitigation proposé le cas échéant par le service de protection lors de l'émulation. Ces attributs ont pour objectif de déterminer si l'un au moins des services de protection SPk, k=l,.., N avec k¹2 (ou plus généralement k différent des indices des services de protection pour lesquels une incapacité à traiter l'attaque a été détectée par le dispositif client 3) est en mesure de traiter l'attaque. On note que l'attribut « emulate » peut être utilisé à d'autres fins, par exemple à des fins de simulation de crise dans le domaine informa tique 2, non détaillées davantage ici.
[0145] Comme mentionné ci-avant, l'émulation de l'attaque est réalisée sur les ressources du domaine in formatique 2 protégées par le service de protection exécutant l'émulation. La requête de mitigation adressée par le dispositif client 3 au dispositif serveur du service de protection doit donc être adap- tée pour être compatible avec le périmètre du service de protection auquel elle est adressée. Autrement dit, les adresses cibles de l'attaque mentionnées dans la requête doivent être celles de ressources protégées par le service de protection et validées avec ce dernier. Un tel mécanisme de validation d'adresses est connu dans le cadre du protocole DOTS et n'est pas décrit en détail ici.
[0146] Dans l'exemple illustratif envisagé ici, on suppose que le dispositif client 3 envoie une telle requête d'émulation au service de protection SP1. La figure 7 illustre les principales étapes mises en œuvre par le service de protection SP1 sur réception de cette requête, et plus particulièrement ici par le module d'émulation 4D de son dispositif serveur 4-1.
[0147] Sur réception de la requête d'émulation (étape G10), le dispositif serveur 4-1 déclenche l'émulation de l'attaque ATTACK sur les ressources qu'il protège (étape G20). Une telle émulation consiste à reproduire l'attaque ATTACK subie par le domaine informatique 2 selon les caractéristiques fournies par le dispositif client 3 dans la requête d'émulation, et en particulier à générer un trafic d'attaque semblable. Le dispositif serveur peut à cet effet s'appuyer sur une bibliothèque de trafics d'attaques collectés au fil du temps.
[0148] Lors de cette émulation, si le service de protection SP1 est capable de traiter l'attaque ainsi émulée (réponse « oui » à l'étape test G30), le dispositif serveur 4-1 dérive à partir de cette simulation des actions de mitigation appropriées en réponse à cette attaque.
[0149] On note que le plan de mitigation, noté ici mplan_emul(SPl), proposé lors de l'émulation par le dispositif serveur 4-1 n'est pas mis en place (c'est-à-dire activé) par ce dernier : du fait de la présence de l'attribut « emulate » dans la requête, celle-ci n'est prise en compte par le dispositif serveur 4-1 qu'à des fins de simulation de l'attaque sur les ressources qu'il protège.
[0150] Le plan de mitigation mplan_emul(SPl) élaboré le cas échéant lors de l'émulation est ensuite fourni au dispositif client 3 en réponse à sa requête d'émulation (étape G40).
[0151] Si le service de protection SP1 n'est pas capable de traiter l'attaque telle qu'émulée par le dispositif serveur 4-1 (réponse « non » à l'étape test G30), le dispositif serveur 4-1 en informe le dispositif client 3 en envoyant en réponse à sa requête d'émulation un message d'erreur tel que décrit précédemment (étape G50).
[0152] En référence à la figure 5, le dispositif client 3 examine la ou les réponse(s) reçue(s) à sa requête d'émulation (selon qu'un ou plusieurs services de protection ont été contactés pour émuler l'attaque) (étape test El 10), autrement dit dans l'exemple illustratif envisagé ici, la réponse du service de protection SP1.
[0153] Si au moins un plan de mitigation mplan_emul(SPi) issu de l'émulation de l'attaque a été fourni au dispositif client 3 par un service de protection autre que le service de protection incapable (réponse « oui » à l'étape test E110), le dispositif client 3 élabore alors à partir de ce plan de mitigation (ou de l'un des plans de mitigation reçus et sélectionné par exemple de façon arbitraire ou en fonction de la richesse des informations contenues dans les plans de mitigation reçus), un plan de mitigation destiné au service de protection incapable, SP2 dans l'exemple envisagé. Dans l'exemple envisagé ici, on suppose que le dispositif client 3 élabore à partir du plan mplan_emul(SPl) un plan g(mplan_emul(SPl)) : il procède à cet effet de façon identique à ce qui a été décrit précédemment pour l'étape E80. Le plan ainsi élaboré g(mplan_emul(SPl)) est ensuite transmis au dispositif serveur 4-2 du service de protection SP2 (étape E90).
[0154] Sinon (réponse « non » à l'étape test E110), il contacte un autre service de protection parmi la pluralité de services de protection protégeant les ressources du domaine informatique 2 pour émuler l'attaque si un tel autre service de protection existe et réitère les étapes E100 et El 10 avec cet autre service de protection qui met alors en œuvre les étapes précédemment décrites de la figure 7.
[0155] On note qu'en cas d'échec des différentes requêtes d'émulation, le dispositif client 3 peut réitérer ses requêtes en fournissant plus de détails sur l'attaque ou en envoyant des captures du trafic de l'attaque aux services de protection.
[0156] En référence à la figure 6, sur réception du plan de mitigation élaboré par le dispositif client 3 (à partir du plan de mitigation mis en place par le service de protection SP1 ou d'un plan de mitigation émulé par ce dernier), via son module de réception 4A et ses moyens de communication 15 (étape F80), le dispositif serveur 4-2, par l'intermédiaire de son module de mise en place 4B, met alors en place, en réponse à l'attaque ATTACK, un plan de mitigation de cette attaque dérivé du plan de mitigation g(mplan(SPl)) ou g(mplan_emul(SPl)) reçu du dispositif client 3 (étape F90). Par « dérivé », on entend ici que le plan de mitigation mis en place peut être identique au plan reçu du dispositif client 3, être élaboré par le dispositif serveur 4-2 à partir de tout ou partie des informations (règles et actions de mitigation notamment) contenues dans le plan de mitigation reçu du dispositif client 3, ou s'inspirer de la logique du plan reçu. L'invention ne se limite pas à une exécution telle quelle par le dispositif serveur 4-2 du plan de mitigation reçu du dispositif client 3, mais inclut également une version adaptée de celui-ci.
[0157] On note que si le plan de mitigation élaboré par le dispositif serveur 4-2 à partir du plan fourni par le dispositif client 3 n'est pas suffisant pour mettre fin à l'attaque ATTACK, le dispositif client 3 en est informé (soit par le dispositif serveur 4-2 directement, soit par un autre biais), et peut alors élaborer et communiquer au dispositif serveur 4-2 un autre plan de mitigation dérivé d'un plan de mitigation fourni par un autre service de protection que le service de protection SP1.
[0158] La branche (I) de la figure 5 qui vient d'être décrite fait référence à une incapacité fonctionnelle du service de protection SP2 pour traiter l'attaque ATTACK ciblant les ressources du domaine informatique 2 qu'il protège, et à l'assistance fournie par le dispositif client 3 au service de protection SP2 pour traiter l'attaque ATTACK dans le cas d'une telle incapacité fonctionnelle. Comme mentionné précédemment, l'incapacité du service de protection SP2 peut en variante provenir d'une insuffisance capacitaire, autrement dit, le service de protection SP2 ne dispose pas de ressources suffisantes pour mitiger l'attaque, par exemple parce que celle-ci est de grande ampleur.
[0159] Dans ce cas (branche II de la figure 5), le dispositif client 3, sur réception du message d'erreur transmis par le dispositif serveur 4-2, interroge au moins un autre service de protection parmi les services de protection SP1, ..., SPk, ..., SPN, k¹2, protégeant des ressources du domaine informatique 2, pour déterminer s'il est apte à fournir une assistance capacitaire au service de protection SP2 pour mitiger l'attaque ATTACK (étape E120). A cet effet, il envoie, dans le mode de réalisation décrit ici, à au moins l'un des services de protection SP1, ..., SPk, ..., SPN, k¹2, une requête d'assistance DOTS. Dans l'exemple illustratif envisagé ici, on suppose que cette requête d'assistance est envoyée au service de protection SP1 et plus particulièrement à son dispositif serveur 4-1. On note qu'une telle requête n'existe pas dans la version actuelle du protocole DOTS et nécessite d'être définie pour les besoins de l'invention. Une telle requête est par exemple nommée « Request Assisted Mitigation ».
[0160] Dans le mode de réalisation décrit ici, le corps de la requête d'assistance « Request Assisted Mitigation » comprend notamment les attributs suivants :
- un attribut nommé ici « type » permettant au dispositif client 3 de préciser l'urgence de l'assistance requise, à savoir si l'assistance requise doit être fournie immédiatement ou de manière différée ; et
- un attribut nommé ici « required_capacity » permettant au dispositif client 3 de préciser les ressources capacitaires minimales requises pour fournir une assistance au service de protection incapable SP2 (notamment la quantité et la nature des ressources requises).
[0161] Cette liste d'attributs n'est aucunement exhaustive ni limitative en soi. D'autres attributs peuvent être envisagés en variante ou en complément des attributs précités.
[0162] Sur réception d'une telle requête d'assistance par le dispositif serveur 4-1, celui-ci vérifie si le service de protection SP1 a la capacité nécessaire pour la mise en place de l'assistance requise. Si tel est le cas et si le service de protection SP1 accepte de fournir cette assistance, le dispositif serveur 4-1 répond au dispositif client 3 avec un message de réponse DOTS « 2.01 Created », dans lequel il inclut des informations pour la mise en place de l'assistance que propose de fournir le service de protection SP1. En particulier, dans le mode de réalisation décrit ici, un attribut nommé par exemple « Scrubbing_Endpoint(s) » est inclus dans le corps du message de réponse et contient l'adresse ou les adresses IP (ou le ou les noms de domaines) de la ou des entités avec lesquelles le dispositif serveur 4-2 peut établir une communication pour bénéficier de l'assistance fournie par le service de protection SP2 pour résoudre l'attaque ATTACK. Une telle entité est par exemple un centre de nettoyage (plus communément appelé « scrubbing center ») du service de protection SP1 en charge du filtrage de tout ou partie du trafic suspect qui lui parvient.
[0163] D'autres informations peuvent être incluses dans la réponse, comme par exemple une capacité dis ponible au niveau du service de protection fournissant son assistance, une ou plusieurs clés de sécurité destinées à être utilisées lors de cette assistance (par exemple dans le cadre d'un tunnel de communication sécurisé établi entre le service de protection incapable et le service de protection fournissant son assistance), une durée de vie de l'assistance fournie par le service de protection, etc.
[0164] Sur réception des informations fournies par le ou les services de protection se déclarant aptes à fournir une assistance au service de protection SP2 incapable de traiter l'attaque, le dispositif client 3 les mémorise dans sa mémoire non volatile 9 (étape E130). On note qu'en fonction de la durée de vie associée le cas échéant à l'assistance proposée par les services de protection, ces informa tions ont vocation à être utilisées pour traiter l'attaque ATTACK et prêter assistance au service de protection SP2 incapable de traiter l'attaque ATTACK, mais également si besoin ultérieurement pour ce même service de protection ou un autre.
[0165] Puis il élabore, par le biais de son module 3B d'élaboration, un plan de mitigation destiné au ser vice de protection SP2 utilisant l'assistance d'un ou de plusieurs services de protection s'étant dé clarés aptes à fournir une telle assistance (étape E140).
[0166] Dans l'exemple illustratif considéré ici, il élabore par exemple un plan de mitigation s'appuyant sur l'assistance proposée par le service de protection SP1. Plus particulièrement, ce plan de mitigation comprend les informations fournies par le service de protection SP1 pour établir une communica tion entre le service de protection SP2 et le service de protection SP1 afin de lui permettre de bé néficier de l'assistance du service de protection SP1 pour la mitigation de l'attaque ATTACK. Si plu sieurs services de protection ont répondu favorablement pour fournir une assistance au service de protection SP2, le plan de mitigation peut comprendre les informations indiquées au dispositif client 3 par tout ou partie de ces services de protection aptes à fournir leur assistance.
[0167] Dans le mode de réalisation décrit ici, le plan de mitigation comprenant les informations permet tant au service de protection SP2 de bénéficier de l'assistance d'un ou de plusieurs autres services de protection pour mitiger l'attaque est transmis par le dispositif client 3 au dispositif serveur 4-1 du service de protection SP1 dans une requête de mitigation DOTS « Request Mitigation » compre nant notamment comme attributs l'identifiant de mitigation de l'attaque « mid » et un attribut nommé « assist-on » comprenant les informations fournies par le ou les services de protection ayant proposé leur assistance pour établir une communication avec lui ou eux (SP1 ici) (étape E150).
[0168] En référence à la figure 6, sur réception de ce plan de mitigation (étape F80), le dispositif serveur 4-2, par l'intermédiaire de son module de mise en place 4B, met alors en place, en réponse à l'at taque ATTACK ciblant les ressources du domaine informatique 2 qu'il protège, un plan de mitiga tion de cette attaque dérivé du plan de mitigation reçu du dispositif client 3 (étape F90). Ce plan de mitigation consiste notamment à établir une communication pouvant être sécurisée (par exemple un tunnel sécurisé) avec la ou les entités du service de protection SP1 identifiées dans les informations fournies dans le plan de mitigation (« scrubbing center » du service de protection SP1) et à rediriger via la communication ainsi établie, tout ou partie du trafic suspect (i.e., des données suspectées d'être associées à l'attaque) vers le scrubbing center du service de protection SP1 pour traitement ou filtrage. Des mécanismes connus de l'état de la technique peuvent être uti lisés à cet effet pour établir une telle communication comme par exemple la suite de protocoles IPsec.
[0169] Le trafic suspect redirigé et acheminé vers le service de protection SP1 est alors traité par ce der nier. Le trafic considéré comme légitime peut être retourné vers le service de protection SP2 ou être acheminé directement vers le domaine informatique 2 par le service de protection SP1.
[0170] Dans le mode de réalisation décrit ici, le dispositif client 3 sollicite les services de protection SP1,
..., SPN distincts du service de protection SP2 suite à la détection de l'attaque ATTACK et dès lors qu'il a été informé de l'incapacité du service de protection SP2 à traiter celle-ci. En variante, afin d'anticiper les problèmes liés à une défaillance capacitaire de l'un des services de protection (par exemple pour pouvoir absorber le trafic d'une attaque dont le volume dépasse un certain seuil), le dispositif client 3 peut préconfigurer l'assistance susceptible d'être fournie par les services de pro tection SP1,...,SPN. A cet effet, il peut envoyer, indépendamment de la détection d'une attaque in formatique contre des ressources du domaine informatique 2, une requête d'assistance « Request Assisted Mitigation » à tout ou partie des services de protection SP1, ..., SPN (plus particulièrement à leurs dispositifs serveurs 4-1, ..., 4-N) dans laquelle l'attribut « type » est positionné par exemple à la valeur « preconfigured ». Le dispositif client 3 peut éventuellement inclure également dans la requête une estimation de la capacité nécessaire pour l'assistance requise. Une telle estimation peut être réalisée au moyen d'une heuristique reposant sur l'analyse de compteurs SNMP (Simple Network Management Protocol) ou NETCONF permettant d'estimer la volumétrie des paquets de données échangés sur un réseau. L'envoi de cette requête aux services de protection peut se faire de manière simultanée ou séquentielle.
[0171] Sur réception de cette requête par un dispositif serveur d'un service de protection concerné, ce dernier vérifie s'il dispose de la capacité nécessaire pour la mise en place d'une telle assistance, comme décrit ci-avant. Si la demande d'assistance est acceptée par le service de protection, le dis positif serveur répond avec un message « 2.01 Created », incluant dans le corps de la réponse les informations décrites précédemment permettant d'établir une communication avec le service de protection. Une durée de vie de l'assistance proposée peut également être incluse dans le message de réponse. La réception et la mémorisation de ces informations par le dispositif client 3 dans sa mémoire non volatile 9 achève la pré-configuration de l'assistance.
[0172] Ainsi, en cas de détection d'une attaque ciblant les ressources du domaine informatique 2, le dis positif client 3 peut alors, dès l'envoi de la requête de mitigation « Request Mitigation » aux ser vices de protection protégeant les ressources affectées par l'attaque, requérir l'intervention de ces services de protection tout en insérant dans la requête l'offre d'assistance préconfigurée offerte par les services de protection (autrement dit les informations transmises par ces derniers pour per mettre d'établir une communication avec eux aux fins de la fourniture de cette assistance), dès lors que celle-ci a encore une durée de vie valide. Sur réception de cette requête, chaque service de mitigation procède à l'exécution d'un plan de mitigation en mettant en place des contre- mesures contre l'attaque. S'il n'est pas en mesure de traiter le trafic suspect pour des raisons capacitaires, il peut ainsi réacheminer une partie de l'excédent du trafic vers un ou plusieurs services de protec tion ayant offert son assistance. A cet effet, il établit une communication avec les entités idoines de ces services de protection (« scrubbing centers ») en utilisant les informations communiquées dans la requête de mitigation. Une fois cette communication établie, le service de protection défaillant peut rediriger l'excédent du trafic suspect qu'il ne peut pas gérer vers un service de protection lui prêtant assistance. Cet excédent est alors géré par le service de protection fournissant l'assistance, tandis que le trafic légitime peut être retourné vers le service de protection défaillant ou être ache miné directement vers le domaine informatique 2.
[0173] On note que si un service de protection n'est plus en mesure de fournir son assistance à un service de protection défaillant ou si le dispositif client 3 ne renouvelle pas la demande après expiration de la durée de vie de son offre d'assistance, alors le dispositif client 3 ne doit plus inclure cette offre dans la requête de mitigation.
[0174] L'invention permet donc de manière générale de fournir une assistance à un service de protection défaillant en s'appuyant sur les autres services de protection protégeant les ressources du domaine informatique 2, quelle que soit la raison de cette défaillance. On a évoqué dans les exemples illus tratifs fournis une défaillance de type capacitaire ou une défaillance fonctionnelle, toutefois ces exemples ne sont pas limitatifs en soi et on peut envisager d'autres types de défaillances.
[0175] Par ailleurs, dans un mode particulier de réalisation, outre la fourniture de cette assistance, on peut envisager que le dispositif client 3 soit également en mesure, lorsque l'attaque relève du péri mètre d'action de plusieurs services de protection parmi les services de protection SP1, ..., SPN, de vérifier la compatibilité des plans de mitigation mis en place par chacun des services de protection concernés par l'attaque, et de coordonner le cas échéant la cohérence de ces plans de mitigation entre eux. Par exemple, à l'issue de l'étape E30, lorsque le dispositif client 3 a été informé de l'en semble des plans de mitigation mis en place par les services de protection concernés par l'attaque, il peut vérifier si les plans de mitigation obtenus sont compatibles entre eux pour traiter l'attaque ATTACK.
[0176] Un exemple d'incompatibilité (autrement dit d'anomalie entre les plans de mitigation) est la créa tion d'une boucle de routage par l'association de plans de mitigation non coordonnés mis en place par plusieurs services de protection. Pour illustrer une telle boucle de routage, prenons l'exemple de la figure 1 et du domaine client CL relié à deux réseaux transitaires TN1 et TN2 via respective ment les liens d'interconnexion R2 et RI. Sur détection d'une attaque, on suppose que le service DPS1 met en place un plan de mitigation redirigeant tout le trafic légitime vers le lien d'intercon nexion RI, et que le service DPS2 met en place un plan de mitigation redirigeant tout le trafic légi time vers le lien d'interconnexion R2. Ce faisant, une boucle de routage est créée : le trafic légi time ne peut plus être acheminé vers le domaine client CL. Cette boucle de routage n'est toutefois pas détectable par les services de protection DPS1 et DPS2.
[0177] Au contraire, dans le contexte de l'invention où le dispositif client 3 dispose à l'issue de l'étape E40 des plans de mitigation mis en place par les différents services de protection en réponse à l'attaque ATTACK, le dispositif client 3 a la possibilité de détecter une telle boucle de routage, ou plus géné ralement une incompatibilité entre les plans de mitigation mis en place. On peut noter que le do maine client CL peut également détecter une telle anomalie en observant le trafic entrant/sortant du domaine informatique 2 (une boucle de routage telle que décrite ci-avant peut se manifester typiquement par une absence de trafic entrant dans le domaine informatique).
[0178] Sur détection d'une telle incompatibilité entre les plans de mitigation mis en place par au moins deux services de protection désignés par SPkl et SPk2, le dispositif client 3 coordonne, dans un mode particulier de réalisation, un ajustement de tout ou partie des plans de mitigation incompa tibles de sorte à éliminer l'incompatibilité. A cet effet, il peut procéder par exemple selon l'une ou l'autre des variantes de réalisation suivantes.
[0179] Selon une première variante de réalisation, le dispositif client 3 sélectionne au moins l'un des ser vices de protection « en conflit » (par exemple SPkl) et notifie au dispositif serveur (4-kl) de ce dernier l'incompatibilité entre les plans de mitigation (par exemple l'existence d'une boucle de rou tage). Le service de protection notifié peut être sélectionné arbitrairement parmi les services de protection en conflit, ou on peut envisager de sélectionner par exemple celui qui présente le plan de mitigation le moins efficace. Pour notifier au dispositif serveur du service de protection sélec tionné l'incompatibilité détectée, le dispositif client 3 peut lui envoyer une requête DOTS de mitiga tion avec un attribut, nouvellement introduit dans le protocole DOTS pour les besoins de l'inven tion, nommé ici « thirdparty-dps-conflict » visant à requérir un ajustement, autrement dit une mise à jour, du plan de mitigation proposé par le service de protection en question (SPkl ici). Cette re quête peut contenir en outre des éléments nécessaires pour identifier le conflit, comme par exemple tout ou partie des plans de mitigation présentant une incompatibilité avec celui du service de protection en question (typiquement les règles et les actions en conflit).
[0180] Sur réception de cette requête, le dispositif serveur 4-kl modifie son plan de mitigation pour éviter l'incompatibilité et transmet son plan modifié du dispositif client 3. Le dispositif client 3 vérifie si l'incompatibilité est effectivement résolue et si aucune autre incompatibilité n'a été créée du fait de l'ajustement du plan du service de protection SPkl.
[0181] Selon une deuxième variante, le dispositif client 3 notifie tous les dispositifs serveurs des services de protection impliqués dans l'incompatibilité détectée pour leur demander d'ajuster leurs plans de mitigation. Dans l'exemple illustratif envisagé ci-dessus, il notifie ainsi les dispositifs serveurs 4-kl et 4-k2. Il peut à cet effet utiliser une requête de mitigation avec un attribut « thirdparty-dps-con- flict » telle que décrite ci-avant.
[0182] Sur réception de cette requête, chaque dispositif serveur procède à un ajustement de son plan de mitigation pour résoudre l'incompatibilité détectée et transmet son plan de mitigation ajusté au dis positif client 3. Le dispositif client 3 vérifie la compatibilité des plans de mitigation ajustés et en cas d'incompatibilité procède de nouveau selon la première variante ou la deuxième variante.
[0183] On note que le dispositif client 3 peut contacter à fréquence régulière les dispositifs serveurs 4-k, k=l,...,N pour vérifier si une modification a été apportée à leurs plans de mitigation, et le cas échéant, procéder à la vérification de la compatibilité des mises à jour avec les plans de mitigation existants. Alternativement, chaque dispositif serveur peut notifier le dispositif client 3 d'une mise à jour de son plan de mitigation.
[0184] L'invention offre ainsi une solution efficace permettant de valoriser l'utilisation d'une pluralité de services de protection pour protéger les ressources d'un domaine informatique client. Elle s'ap plique de façon avantageuse mais non limitative lorsque les services de protection sont gérés par des entités administratives distinctes. Cette invention s'appuie avantageusement sur la visibilité dont dispose le domaine informatique client pour coordonner les actions des services de protec tion.

Claims

Revendications
[Revendication 1] Procédé d'assistance mis en œuvre par un dispositif (3) gérant des ressources d'un domaine informatique (2), lesdites ressources étant protégées par une pluralité de services de protection contre des attaques informatiques, ledit procédé comprenant : une étape de détermination (E20,E50) d'une incapacité d'un premier service de protection parmi ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique ; une étape d'élaboration (E80,E140) d'un plan de mitigation de ladite attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection parmi ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et une étape de transmission (E90,E150) du plan de mitigation élaboré au premier service de protection pour traiter ladite attaque.
[Revendication 2] Procédé selon la revendication 1 dans lequel : le deuxième service de protection a mis en place un plan de mitigation en réponse à ladite attaque ; ladite incapacité du premier service de protection provient d'une méconnaissance de ladite attaque par le premier service de protection ; et le plan de mitigation transmis au premier service de protection est élaboré (E80) en adaptant ledit plan de mitigation mis en place par le deuxième service de protection aux ressources du domaine informatique protégées par le premier service de protection.
[Revendication 3] Procédé selon la revendication 1 dans lequel, lorsque ladite attaque relève d'un périmètre d'action du premier service de protection uniquement et ladite incapacité du premier service de protection provient d'une méconnaissance de l'attaque par le premier service de protection, ledit procédé comprend en outre : une étape d'envoi (E100) audit deuxième service de protection d'une requête d'émulation de ladite attaque sur au moins une ressource du domaine informatique protégée par le deuxième service de protection ; et une étape d'obtention (El 10) d'un plan de mitigation proposé lors de l'émulation de l'attaque par le deuxième service de protection pour traiter cette attaque ; le plan de mitigation transmis au premier dispositif étant élaboré à partir du plan de mitigation obtenu lors de l'étape d'obtention en l'adaptant aux ressources du domaine informatique protégées par le premier service de protection.
[Revendication 4] Procédé selon la revendication 1 dans lequel ladite incapacité du premier service de protection provient d'une insuffisance de ressources disponibles au niveau du premier service de protection pour mitiger ladite attaque, ledit procédé comprenant une étape d'obtention (E130) auprès dudit deuxième service de protection d'au moins une information permettant un établissement d'une communication entre ledit premier service de protection et le deuxième service de protection pour l'assister dans la mitigation de ladite attaque, le plan de mitigation transmis au premier service de protection comprenant ladite au moins une information obtenue.
[Revendication 5] Procédé selon l'une quelconque des revendications 1 à 4 comprenant : une étape d'interrogation (E120) de tout ou partie de ladite pluralité de services de protection protégeant des ressources du domaine informatique pour déterminer lesdits services de protection aptes à fournir une assistance pour mitiger une attaque informatique à au moins un autre service de protection de ladite pluralité de services de protection ; et une étape de mémorisation (E130), pour chaque service de protection se déclarant apte à fournir une assistance, d'au moins une information fournie par ce service de protection permettant une mise en œuvre de cette assistance.
[Revendication 6] Procédé selon la revendication 5 dans lequel ladite au moins une information comprend au moins un élément parmi : une capacité disponible au niveau dudit service de protection apte pour ladite assistance ; une information permettant l'établissement d'une communication avec ledit service de protection apte à fournir une assistance ; au moins une clé de sécurité destinée à être utilisée lors de ladite assistance avec le service de protection apte à fournir une assistance ; une durée de vie de l'assistance fournie par ledit service de protection apte à fournir une assistance.
[Revendication 7] Procédé selon la revendication 5 ou 6 dans lequel lors de l'étape d'interrogation, le dispositif indique auxdits services de protection interrogés une capacité minimale dont doit disposer un service de protection se déclarant apte à fournir ladite assistance.
[Revendication 8] Procédé selon l'une quelconque des revendications 5 à 7 dans lequel ladite étape d'interrogation est mise en œuvre suite à la détection d'une attaque ciblant au moins une ressource du domaine informatique.
[Revendication 9] Procédé selon l'une quelconque des revendications 1 à 8 comprenant, après détection de ladite attaque, une étape d'envoi (E30) à tout ou partie des services de protection de ladite pluralité de services de protection , d'une requête d'obtention d'un plan de mitigation mis en place par ces services de protection en réponse à ladite attaque.
[Revendication 10] Procédé selon l'une quelconque des revendications 1 à 9 comprenant, lorsque ladite attaque se trouve dans un périmètre d'action de plusieurs services de protection de ladite pluralité de services de protection : une étape de vérification de la compatibilité des plans de mitigation mis en place en réponse à ladite attaque par lesdits plusieurs services de protection ; et si au moins une incompatibilité est détectée entre desdits plans de mitigation lors de l'étape de vérification, une étape de coordination d'un ajustement de tout ou partie desdits plans de mitigation incompatibles de sorte à éliminer ladite au moins une incompatibilité.
[Revendication 11] Procédé d'obtention, par un premier service de protection d'une pluralité de services de protection contre des attaques informatiques protégeant des ressources d'un domaine informatique, d'un plan de mitigation d'une attaque informatique ciblant au moins une ressource du domaine informatique, ledit procédé comprenant, suite à une détection d'une incapacité du premier service de protection à traiter ladite attaque : une étape de réception (F80) d'un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique, à partir d'un plan de mitigation obtenu d'un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et une étape de mise en place (F90), en réponse à ladite attaque, d'un plan de mitigation de l'attaque dérivé du plan de mitigation reçu du dispositif pour traiter ladite attaque.
[Revendication 12] Procédé selon la revendication 11 dans lequel l'étape de mise en place du plan de mitigation comprend, lorsque ledit plan de mitigation utilise une assistance fournie par au moins ledit deuxième service de protection, un acheminement de données suspectées d'être associées à ladite attaque vers ledit deuxième service de protection pour un traitement desdites données.
[Revendication 13] Procédé selon la revendication 12 dans lequel lesdites données sont acheminées vers ledit deuxième service de protection dans un tunnel sécurisé établi avec ledit deuxième service de protection au moyen d'au moins une information contenue dans ledit plan de mitigation reçu du dispositif.
[Revendication 14] Programme d'ordinateur (PROG3,PROG4) comportant des instructions pour l'exécution d'un procédé selon l'une quelconque des revendications 1 à 13, lorsque ledit programme est exécuté par un ordinateur.
[Revendication 15] Support d'enregistrement lisible par un ordinateur sur lequel est enregistré un programme d'ordinateur selon la revendication 14.
[Revendication 16] Dispositif (3) gérant des ressources d'un domaine informatique, configuré pour communiquer avec une pluralité de services de protection contre des attaques informatiques protégeant lesdites ressources du domaine informatique, ledit dispositif comprenant : un module de détermination (3A), configuré pour déterminer une incapacité d'un premier service de protection de ladite pluralité de services de protection, à traiter une attaque informatique ciblant au moins une ressource du domaine informatique ; un module d'élaboration (3B), configuré pour élaborer un plan de mitigation de ladite attaque à partir d'un plan de mitigation obtenu d'un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et un module de transmission (3C), configuré pour transmettre le plan de mitigation élaboré au premier service de protection pour traiter ladite attaque.
[Revendication 17] Dispositif (SPk) d'un premier service de protection d'une pluralité de services de protection contre des attaques informatiques protégeant des ressources d'un domaine informatique, au moins une dite ressource du domaine informatique étant ciblée par une attaque informatique, ledit dispositif comprenant des modules activés suite à une détection d'une incapacité dudit dispositif à traiter ladite attaque, lesdits modules comprenant : un module de réception, configuré pour recevoir un plan de mitigation élaboré par un dispositif gérant lesdites ressources du domaine informatique à partir d'un plan de mitigation obtenu d'un deuxième service de protection de ladite pluralité de services de protection ou utilisant une assistance fournie par au moins ledit deuxième service de protection ; et un module de mise en place, configuré pour mettre en place en réponse à ladite attaque un plan de mitigation dérivé du plan de mitigation reçu.
[Revendication 18] Système (1) de protection d'un domaine informatique comprenant : une pluralité de services de protection contre des attaques informatiques protégeant des ressources du domaine informatique ; un dispositif gérant lesdites ressources du domaine informatique, conforme à la revendication 16 et configuré pour communiquer avec lesdits services de protection ; ladite pluralité de services de protection comprenant au moins : un premier service de protection comportant un dispositif selon la revendication 17 incapable de traiter une attaque informatique ciblant au moins une des ressources du domaine informatique ; et un deuxième service de protection configuré pour fournir au dispositif gérant les ressources du domaine informatique un plan de mitigation de ladite attaque ou une assistance au premier service de protection pour traiter ladite attaque.
EP20824303.0A 2019-11-29 2020-11-26 Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes Pending EP4066460A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1913504A FR3103920A1 (fr) 2019-11-29 2019-11-29 Procédé d’assistance pour la gestion d’une attaque informatique, dispositif et système associés.
PCT/FR2020/052180 WO2021105617A1 (fr) 2019-11-29 2020-11-26 Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes

Publications (1)

Publication Number Publication Date
EP4066460A1 true EP4066460A1 (fr) 2022-10-05

Family

ID=70295236

Family Applications (1)

Application Number Title Priority Date Filing Date
EP20824303.0A Pending EP4066460A1 (fr) 2019-11-29 2020-11-26 Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes

Country Status (4)

Country Link
US (1) US20230082637A1 (fr)
EP (1) EP4066460A1 (fr)
FR (1) FR3103920A1 (fr)
WO (1) WO2021105617A1 (fr)

Family Cites Families (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8677489B2 (en) * 2012-01-24 2014-03-18 L3 Communications Corporation Methods and apparatus for managing network traffic

Also Published As

Publication number Publication date
WO2021105617A1 (fr) 2021-06-03
FR3103920A1 (fr) 2021-06-04
US20230082637A1 (en) 2023-03-16

Similar Documents

Publication Publication Date Title
WO2017220892A1 (fr) Procédé de communication udp via des chemins multiples entre deux terminaux
JP4829982B2 (ja) ピアツーピア通信の検出及び制御
JP2022531878A (ja) Ｄｎｓメッセージを使用してコンピュータ・フォレンジック・データを選択的に収集するためのシステムおよび方法
KR20100087032A (ko) 보안 실행 지점에 보안 연관 정보를 선택적으로 로딩하는 방법
FR3096533A1 (fr) Procédé de gestion d’une communication entre terminaux dans un réseau de communication, et dispositifs pour la mise en œuvre du procédé
EP3857848B1 (fr) Procédé d'allocation d'un identifiant à un noeud client, procédé d'enregistrement d'un identifiant, dispositif, noeud client, serveur et programmes d'ordinateurs correspondants
EP3972218A1 (fr) Procédé d'accès sécurisé à des ressources via un réseau de télécommunication et système de contrôle associé
EP4066461B1 (fr) Procédé de coordination de la mitigation d'une attaque informatique, dispositif et système associés
EP4066460A1 (fr) Procede d'assistance pour la gestion d'une attaque informatique, dispositif et systeme associes
WO2019211548A1 (fr) Procédé d'envoi d'une information et de réception d'une information pour la gestion de réputation d'une ressource ip
EP3871381B1 (fr) Technique de collecte d'informations relatives à un flux acheminé dans un réseau
US20100250737A1 (en) Detecting and controlling peer-to-peer traffic
EP3815336A1 (fr) Procédés de gestion du trafic associé à un domaine client, serveur, noeud client et programme d'ordinateur correspondants
FR3105486A1 (fr) Procédé de détection d’un comportement malveillant dans un réseau de communication, dispositif, équipement d’accès audit réseau, procédé de détection d’une attaque distribuée dans ledit réseau, dispositif, équipement nœud et programmes d’ordinateur correspondants
EP1986398A1 (fr) Procédé de filtrage de flots indésirables en provenance d'un terminal présumé malveillant
FR3079642A1 (fr) Capteur d'intrusion informatique et procede de creation d'un capteur d'intrusion
FR3044195A1 (fr) Procede et dispositif de traitement d'une annonce non legitime d'un bloc d'adresses ip
EP4128701A1 (fr) Procédé de gestion de communications et dispositifs associés
WO2020065234A1 (fr) Procédés de protection d'un domaine client, nœud client, serveur et programmes d'ordinateur correspondants
FR3136075A1 (fr) Infrastructure de sécurité ; procédé et produit programme d’ordinateur associés.
WO2023117802A1 (fr) Procédés d'identification d'au moins un serveur de mitigation et de protection d'un domaine client contre une attaque informatique, dispositifs et signal correspondants
FR3110802A1 (fr) Procédé de contrôle de l’attribution d’une adresse IP à un équipement client dans un réseau de communication local, procédé de traitement d’une requête d’attribution d’une adresse IP à un équipement client dans un réseau de communication local, dispositifs, équipement d’accès, équipement serveur et programmes d’ordinateur correspondants.
FR3086821A1 (fr) Procedes de collaboration et de demande de collaboration entre services de protection associes a au moins un domaine, agents et programme d’ordinateur correspondants.
WO2008031967A2 (fr) Procédé de supervision d'une session d'accès a un service établie par un terminal client au moyen d'un protocole de configuration dynamique
WO2007113439A2 (fr) Systeme et procede de controle d'acces d'un dispositif client a un reseau de serveurs dynamiques

Legal Events

Date Code Title Description
STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: UNKNOWN

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: THE INTERNATIONAL PUBLICATION HAS BEEN MADE

PUAI Public reference made under article 153(3) epc to a published international application that has entered the european phase

Free format text: ORIGINAL CODE: 0009012

STAA Information on the status of an ep patent application or granted ep patent

Free format text: STATUS: REQUEST FOR EXAMINATION WAS MADE

17P Request for examination filed

Effective date: 20220616

AK Designated contracting states

Kind code of ref document: A1

Designated state(s): AL AT BE BG CH CY CZ DE DK EE ES FI FR GB GR HR HU IE IS IT LI LT LU LV MC MK MT NL NO PL PT RO RS SE SI SK SM TR

DAV Request for validation of the european patent (deleted)
DAX Request for extension of the european patent (deleted)
RAP3 Party data changed (applicant data changed or rights of an application transferred)

Owner name: ORANGE