COMPUTER-IMPLEMENTED METHOD FOR TESTING THE CYBERSECURITY OF A TARGET ENVIRONMENT

Description

[0001] The invention relates to the field of cybersecurity.

[0002] In the cybersecurity industry, various commercial and open-source tools, techniques, and methods exist for the passive or active discovery of vulnerabilities. These include simple "fuzzing" tools (injecting random data into software), penetration testing programs ("pentesting") similar to "bug bounty" campaigns conducted by ethical hackers, and tools capable of automatically identifying vulnerabilities in a target.

[0003] These tools and analyses produce security documents in a structured or unstructured format, which describe security problems succinctly or extensively, in particular vulnerabilities and their modes of operation.

[0004] For example, a security document might describe a vulnerability in a field of an HTTP message sent by an attacker to a website developed with a specific software version. This HTTP message also contains a specific attack payload, allowing the attacker to gain elevated privileges and become an administrator, or to access the passwords and logins of the website's users.

[0005] Once a vulnerability has been detected and validated, it is generally documented through a publicly available description published in a standardized text format, known as CVEs (Common Vulnerabilities and Exposures). However, CVEs are far from being fully standardized, and there are almost as many variations as there are CVEs, making their systematic exploitation impossible. Furthermore, CVEs are not the only formats for presenting vulnerabilities, nor are they the only repositories for publication.

[0006] To address this problem, several academic works have proposed ontologies and annotation models for analyzing textual descriptions associated with vulnerabilities, such as CVE, CWE, CAPEC descriptions, security bulletins, etc. The analysis techniques used are based on algorithms developed in the field of natural language processing, to automatically extract knowledge related to the vulnerability or attack from these documents, such as the software version, the target function, the attack method, and its consequences.

[0007] This academic work focuses primarily on the construction of knowledge graphs to provide assistance to analysts, notably by specifying ontologies adapted to this domain of knowledge.

[0008] For example, the STUCCO project offers an ontology for structuring data from intrusion detection systems, network flows, CVEs, etc. This allows data to be collected and structured with an ontology that links different entities together, such as: software, vulnerability, malware, attacker, etc.

[0009] Another example is the University of Maryland Baltimore County (UMBC), which proposed the UCO ontology dedicated to cybersecurity to structure text documents and standard security structures such as CVE, CAPEC, CPE, CVSS, OpenIOC.

[0010] We can also mention the MITRE organization, which offers the STIX (Structured Threat Information Expression) standard. This standard structures and unifies the sharing of security information and provides several extensions to include data from various sources. STIX also allows for the description of multiple entities to model a threat and outline the generic steps of an attack chain, similar to the Tactics, Techniques, and Procedures (TTP) model, which relies on different entities such as malware, attack patterns, and the consequences of an attack.

[0011] But here again, no single ontology is truly prevalent, and information concerning vulnerabilities is scattered. In the absence of a coherent view of vulnerabilities, and in order to aid in risk prevention management, several proposals have been formulated to model the successive actions of attackers to carry out an attack, such as attack trees, attack graphs, or Petri nets. These models differ according to the chosen representation (tree, graph, etc.) and the attributes that constitute it (events, actions, network logs, etc.).

[0012] Various patent applications have proposed techniques for generating attack graphs and analyzing vulnerabilities.

[0013] Thus, WO2007 / 143226 A2 describes a method for automatically generating attack graphs and establishing links between attack states and their vulnerability prerequisites. This method only describes the generation of a prerequisite graph by linking states to vulnerabilities to establish an attack path on one or more systems. However, it requires complex inputs and cannot rely solely on knowledge of vulnerability descriptions and their contexts.

[0014] US 7 013 395 B1 also describes a method for generating attack graphs to analyze risk, but this method focuses exclusively on a graph-based approach where nodes represent attack states, and links represent changes in state resulting from actions by the attacker or a user. To do this, it uses structured templates describing the attack steps as input, along with configuration files describing the target environments. This is complex and must be revisited with each new environment.

[0015] Finally, the article by Sheyne et al., "Automated generation and analysis of attack graphs," in Proceedings of the 2002 IEEE Symposium on Security and Privacy, SP '02, pages 273-, Washington, DC, USA, 2002. IEEE Computer Society, proposes a method for generating attack graphs using model checking to find paths in a system of transitions that satisfy certain properties. This approach also requires, as input, a mathematical formalization of the possible states and transitions, notably using preconditions. It is therefore complex and lacks flexibility.

[0016] Finally, among cybersecurity analysis tools, Tenable's Nessus tool stands out. It maps vulnerabilities and provides scan reports. Tenable.sc and tenable.io also allow for prioritizing vulnerabilities by associating them with exploitability scores. In France, Ambionics Security offers a vulnerability monitoring solution for web applications, mapping, detecting, and exploiting vulnerabilities to assess their security. The Orange group, through its cyberdefense division, also offers a Security Operations Center (SOC) for managed vulnerability monitoring, including vulnerability tracking and analysis.

[0017] It is clear from the above that cybersecurity is a highly fragmented field with a multitude of approaches and solutions that are more or less interconnected. This results in a strong dependence on the operators of these tools, and it is impossible to automate cybersecurity testing of an environment without making significant investments. Furthermore, once an environment has been tested, the slightest change can invalidate the analysis, and it is difficult to anticipate the consequences of such a change.

[0018] The invention improves the situation. To this end, it proposes a computer-implemented method for testing the cybersecurity of a target environment, comprising: a. Receive target environment data including software elements, b. Access a vulnerability database, each vulnerability being defined by a tuple associating a vulnerability identifier, a list of means defining the means used to exploit the vulnerability, and a list of consequences defining the consequences of exploiting the vulnerability, and extract a list of vulnerabilities including all vulnerabilities including a vulnerability identifier associated with a software element included in the target environment data, c. Construct a list of vulnerability chains from the vulnerability list by initializing at least one pair including an empty list as the current list and one of the vulnerabilities from the vulnerability list as the current vulnerability, and for each pair, performing the following operations c.1.For each given vulnerability in the list of vulnerabilities distinct from the current vulnerability and absent from the tuples in the current list, compare the consequences of the current vulnerability with the means of the given vulnerability, and, c.2. Whenever a similarity is found between a consequence in the list of consequences of the current vulnerability and a means in the list of means of the given vulnerability, c.2.i. Define one or more new chains by adding to each of the chains in the current list whose last tuple includes the current vulnerability a tuple associating the given vulnerability, a similarity identifier, the consequence from the list of consequences of the current vulnerability, and the means from the list of means of the given vulnerability, c.2.ii. Add the new chain(s) to the list of vulnerability chains, c.2.iii. Repeat operations a. and b.with the given vulnerability as the current vulnerability, and the list of vulnerability chains as the current list.

[0019] This system is particularly advantageous because it allows for the automatic generation of vulnerability chains for a target environment based solely on the description of its components and a unified vulnerability database. Therefore, there is absolutely no need for complex formalization of the environment or the attacks: simply describing the elements that compose it is sufficient.

[0020] According to various embodiments, the invention may have one or more of the following characteristics: Operation c. includes initializing as many pairs as there are vulnerabilities in the vulnerability list; operation c.2. includes determining a similarity value between a consequence from the list of consequences of the current vulnerability and a means from the list of means of the given vulnerability, and determining that this similarity value is strictly greater than a chosen threshold. the chosen threshold is zero, which when the consequence of the consequence list of the current vulnerability is identical to the means list of the given vulnerability, the similarity value is 1, the target environment data further include software element configuration data and software element relationship data, in which the tuple defining a vulnerability further includes a context data list defining the software context in which the vulnerability can be executed, the process further includes d. Comparing the context data lists of the vulnerabilities of each vulnerability chain in the vulnerability chain list with the configuration data and / or software element relationship data, and d.1.d.1. Store in a first list the vulnerability chains whose vulnerabilities include lists of context data that are all contained in the configuration data and / or the relationship data between software elements, and d.2. Store in a second list the vulnerability chains of which only some of the vulnerabilities include lists of context data contained in the configuration data and / or the relationship data between software elements, and the method further includes: e. Obtain exploits corresponding to the vulnerabilities in the vulnerability chains of the first and second lists, implement the exploit chains of the first and second lists with these exploits, and return the chains, classifying them according to their membership in the first or second list and according to the success rate of their implementation.

[0021] The invention also relates to a computer program comprising instructions for executing the method according to the invention, a data storage medium on which this computer program is recorded, and a computer system comprising a processor coupled to a memory on which this computer program is recorded.

[0022] Other features and advantages of the invention will become clearer upon reading the following description, drawn from illustrative and non-limiting examples taken from the drawings shown: [ Fig. 1 ] There figure 1 represents a generic diagram of a system according to the invention, [ Fig. 2 ] There figure 2 represents a generic diagram of the functions implemented by the system of the figure 1 , [ Fig. 3 ] There figure 3 represents an example of the implementation of a function of the figure 2 , [string generation], and [ Fig. 4 ] There figure 4 represents an example of the implementation of a function of the figure 3 , [recurring function].

[0023] The drawings and description below contain, for the most part, elements of a definite nature. They can therefore not only serve to better explain the present invention, but also contribute to its definition, if necessary.

[0024] This description contains material that may be protected by copyright. The rights holder has no objection to the reproduction of this patent document or its description, as it appears in official records, by anyone. Otherwise, the rights holder reserves all rights.

[0025] There figure 1 represents a generic diagram of a system according to the invention.

[0026] As can be seen in this figure, a system 2 according to the invention comprises a unifier 4, an extractor 6, a validator 8 and a tester 10 of a target environment 12.

[0027] In the example described here, the unifier 4 accesses a plurality of vulnerability description sources 14 to produce a vulnerability database 16. Alternatively, the vulnerability database 16 could be provided directly, and the unifier 4 could be omitted.

[0028] The unifier 4 can use a classical or deep learning classification technique, a set of regular expressions, or a set of rules to extract vulnerability attributes. To do this, it takes as input the description of a vulnerability transformed into a sequence of n tokens {t1, t2, ..., tn} to produce a set {(ti, tj, ek)} such that, for each element of this named entity list, i, chosen as an integer in the range [1..n], is the index of the first token of the named entity, j, chosen as an integer in the range [1..n], is the index of the last token of the named entity, and ek is a named entity from the list of attributes mentioned above.

[0029] The annotation of tokens to associate the tokens with their named entity classes can be done manually or by a recurrent neural network of the type LSTM (Long Short-Term Memory), GRU (Gated Recurrent Unit) or CNN (Convolutional Neural Network), or by a statistical model of the type CRF (Conditional Random Field) or an HMM (Hidden Markov model), or a combination of these techniques.

[0030] One non-limiting example of this implementation uses a recurrent neural network (RNN) that takes as input the tokens of the vulnerability's textual description and then associates each token with a numerical representation in the form of a word embedding vector. These vectors are used by the neural network to compute the semantic contexts of each token within the token sequence. Finally, a tag is associated with each token. This tag represents both its named entity and its position within that entity, with tag B indicating the beginning of the named entity, tag I an intermediate position within the named entity, and tag E the final position of the token within the named entity.

[0031] The annotations can be supplemented by measures that establish correspondences between vulnerability consequences. This dataset can be built by a normalization module, manually by an operator, or automatically by a computer program using a machine learning method, a set of regular expressions, or a set of rules. The normalization module is an operational unit that takes as input the sequences of means and consequences extracted from vulnerability descriptions and produces as output normalized and semantically equivalent sequences.

[0032] For example, the following sequences are normalized to the sequence {code, execution}: remote code execution RCE execute arbitrary code command execution run arbitrary code.

[0033] One example of how this non-exhaustive module can be implemented uses a recurrent neural network of the encoder-decoder type based on LSTM or GRU cells. To build a sufficiently large corpus of input sequences to feed the encoder of this neural network and improve its predictions, the following operations can be applied to the encoder's input sequences: Synonym replacement: replace a random word chosen from a sequence with a synonym, Word permutation of the sequence: generate permutations of words from a sequence, Word deletion: randomly choose a word and delete it from the sequence.

[0034] The encoder block allows encoding a provided input sequence {execute, arbitrary, code} into a hidden state. This hidden state is used by the decoder to predict a token sequence semantically equivalent to the provided input sequence.

[0035] Equivalences are used to associate different formulations of the same cause or consequence, or between causes and consequences. Equivalences can be direct or indirect, and thus depend on the context in which they are expressed. Weights or similarity indicators are then associated with these equivalences according to their degree of reliability.

[0036] For example, the causes improper input despecialization, improper input verification, and improper input validation are equivalent, with a very high similarity and therefore a weight of 0.9. However, the similarity between the consequences write application data and code injection is lower, and therefore only has a value of 0.7. It goes without saying that these values ​​are given for purely indicative purposes.

[0037] This set also contains a collection of pre-established causal links, created either manually by an operator or through automated processing, allowing for the inference of causes or consequences when these are absent or too abstract in the textual description of the vulnerability. These links translate into the statement of properties that enrich those discovered on the target system, but to which a lower probability will be assigned.

[0038] For example, if a vulnerability results in the execution of arbitrary code (code execution), the causes code injection or write file are implied, and therefore stated with a probability of 0.7.

[0039] Alternatively, unifier 4 can access one or more vulnerability databases according to one or more chosen ontologies.

[0040] Extractor 6 receives software environment data 18 as input and accesses the vulnerability database 16 to produce as output a list of vulnerability chains 20.

[0041] Software environment data includes a list of software configurations (publisher, name, version, etc.) present on a target environment. This list can be specified manually by an operator, by a mapping tool, or by an IT asset inventory / management tool. This information enriches the context of a vulnerability and validates the exploitability of an intrusion chain on the target environment.

[0042] This list of vulnerability chains 20 is provided along with the software environment data 18 to the validator 8. The validator 8's function is to explore the identified vulnerability chains given the considered software environment. As output, the validator 8 issues a list of fully validated chains 22 and a list of partially validated chains 24.

[0043] Finally, the list of fully validated chains 22 and the list of partially validated chains 24 are provided to tester 10, who accesses an exploit database to implement the chains from these lists. In return, tester 10 returns a success indicator for each tested vulnerability chain.

[0044] In the context of this invention, all data is stored on a memory device, which can be any type of data storage suitable for receiving digital data: hard drive, flash memory hard drive, flash memory of any kind, RAM, magnetic disk, locally distributed or cloud-based storage, etc. The data processed by the device can be stored on any type of memory similar to memory 4, or on memory itself. This data can be erased or retained after the device has completed its tasks.

[0045] Similarly, the unifier 6, the analyzer 8, and the tester 10 are elements that access the data directly or indirectly. They can be implemented as suitable computer code running on one or more processors. By processors, we mean any processor suitable for the calculations described below. Such a processor can be implemented in any known way, such as a personal computer microprocessor, a dedicated chip like an FPGA or SoC, a computing resource on a grid or in the cloud, a microcontroller, or any other form capable of providing the computing power necessary for the implementation described below. One or more of these elements can also be implemented as specialized electronic circuits such as an ASIC. A combination of processor and electronic circuits can also be considered.

[0046] It will also become apparent that the unifier 6, the analyzer 8 and the tester 10 are presented separately in order to better explain the functions implemented by the system 2. Alternatively, they can be combined into a single unit, be divided into subunits, partially grouped together, etc., provided that all the functions described below are performed.

[0047] There figure 2 represents an example of the functions implemented by the system of the figure 1 .

[0048] In the first operation 200, system 2 executes a function Inp() into which the software environment data 18 is entered. The Inp() function can, for example, rely on a user interface through which the location of a file containing the software environment data is specified. Alternatively, this data could be entered manually, or partially determined automatically.

[0049] Next, in operation 210, a function ListVul() receives the software environment data 18 as arguments and queries the vulnerability database 16. In return, the function ListVul() returns an LVul list which contains all the vulnerabilities likely to affect one or more of the elements of the target environment described by the software environment data 18. At this stage, no study of the software context is done, it is only a matter of retrieving all the vulnerabilities that could possibly apply.

[0050] The LVul vulnerability list is then provided as an argument to a ChVul() function in a 220 operation by parser 6. As will appear with the figures 3 And 4 The ChVul() function is a recurring function and an example of its implementation will now be described.

[0051] The ChVul() function contains a loop that calls a recurring function by varying its starting point.

[0052] Thus, in a 300 operation, a local list LVul2 is initialized with the LVul list, and the vulnerability chain list LChVul is initialized to empty. Then, a loop progressively empties the LVul2 list in a 310 operation to define an initial vulnerability Vc, and finally, a recurring function Gen() is executed in a 320 operation. This function will be explained with reference to the figure 4 .

[0053] When the LVul2 list is empty, it means that all vulnerability chains starting from a vulnerability in the LVul list have been explored and the ChVul() function ends in a 399 operation.

[0054] There figure 4 This represents an example of implementing the Gen() function. This function is recurrent in nature and its role is to iterate through the list of LVul vulnerabilities, starting from a current vulnerability, to see if this current vulnerability can be linked to another vulnerability to generate a link in a vulnerability chain. As we will see, the recurrent nature of the Gen() function allows us to build a chain of vulnerabilities step by step from an initial vulnerability.

[0055] The Gen() function receives as arguments the list of LVul vulnerabilities, the list of LChVul vulnerability chains and the current vulnerability Vc.

[0056] The Gen() function starts with a 400 operation in which the LVul vulnerability list is copied into an LVul2 list to traverse the list of vulnerabilities other than the current vulnerability.

[0057] Next, in operation 410, the LVul2 list is extracted to define a vulnerability to be tested, Vt. This vulnerability to be tested, Vt, is then tested twice in operations 420 and 430. Because of the recursive nature of the function, it is important to avoid loops. For this reason, operation 420 checks if the vulnerability to be tested, Vt, is identical to the current vulnerability, Vc, which would inevitably lead to a loop. Similarly, operation 430 checks if the vulnerability to be tested, Vt, is already present in the vulnerability chain associated with the current vulnerability, Vc, in the LChVul vulnerability chain list. This would also lead to a loop.

[0058] If one of these tests is positive, then the vulnerability to be tested Vt is ignored and the LVul2 list is again unstuck with operation 410.

[0059] Alternatively, a Sim() function receives as arguments the current vulnerability Vc and the vulnerability to be tested Vt in a 440 operation and determines whether the current vulnerability Vc can be exploited to implement the vulnerability to be tested Vt.

[0060] In practice, this is done by comparing the consequences of the vulnerability Vc and the means of the vulnerability to be tested Vt. If one of the consequences of the current vulnerability Vc is identical to a means of the vulnerability to be tested Vt, then the Sim() function returns a tuple sim which contains the vulnerability to be tested Vt, a similarity identifier indicating the identity link between the consequence(s) of the current vulnerability Vc that are identical to the means(s) of the vulnerability to be tested Vt, as well as this consequence(s).

[0061] If no consequence of the current vulnerability Vc is identical to a means of the vulnerability under test Vt, then the Sim() function tests whether one or more consequences of the current vulnerability Vc are similar to a means of the vulnerability under test Vt as described above. If so, the Sim() function returns a tuple `sim` containing the vulnerability under test Vt, a similarity identifier indicating the similarity relationship (e.g., the similarity score) between the consequence(s) of the current vulnerability Vc similar to the means(s) of the vulnerability under test Vt, and the consequence(s) themselves.

[0062] Otherwise, the returned sim tuple is empty. Operation 440 finally includes testing the sim tuple. If the sim tuple is empty, then the vulnerability being tested (Vt) is ignored, and the LVul2 list is unstuck again with operation 410.

[0063] Otherwise, the vulnerability to be tested, Vt, is considered to be part of a vulnerability chain for the current vulnerability, Vc, and the tuple `sim` is introduced into the vulnerability chain of the vulnerability chain list associated with the current vulnerability, Vc. Finally, in a 460 operation, the `Gen()` function is called recursively, with the vulnerability list LVul, the vulnerability chain list LChVul thus modified, and the vulnerability to be tested, Vt, as the current vulnerability, Vc.

[0064] When all vulnerabilities in the LVul2 list have been processed, the Gen() function terminates with a 499 error. At the end of the last instance of the Gen() function, the LChVul vulnerability chain list constitutes vulnerability chain list 20 of the figure 1 .

[0065] Once operation 220 is complete, the vulnerability chain list 20 generated by analyzer 6 is tested with software environment data 18 by validator 8 which executes a Val() function in operation 230.

[0066] The Val() function iterates through the list of generated strings to determine the validity of the vulnerabilities composing these strings in the target environment 12. A vulnerability is valid if all the characteristics of its context are included in the software configuration defined by the software environment data 18.

[0067] Following this process, three types of strings are identified for the target environment 12: invalid strings, valid strings stored in an LFull list 22 and partially valid strings stored in an LPart list 24.

[0068] A string `ch` is valid if: ∀ vul ∈ ch, CONTEXTE ( vul ) ⊂ C,where vul is a vulnerability in the ch chain, C is the software configuration of the target environment 12, and CONTEXT(vul) is the set of characteristics of the vulnerability context vul. A chain is invalid if: ∀ vul ∈ ch, CONTEXTE ( vul ) ⊄ C. A string is partially valid if: ∃ vul ∈ ch, CONTEXTE ( vul ) ⊂ C.

[0069] This function therefore makes it possible to determine, among all the chains of vulnerabilities potentially applicable to the target environment 12, those which are potentially exploitable given the specific software context.

[0070] Once the LFull and LPart lists are determined, they are tested in practice in order to define exploit chains in an operation 240. For this, the tester 10 accesses the exploit base 26 and executes a Test() function to return the exploit list LExp.

[0071] Each valid chain, determined in the previous operation, is exploited on the target environment 12 by successively exploiting the vulnerabilities that compose it.

[0072] This phase of exploiting a vulnerability in a valid chain is carried out by computer code developed by an operator, or publicly available or automatically generated by a computer program.

[0073] Upon execution of a valid chain of attacks on the target environment 12, the result of this attack is the consequence of the last exploited vulnerability. Depending on the final exploit targeted, the operator may exploit the chain in its entirety or only partially.

[0074] The partially valid strings, determined in the previous operation, can enable an operator or computer program to calculate the risk when installing software that reduces the invalidity of the string in a target environment 12. This allows an operator to verify that no invalid string will become valid on the target environment 12, following the introduction of a vulnerability by modifying the configuration of that environment.

[0075] The LExp list can store four types of strings as output: Valid and exploitable attack chains, meaning all vulnerabilities associated with these chains match the software context of the target environment and are exploitable within that environment. These are attack chains with a 100% success rate. Valid but partially exploitable chains, meaning all vulnerabilities associated with these chains match the software context of the target environment, but some vulnerabilities are not exploitable; that is, for these, the execution of the exploit fails. The success rate of a chain is proportional to the number of exploitable vulnerabilities. Partially valid and exploitable chains, meaning the vulnerabilities that match the software context of the target environment are exploitable within that environment.The success rate of each chain is proportional to the number of valid vulnerabilities; and partially valid and partially exploitable chains, i.e., some vulnerabilities that are valid in a chain are not exploitable. The success rate of a chain is the product of the ratios of valid vulnerabilities to exploitable vulnerabilities. For example, if a chain has five vulnerabilities, two of which are valid and only one of those two valid vulnerabilities is exploitable, then its success rate is: 2 / 5 * 1 / 2, which corresponds to a success rate of 20%.

[0076] The invention therefore makes it possible to build attack chains, wholly or partially exploitable in a target environment, which makes it possible both to validate known and observable vulnerabilities on the target environment, and also to more effectively assess the risk of an attack when updating the software configuration of the target environment.

[0077] This also makes vulnerability management in a target environment more efficient, by more precisely prioritizing vulnerabilities to be patched ("patching" in English) present in several chains or those that reduce attack chains, especially the first vulnerability to exploit in a chain.

Claims

1. A computer-implemented method for testing the cybersecurity of a target environment, including: a Receiving target environment data including software elements, b Accessing a vulnerability database, wherein each vulnerability is defined by a tuple that associates a vulnerability identifier, a list of means that defines the means used to exploit the vulnerability, and a list of consequences that defines the consequences of an exploiting of the vulnerability, and extracting therefrom a list of vulnerabilities that includes all vulnerabilities including a vulnerability identifier associated with a software element included in the target environment data, c Constructing a list of vulnerability chains based on the list of vulnerabilities by initialising at least one couple that includes an empty list as the current list and one of the vulnerabilities in the list of vulnerabilities as the current vulnerability and, for each couple, executing the following operations c.1 For each given vulnerability in the vulnerability list that is distinct from the current vulnerability and absent in the tuples of the current list, comparing the consequences of the current vulnerability with the means of the given vulnerability, and, c.2 Each time a similarity is found between a consequence in the list of consequences for the current vulnerability and a means in the list of means for the given vulnerability, c.2.i. Defining one or more new chains by adding, to each of the chains in the current list whose last tuple includes the current vulnerability, a tuple that associates the given vulnerability, a similarity identifier, the consequence in the list of consequences for the current vulnerability, and the means in the list of means for the given vulnerability, c.2.ii. Adding the one or more new chains to the list of vulnerability chains, c.2.iii. Repeating the operations c.

1. and c.

2. with the given vulnerability as the current vulnerability and the list of vulnerability chains as the current list.

2. A method according to claim 1, wherein the operation c. includes initialising as many couples as there are vulnerabilities in the vulnerability list.

3. A method according to claim 1 or 2, wherein the operation c.

2. includes determining a similarity value between a consequence in the list of consequences for the current vulnerability and a means in the list of means for the given vulnerability, and determining whether this similarity value is strictly greater than a selected threshold.

4. A method according to claim 3, wherein the selected threshold is zero.

5. A method according to claim 3 or 4, wherein when the consequence in the list of consequences for the current vulnerability is identical to the means in the list of means for the given vulnerability, the similarity value is 1.

6. A method according to one of the preceding claims, wherein the target environment data further include software-element configuration data and software-element interrelationship data, wherein the tuple that defines a vulnerability further includes a list of context data that define the software context in which the vulnerability can be executed, wherein the method further includes d Comparing the lists of vulnerability context data of each vulnerability chain in the list of vulnerability chains with the configuration data and / or the software-element interrelationship data, and d.1 Storing, in a first list, the vulnerability chains whose vulnerabilities include lists of context data that are entirely contained in the configuration data and / or the software-element interrelationship data, and d.2 Storing, in a second list, the vulnerability chains for which only some of the vulnerabilities include lists of context data contained in the configuration data and / or the software-element interrelationship data.

7. A method according to claim 6, further including: e. Obtaining exploits corresponding to the vulnerabilities of the vulnerability chains in the first list and in the second list, implementing the vulnerability chains in the first list and in the second list with these exploits, and returning the chains by classifying them according to whether they belong to the first list or the second list and according to the success rate of their implementation.

8. A computer program including instructions for executing the method according to one of claims 1 to 7 when it is executed on a computer.

9. A data storage medium on which the computer program according to claim 8 is stored.

10. A computer system including a processor coupled to a memory on which the computer program of claim 8 is stored.