Sébastien Salva
email: sebastien.salva@uca.fr

Loukmen Regainia
email: loukmen.regainia@uca.fr

Using data integration to help design more secure applications

Keywords: Security patterns, Classification, Attack, Attack Defence Tree

Security patterns are reusable solutions, which enable the design of maintainable systems or applications that have to meet security requirements. The generic nature of security patterns and their growing number make their choices difficult, even for experts in software design. We propose to contribute in this issue by presenting a methodology of security pattern classification based upon data integration. The classification exhibits relationships among 215 software attacks, 66 security principles and 26 security patterns. It expresses pattern combinations, which are countermeasures to a given attack. This classification is semiautomatically inferred by means of a data-store integrating disparate publicly available security data. Besides pattern classification, we show that the data-store can be used to generate Attack Defence Trees. In our context, these illustrate, for a given attack, its sub-attacks, steps, techniques and the related defences given under the form of security pattern combinations. Such trees make the pattern classification more readable even for beginners in security patterns.

Introduction

In the domain of software security, many documents (knowledge bases, papers, etc.) are now publicly available to help developers design and code more secure applications. For instance, the notion of security patterns, which is one of the topics of this paper, aims at providing guidelines to help in design secure systems [START_REF] Yoder | Architectural patterns for enabling application security[END_REF]. Schumacher postulates that a security pattern intuitively relates countermeasures to threats and attacks in a given context [START_REF] Schumacher | Security Engineering with Patterns: Origins, Theoretical Models, and New Applications[END_REF]. As developers cannot be expert in all security fields, this plethora of (often complex) documents exposes them to the difficult choice of the most suitable security solutions for a given context. From these resources, several works recently proposed to organise them in order to help developers in their understanding and usage. Security patterns were arranged into different categories, e.g., by security principles [START_REF] Yskout | Do security patterns really help designers?[END_REF][START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF], by application domains [START_REF] Bunke | Organizing security patterns related to security and pattern recognition requirements[END_REF] (software, network, user, etc.), by vulnerabilities [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF] or by attacks [START_REF] Wiesauer | A security design pattern taxonomy based on attack patterns[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF].

Despite the benefits brought by these classifications, they all are confronted to several limitations, which prevent their adoptions in the industry. Firstly, these classifications were manually devised, by directly comparing textual descriptions of different security concepts (patterns, principles, vulnerabilities, attacks, etc.). As these descriptions are generic and have miscellaneous abstraction levels, the categorisation of a pattern can be performed only when there is an evident relation between it and another security property. In addition, as these classifications are not deterministic (no strict definition of the classification process [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]), it often becomes delicate to upgrade them. Yskout et al. also reported that the security pattern adoption is limited possibly due to a sub-optimal quality of the documentation [19]. We indeed believe that many security pattern classifications lack of Navigability and Comprehensibility, which are quality criteria, proposed in [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF] and respectively related to: the ability to direct a software designer among collaborative and related patterns; the ease to understand patterns by both a novice and expert developer.

From these observations, we propose to contribute to the security pattern classification by proposing a strict and precise classification process based on the concept of data integration. To make this classification navigable and comprehensible, we propose to automatically infer attack-defence trees (ADTrees [START_REF] Kordy | Attack-defense trees[END_REF]), which illustrate the security pattern combinations that can be used to prevent an attack on an application. More precisely, the contributions of this paper can be summarised by the following points:

we propose a data integration methodology, built on six steps. These extract data from various Web and publicly accessible sources and store them into a data-store composed of relationships among attacks, attack steps, security principles and security patterns; we automatically derive a security pattern classification from the data-store, which can be updated after every data modification. For an attack, the classification expresses the security pattern combinations that can be used in the software design stage to later prevent the attack from being successfully carried out on the application; we generate Attack-Defence Trees (ADTrees [START_REF] Kordy | Attack-defense trees[END_REF]), which aim at supplementing the classification with illustrations depicting, for a given attack, its (more concrete) sub-attacks, steps and techniques along with defences preventing the attacks expressed here with security patterns combined with logic operations. Such ADTrees aim at improving the navigability and understanding of the previous classification.

We have generated a data-store and a security pattern classification specialised to the Web application domain, which is composed of 215 attacks, 26 security patterns and 66 security principles covering various security aspects. This classification and the ADTree generator are available here 3 .

The remainder of the paper is organised as follows: Section 2 presents some related work and the motivations of our approach. The method, which aims at

Related work

Several classifications were proposed to ease the pattern choice in the catalogues available in the literature, e.g., [START_REF]Security pattern catalog[END_REF], [19], totalling around 180 patterns. The classifications proposed in [START_REF] Wiesauer | A security design pattern taxonomy based on attack patterns[END_REF][START_REF] Tøndel | Combining misuse cases with attack trees and security activity models[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF][START_REF] Uzunov | An extensible pattern-based library and taxonomy of security threats for distributed systems[END_REF] focus on the attacker side. This choice of categorisation seems quite interesting and meaningful as attacks are more and more known and examined by designers. Wiesauer et al. initially presented a short taxonomy of security design patterns manually made from links between attack textual descriptions and security pattern purposes [START_REF] Wiesauer | A security design pattern taxonomy based on attack patterns[END_REF]. Tondel et al. presented in [START_REF] Tøndel | Combining misuse cases with attack trees and security activity models[END_REF] the combination of three formalisms of security modelling (misuse cases, attack trees and security activity graphs) in order to give a more complete security modelling approach. In particular, they link some activities of attack trees with attacks; they also connect some activities of SAGs (security activity graphs) with security patterns. The relationships among security activities and security patterns are manually extracted from documentation and are not explained. Alvi et al. presented a classification scheme for security patterns putting together attacks and security patterns [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. They analysed some security pattern templates available in the literature and proposed a new text section for completing the CAPEC classification [START_REF]Common attack pattern enumeration and classification[END_REF]. After inspection, we observed that this section is seldom available, which limits its interest. Finally, Uzunov et al. proposed a taxonomy of security threats and patterns specialised for distributed systems [START_REF] Uzunov | An extensible pattern-based library and taxonomy of security threats for distributed systems[END_REF]. This classification includes a library of threats and their relationships with security patterns. Some papers reviewed these classifications and established a comparative study to point out their positive and negative aspects. Alvi et al. outlined 24 pattern classifications, including security pattern classifications, and established a comparative study to point out their positive and negative aspects [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. They chose 29 classification attributes (purpose, abstraction levels, life-cycle, etc.) and compared the classifications against a set of desirable quality criteria (Navigability, Comprehensibility, Usefulness, etc.). They observed that several classifications were built in reference to a unique classification attribute, which appears to be insufficient. They indeed concluded that the use of multiple attributes enables the pattern selection in a faster and more accurate manner. Bunke et al. presented a systematic literature review of the papers dealing with security patterns between 1997 and 2012. In addition, they listed a set of classification criteria and compared design pattern and security pattern classifications [START_REF] Bunke | Organizing security patterns related to security and pattern recognition requirements[END_REF]. They finally proposed a classification based upon the application domains of patterns (software, network, user, etc.).

We observed that the main problem of the above classifications lies in the fact that these all are manually conceived by directly finding relations in tex-tual documents. Justifying these classifications or updating them is difficult. We also observed that they often lack of either Navigability or Comprehensibility or both. Relations among patterns are often not given, yet we noticed that some patterns are compatible together and that others are conflicting. As a consequence, a designer may be still confused about the pattern choice. As in [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF], we propose a pattern classification expressing which patterns can be used to counter an attack step. Our classification proposes a more precise and accurate mapping between patterns and attacks. It is more accurate in the sense that we translate the meaning of the patterns and attacks into smaller properties. We establish relations among these properties with respect to security principles, which identify the meaning of these relations. In addition, the classification is completed with inter-pattern relationships. Our data integration process also offers the advantage to justify the pattern classification and reduces the efforts required to update it. Finally, the generation of ADTrees makes the classification precise and readable even for novice in patterns or security.

Data integration

We present below the architecture of the data-store we devised and an example of data integration for attacks and security patterns related to the Web application domain. Beforehand, we recall some basic fact about security patterns.

Security patterns

Security patterns provide guidelines for secure system design and evaluation [START_REF] Yoder | Architectural patterns for enabling application security[END_REF]. They often are presented textually or with schema (UML diagrams) and are characterised by a set of structural and behavioural properties.

Several security pattern catalogues are available on the Internet and literature, e.g., [START_REF]Security pattern catalog[END_REF]19], themselves extracted from other papers. The quality of a pattern and its classification can be established by means of its strong points, which are properties expressing pattern key design features. Besides, a security pattern may have different relationships with other patterns. These new properties may noticeably help combine patterns and not to devise unsound composite patterns. Yskout et al. proposed a listing of pattern relations with the following annotations [START_REF] Yskout | Do security patterns really help designers?[END_REF]: "depend", "benefit", "impair" (the functioning of the pattern can be obstructed by the implementation of a second one), "alternative", "conflict".

Application Firewall is a security pattern example whose primary objective is to filter out undesired messages given or produced by an application, by means of access control policies. Figure 1 depicts the UML class diagram of this security pattern. This schema shows that it forces to structure an application in such a way that the filtering logic is centralised and decoupled from the functional logic of the application. This also corresponds to a strong point of the pattern.

Data-store architecture presentation

The classification purpose is to ease the design of more secure applications. To do so, we propose to arrange security patterns in such a way that the resulting classification provides the set of patterns that can be used as countermeasures against a given attack (in reference to the security pattern definition of Schumacher [START_REF] Schumacher | Security Engineering with Patterns: Origins, Theoretical Models, and New Applications[END_REF]) and relations among patterns.

To infer a precise classification, we chose to anatomize attacks and security patterns into more detailed properties that can be interconnected in an explicit manner. After reviewing the literature and some attack bases, we observed that attacks are documented with more concrete attacks, which can be themselves segmented into steps; These steps can be performed with techniques and can be prevented with countermeasures. We did not found smaller properties in the literature. On the other hand, security patterns can be characterised with some sub-properties, e.g., forces, consequences or strong points. A strong point is a pattern key feature that is extractable from its forces or consequences.

In both sides, countermeasures and strong points refer to the notion of attack prevention. But directly finding relations among them is still an obscure task as these properties have different purposes and abstraction levels. To solve this issue, we propose the option of gathering countermeasures into clusters (groups) to reach roughly the same abstraction level as strong points. Indeed, countermeasures are often much more detailed. Then, to link clusters and strong points, we chose to focus on security principles as mediators. We indeed observed that security patterns and strong points are classifiable w.r.t. security principles like most of the security techniques. Since countermeasures aim at preventing attack steps, it sounds natural that countermeasure clusters and strong points belong at least to one principle.

All the security properties considered here and their relations are structured with the meta-model illustrated in Figure 2 as explained before. The entities refer to security properties, the relations formally express associations among them. This meta-model finally structures our data-store.

Data integration and consolidation steps

We present, in this section, the different steps for integrating security properties into the data-store. The data integration is divided into six steps, which aim at collecting security properties and establishing the different relations presented in Figure 2. Steps 1 to 5 give birth to databases, and Step 6 consolidates them so that every entity of the meta-model is related to the other ones as expected. These steps offer the strong advantage to semi-automatically achieve a datastore, which can be updated.

We implemented these steps mostly by means of Talend, 4 an ELT (Extraction, Load, Transform) tool that allows an automated processing of data independently from the type of its source or destination. We applied these steps on attacks, patterns and principles related to the Web application context. We provide some quantitative results related to this context with each step. But, these can also be applied to other kinds of systems as long as documentation is available. We integrate data coming from different sources: the CAPEC base [START_REF]Common attack pattern enumeration and classification[END_REF], several papers dealing with security principles [START_REF] Saltzer | The protection of information in computer systems[END_REF][START_REF] Viega | Building Secure Software: How to Avoid Security Problems the Right Way, Portable Documents[END_REF][START_REF] Meier | Web application security engineering[END_REF] and the pattern catalogue given in [19].

Step 1: Extraction of attacks, steps, techniques and countermeasures We chose to focus on the CAPEC base to extract information about security attacks. The Common Attack Pattern Enumeration and Classification (CAPEC) is an open database offering a catalogue of attacks in a comprehensive schema.

Attack patterns are descriptions of common approaches that attackers take to attack software or systems. An attack pattern, which we refer here as documentation (to avoid the confusion with security pattern), consists of several textual sections. For instance, the section "Related attack patterns" shows interdependence among attacks, having different levels of abstractions.

We extracted attacks of the CAPEC base and organised them into a single tree, which describes a hierarchy of attacks from the most abstract to the most concrete ones so that, we can get all the sub-attacks of a given attack. To reach that purpose, we rely on the relationships among attack descriptions found in the CAPEC section "Related Attack Patterns". By scrutinising all the CAPEC documents, it becomes possible to develop a hierarchical tree whose root node is unlabelled and connected to the attacks of the type "Category". These nodes may also be parent of attacks that belong to the type "Meta Attack pattern" and so on. The leaves are the most concrete attacks of the type "Detailed attack pattern". Then, for every attack, we collected from the CAPEC base (section "Attack Execution Flow") its steps, which may be composed of more concrete sub-steps, and for each step, the corresponding techniques and security controls, which correspond to countermeasures. This data extraction is automatically performed with a tool, which yields a database DB 1 . From the CAPEC base Version 2.8, we extracted these elements for the Web application context and collected 215 attacks, 209 steps, 448 techniques and 217 countermeasures, knowing that attacks can share steps, techniques, etc.

Step 2: Countermeasure hierarchical clustering The countermeasure number grows quickly while reading the attacks of the CAPEC base. Many of them have a close meaning though, which can be explained by the number of different contributors that added them. These countermeasures can be hence grouped into families to be later associated with a security principle.

We semi-automated this process by applying a hierarchical clustering technique of documents. We firstly used the tool KHcoder5 , which is a reputed tool performing quantitative content analysis or text mining. In short, we applied the tool as follows:

1. the Stanford (Part-of-speech) POS tagger is called to sort the keywords found in the countermeasure descriptions (log, input, credentials, etc.) by their frequencies and types (noun, verb, adverb, etc.); 2. from the frequencies, weights are computed and scaled with the Jaccard coefficient (the dissimilarity between sample sets) to measure a distance among countermeasures. The distance between two security controls is minimised when they have more common keywords.

Afterwards, we used the method Ward to automatically yield a hierarchy of countermeasure clusters [START_REF] Willett | Recent trends in hierarchic document clustering: a critical review[END_REF]. We chose Ward because it offers the possibility to merge groups, piece by piece, instead of directly providing big clusters. In our case, this second solution would tend to build big clusters covering too much security aspects, which would be later associated with too much security principles. Finally, the level to consider in the cluster organisation (and implicitly the number of clusters to keep) is manually chosen, as the choice of the number of clusters is always supervised with Ward. To get a coherent clustering, we chose the most suitable level after some iterations by checking whether the countermeasures obtained in the clusters refer to the same security principle or set of principles.

The resulting clusters are stored into the database DB 2 . The 217 security controls collected by the previous step, are aggregated into 21 clusters.

Step 3: security patterns and strong points integration We manually collected security patterns and their strong points from the catalogue given in [19]. Strong points often have to be deduced in the sections referring to the forces and consequences of the patterns. Then, we manually established two relations among patterns and strong points:

1. the first one is a many-to-many relation between security patterns and strong points, each pattern being characterised by a set of strong points that can be shared with other patterns. For example, the patterns "Authorization enforcer" and "Container managed security" share the strong point "Providing the application with authorization mechanism; 2. the second relation is related to the annotations "depend", "benefit", "impair" or "alternative" defined among patterns [START_REF] Yskout | Do security patterns really help designers?[END_REF]. With P a set of patterns, this relation is defined as a mapping from P 2 to the annotation set {"depend", "benef it", "impair", "alternative"}, which provides for a pair of patterns (p1, p2) an annotation about the relationship between p1 and p2.

These data and relations, which provide connections among security patterns and between patterns and strong points, are encoded into the database DB 3 . For the domain of Web applications, we gathered 26 security patterns and 36 strong points.

Step 4: Security principle integration We chose to organise security principles into a hierarchy, from the most abstract to the most concrete principles. We collected 66 security principles related to Web applications found in [START_REF] Saltzer | The protection of information in computer systems[END_REF][START_REF] Viega | Building Secure Software: How to Avoid Security Problems the Right Way, Portable Documents[END_REF][START_REF] Meier | Web application security engineering[END_REF] and manually established dependencies in relation to the nature of each security principle, often described with text. The current hierarchy, which has four levels, is certainly not exhaustive. But it covers all the security patterns given in [19]. This security principle hierarchy is stored in the database DB 4 .

This principle organisation gives a complete hierarchical view on security mechanisms, which are in the meantime required to prevent an attack step and which are provided by strong points. As principles are hierarchically organised from the most abstract to the most concrete ones, we can find relations between strong points and countermeasure clusters even if they do not exactly have the same level of abstraction.

Step 5: mapping between strong points, security principles and countermeasure clusters In this step, we established the many-to-many relation between strong points and security principles. This step was manually done because strong points and principles are mostly presented in an abstract manner. During this step, we observed that the abstraction level of the strong points better fit with the most concrete principles, which are the leaves of our hierarchical organisation.

In the same way, we established the many-to-many relation between countermeasure clusters and security principles. In Step 3, clusters include countermeasures sharing the same security aspects, e.g., Input validation, Authentication or Authorisation. Once these aspects are deduced, linking clusters and security principles becomes straightforward.

These relations are materialised with the database DB 5 , which combines 21 clusters, 36 strong points and 66 principles.

Step 6: data consolidation This automatic step integrates the previous databases DB 1 to DB 5 into a single one. On the one hand, DB 1 , DB 2 and DB 5 store the relations among attacks, steps, countermeasures and principles. On the other hand, DB 3 and DB 5 store the relations among security patterns, strong points and principles. It is now manifest that the security principle hierarchy becomes the central point that helps map attacks onto security patterns.

This step is automatically performed by the tool Talend by means of the meta-model given in Figure 2. The step produces the final database DB f .

Security pattern classification and ADTree generation

Security pattern classification

The database DB f holds all the data and relations among attacks, steps, security principles and security patterns allowing to extract a security pattern classification. We have chosen to catalogue the combinations of patterns that are countermeasures against an attack. Given an attack Att, the following data and relations are hence extracted from DB f :

the information about Att (name, identifier, description); the tree T (Att), whose root is Att, if Att is not a leaf of the attack tree derived in Step 1. For every attack found in T (Att), we also extract its attack steps and techniques; for each step st, the complete hierarchy of security principles Sp(st) by means of the successive relations established among st, countermeasure clusters and security principles. Sp(st) represents the complete hierarchy of security principles related to a step, i.e., if a principle sp associated to the step st is not a leaf of our hierarchical organisation, then we also extract all the principle sub-tree whose root is sp;

for each principle sp in Sp(st), the set of security patterns P sp , the set of patterns P 2 sp not in P sp that have relations with any pattern of P sp , and the nature of these relations defined for couples of patterns by the annotations in {"depend", "benef it", "impair", "alternative", "conf lict"}. Figure 3 depicts an extraction example for the CAPEC attack 34 "HTTP Response Splitting". The first column gives the ID of the chosen attack. This attack belongs to the category "Detailed" of the CAPEC, therefore it has no sub attacks (otherwise, the next columns would list them too). Columns 2 to 4 index the attack steps and techniques. Due to lack of room, we only illustrate the step "Experiment" here. The security patterns allowing to prevent the step are given in Column 5. These four patterns have to be contextualised in the application model and implemented to prevent the attack. The last two columns add the security patterns being associated with the patterns of Column 5 and their relations. For instance, Figure 3 shows that "Application Firewall" and "Input guard" are alternative patterns, hence using one of them is enough (although using both is not incorrect).

The classification extraction is achieved once all the attacks stored in the database DB f are covered. This extraction is automatically performed with a tool based upon Talend. This tool can be re-executed every time the data-store is updated. The classification remains up-to-date accordingly.

At this stage, we think that Comprehensibility, which refers to the ability to use the classification by experts or novices, is not yet totally satisfied. Indeed, the classification is given under a tabular form only, which does not appear to be the most user-friendly way to represent a classification. This is why we also propose to generate ADTrees.

Attack-Defence Tree generation

Attack Defence Trees "are graphical representations of possible measures an attacker might take in order to attack a system and the defences that a defender can employ to protect the system" [START_REF] Kordy | Attack-defense trees[END_REF]. We recall that ADTrees have two different kinds of nodes: attack nodes (red circles) and defence nodes (green squares). A node can be refined with child nodes using conjunctive or disjunctive refinements. The former is recognisable by edges going from a node to its children. The latter is graphically distinguishable by connecting these edges with an arc. Here, we extend these two refinements with the sequential conjunctive refinement of attack nodes, defined by the same authors in [START_REF] Jhawar | Attack trees with sequential conjunction[END_REF]. This operator expresses the execution order of child attack nodes. Graphically, a sequential conjunctive refinement is depicted by connecting the edges going from a node to its children with an arrow.

Keeping in mind that we use ADTrees to help developers design more secure applications, we propose to generate them with the general form illustrated in Figure 4(a). This ADTree points out how an attack is sequenced with steps and how to prevent them with countermeasures given under the form of security pattern combinations. An ADTree root node is labelled by an attack. If the attack is linked to sub-attacks, the root node is also connected to child attack nodes expressing these sub-attacks. When an attack is defined with steps and techniques, its corresponding node has child nodes expressing them. A node labelled by an attack step has a child defence node, which is the root of a defence sub-tree expressing combinations of security patterns.

We automatically generate ADTrees from the data-store as follows:

1. every CAPEC attack found in DB f has its own ADTree whose root node is labelled by its identifier. This root node is linked to other attack nodes with a disjunctive refinement if the attack has sub-attacks. This step is repeated for every sub-attack; 2. for each attack Att of the preceding tree, we collect its sequence of steps.

The node labelled by Att is refined with a sequential conjunction of attack nodes, one for each step. We repeat this process if a step is itself composed of steps. In the same way, for each step St, the related techniques are extracted from the classification and are associated to the node labelled by St with a disjunctive refinement; The not operation is here replaced by an attack node meaning that two conflicting security patterns used together might constitute a kind of attack. The node "Potential attack" expresses a kind of negation. The corresponding sub-tree is depicted in Figure 4(b); p 1 having no relation with any pattern p 2 in P , we add one parent defence node labelled with p 1 . The parent defence nodes, resulting from the above steps, are combined to a defence node labelled by "Pattern Composition" with a conjunctive refinement. This last defence node is linked to the attack node labelled by St.

We implemented the ADTree generation with a tool, which takes as input an attack identifier and yields an ADTree, which is stored into an XML file. These files can be used with the editing tool given in [START_REF] Kordy | Adtool: security analysis with attack-defense trees[END_REF]. As a consequence, ADTrees can be modified or updated as the developer wishes.

Figure 5 illustrates the ADTree obtained from the attack CAPEC 34. The root of the tree is the main goal of the attacker. Its second and third levels relate to the attack steps. These nodes are sequential conjunctive refinements of the root node. For instance, the step Exploit is achieved if both steps 3.1 and 3.2 are successfully executed in the right order (from left to right). An attack step has a disjunctive refinement of attack nodes labelled by techniques. The step is achieved if one of the attack techniques is applied with success. Defence nodes (square nodes) illustrate security pattern combinations. For instance, the step "1.1 Spider" refers to the Web application exploration through Graphical user interfaces in order to get all the URLs of the application. This step can be prevented by designing the application with both patterns "Audit interceptor" and "Secure logger". "Audit interceptor" can be used to detect the application crawling and to warn an administrator. The audit logs are secured by means of "Secure logger", which guarantees that the audit logs cannot be accessed or altered by unauthorised users. This example illustrates that a designer can easily follow the concrete materialisations of an attack in an ADTree and can directly choose security patterns.

Classification discussion

Our security pattern classification associates attacks, security principles and security patterns in order to help developers in the choice of the most suitable pattern combinations to design and code secure applications. The current classification is founded on 215 CAPEC attacks, 26 security patterns and 66 principles related to the Web application context. It enables multi-attribute based decisions insofar as patterns can be selected according to the provided inter-pattern relations and/or according to the attack steps. -Navigability: our classification, accompanied by ADTrees, satisfies this criterion as it exhibits the hierarchical refinements of an attack and, for every attack step, the combinations of patterns, which should be integrated in the application model. In addition, the classification provides the relationships among security patterns, which help choose the most appropriate pattern combination; -Determinism: the classification is clearly defined by means of the method steps. All these steps justify the soundness of the classification; -Unambiguity/Comprehensibility: patterns are classified w.r.t. defined categories, i.e., attacks, steps, and security principles. This organisation, which is illustrated by means of ADTrees, makes our classification readable and comprehensible even for novices in security patterns; -Usefulness: we believe the classification can be used in practice since it is based upon a known security pattern catalogue [19] and upon the CAPEC base, which is more and more employed in the industry; -Repeatability: the classification is generic and can be reused. Furthermore, the data-store and the classification can be updated and generated semiautomatically.

Besides, a variety of statistical information can be automatically extracted from the data-store. For instance, Figure 6 depicts a pie chart, which shows the ratios of attacks that can be partially prevented per security pattern. These kinds of charts, which are automatically generated from the data-store, seem quite useful to guide designers towards security analysis, good practices and education. For instance, with the above chart, a designer can observe that 2 patterns seem to emerge for partly countering a large part of the 215 attacks covered by the classification, namely "Input Guard" and "Application firewall". It is manifest that if we complete the data-store with more data, e.g., patterns or attack risks, such charts could be more refined and adapted to the developer needs.

Our classification and data integration process present some limitations, which could lead to future works. Firstly, we did not consider the notion of attack combination. Such a combination could be seen as several attacks or as one particular attack. Furthermore, the classification is not yet exhaustive: it includes 215 attacks out of 569 (for any kind of application) and 26 security patterns out of around 180. We also do not take into consideration the ADTree size. This is a strong limitation since large trees are usually unreadable, which contradicts the classification purposes. The ADTree reduction could be a first solution on this problem. But, reducing such trees remains a hard problem as the node meaning must be taken into account in the node aggregating process.

Conclusion

We have proposed a security pattern classification method associating attacks, security principles and security patterns in order to help designers understand the inner workings of attacks and choose the most suitable pattern combinations to design secure applications. This method integrates data obtained from various sources and subdivides attacks and patterns into detailed properties, which are associated in accordance with security principles. The pattern classification is then automatically generated from the data-store. The data-store and the classification can be upgraded by following some steps only. We also proposed to portray this classification by means of ADTrees showing attack scenarios (steps, techniques, etc.) and countermeasures given as security pattern combinations.

In future research, we will firstly focus on the automation of some data integration steps. Indeed, it could be relevant to investigate whether some text mining techniques would help partially automate the extraction and integration of the security pattern properties without adding ambiguity. As our ADTrees exhibit concrete attack scenarios composed of sequences of steps, we also intend to use them for the test case generation to check whether an implementation is protected against the attacks given in an ADTree or if security patterns are correctly contextualised and implemented w.r.t. the application context.

Fig. 1 .

 1 Fig. 1. Security pattern "Application Firewall"

Fig. 2 .

 2 Fig. 2. The proposed mapping metamodel

Fig. 3 .

 3 Fig. 3. Data extraction for the attack CAPEC-34

Fig. 4 .

 4 Fig. 4.

Fig. 5 .

 5 Fig. 5. ADTree of the Attack CAPEC-34

Fig. 6 .

 6 Fig. 6. Percentage of fixed attacks per pattern

  3. for each step St, we extract the set P of security patterns that are countermeasures of St. Given a couple of patterns (p 1 , p 2 ) ∈ P , we illustrate these relations with new nodes and logic operations as follows. If we have: -(p 1 R p 2 ) with R a relation in {depend, benef it}, we build three defence nodes, one parent node labelled by p 1 R p 2 and two nodes labelled by p 1 , p 2 combined with this parent defence node by a conjunctive refinement;

https://talend.com/

http://khc.sourceforge.net/en/

Research supported by the industrial chair on Digital Confidence http://confiancenumerique.clermont-universite.fr/index-en.html


Loukmen Regainia
email: loukmen.regainia@udamail.fr

Sébastien Salva
email: sebastien.salva@udamail.fr

A methodology of security pattern classification and of Attack-Defense Tree generation

Keywords: Security patterns, Classification, CAPEC attacks, CWE weaknesses, Attack-Defense Trees

Security at the design stage of the software life cycle can be performed by means of security patterns, which are viable and reusable solutions to regular security problems. Their generic nature and growing number make their choice difficult though, even for experts in system design. To guide them through the appropriate choice of patterns, we present a methodology of security pattern classification and the classification itself, which exposes relationships among attacks, weaknesses and security patterns. Given an attack of the CAPEC (Common Attack Patterns Enumeration and Classification) database , the classification expresses the security pattern combinations that overcome the attack. The methodology, which generates the classification is composed of five steps, which decompose patterns and attacks into sets of more precise sub-properties that are associated. These steps provide the justifications of the classification and can be followed again to upgrade it. From the classification, we also generate Attack-Defense Trees (ADTtrees), which depict an attack, its sub-attacks and the related defenses in the form of security pattern combinations. Without loss of generality, this classification has been established for Web applications and covers 215 attacks, 136 software weaknesses and 26 security patterns.

INTRODUCTION

Design patterns are recurrent solutions to software design problems proposed and used by skilled application or system designers. They are more and more considered in the industry since they may accelerate the design stage of the software life cycle and help in the code readability and maintenance. As the interest in software security continuously grows for a few years, specialised patterns were also proposed to improve the security properties of models.

Security patterns are reusable (design) elements to design secure applications which will enable software architects and designers to produce a system which meets their security requirements and which is maintainable and extensible from the smallest to the largest systems [START_REF] Rodriguez | Security Design Patterns[END_REF].

Security patterns relates countermeasures (stated in the solution) to threats and attacks in a given context [START_REF] Schumacher | Security Engineering with Patterns[END_REF].

Hence, these patterns are often presented with UML (Unified Modelling Language) class and sequence diagrams.

Since 1997, the number of security patterns is continuously growing and around 170 security patterns are available at the moment [START_REF] Slavin | Security patterns repository[END_REF]. Security patterns are often presented with a high level of abstraction to be reusable in different kinds of context and are described with textual documents. Because of this abstract nature and because the documents are not structured in the same manner, the choice of the most appropriate security pattern to mitigate a security problem is sensitive and somehow perilous to novice designers [START_REF] Yskout | Does organizing security patterns focus architectural choices[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. As designers cannot be experts in all the fields of software engineering, they clearly lack of guidance in the choice of patterns during the design phase. As a consequence, security pattern taxonomies were proposed in the literature to lead them towards good practices.

Several classifications were proposed to arrange security patterns in different kinds of cate-gories, e.g., by security principles [START_REF] Yskout | A system of security patterns[END_REF][START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF], by application domains [START_REF] Bunke | Organizing security patterns related to security and pattern recognition requirements[END_REF] (software, network, user, etc.)., by vulnerabilities [START_REF] Anand | Vulnerability-Based Security Pattern Categorization in Search of Missing Patterns[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF] or by attacks [START_REF] Wiesauer | A security design pattern taxonomy based on attack patterns[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. Despite the improvements in the pattern choice brought by these classifications, several issues still remain open. Among them, we noticed that these classifications are all manually devised by directly comparing the textual descriptions of patterns with those of the other security artifacts (vulnerabilities, attacks, etc.). As these descriptions are generic and have different levels of abstraction, the categorisation of a pattern can be done only when there is an evident relation between it and a security property. Furthermore, it is often delicate to upgrade these classifications since no strict process to follow is available. Finally, the navigability among a set of patterns is rarely taken into consideration by theses classifications [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. This important quality criterion is defined as the ability to guide the choice of designers among collaborative and related patterns. We believe that this criterion must be examined and exposed in security pattern classifications since we often observed that several patterns may meet the same security property.

From these observations, we propose to contribute in the security pattern classification by proposing a classification methodology, composed of several successive steps, which lead to a pattern classification based upon security attacks, since the notion of attacks is usually well-known by designers and developers. More precisely, the contributions of this paper can be summarised by the following points:

• we propose a classification, which is based upon relationships among attacks, weaknesses, security principles and security patterns, expressing the pattern combinations that can be used to mitigate an attack. The classification is composed of security properties found in well established security bases i.e. the CAPEC (Mitre corporation, 2015a) and CWE (Mitre corporation, 2015b) bases.

The classification is stored in a database available in [START_REF] Regainia | Security pattern classification[END_REF]. For readability purposes and to illustrate the navigability among patterns, the classification is illustrated by means of Attack-Defence Trees (ADTrees [START_REF] Kordy | Attack-defense trees[END_REF]), which illustrate for a given attack its (more concrete) sub-attacks and the defenses, expressed here with security patterns combined with logic operations,

• our classification reveals the combinations of patterns that should be chosen to block an attack, and particularly it provides inter-pattern relations. We indeed take advantage of the studies about the inter-pattern relations [START_REF] Yskout | A system of security patterns[END_REF][START_REF] Fernandez | Classifying security patterns[END_REF] and include them in the classification. For instance, these inter-pattern relations offer the advantage to make apparent the conflicting or alternative patterns,

• we propose a methodology, built on five steps, which infer relationships between attacks, weaknesses, security principles and patterns to generate the classification and Attack Defence Trees. The methodology takes as inputs CAPEC attacks, builds a hierarchical tree of attacks showing the sub-attacks of a given attack and links them with the targeted weaknesses found in the CWE base. Afterwards, we reuse an earlier work, proposed in (Regainia et al., 2016a), to build relationships among weaknesses, security principles and security patterns. All these steps provide the detailed justifications of the resulting classification. As most of the steps are automatic, this methodology can be followed again to update the classification.

We have limited our classification to the field of Web applications, which means that our pattern classification includes 215 CAPEC attacks, 136 CWE weaknesses, and 26 security patterns covering varied security aspects.

The remainder of the paper is organised as follows: Section 2 presents some related work and the motivations of the proposed approach. Section 3 recalls some security notions used in the paper. We introduce the methodology in Section 4 and illustrate its steps with the attack "CAPEC-39: Manipulating Opaque Client-based Data Tokens". We give a short presentation of the classification and discuss about its advantages and limitations in Section 5. We traditionally conclude and give some perspectives for future work in Section 6.

RELATED WORK

Some taxonomies and classifications were proposed in the literature to help designers in the choice of the most appropriate security patterns with regard to a given context. Bunke et al. presented a systematic literature review of the papers dealing with security patterns between 1997 and 2012. They finally proposed a classification based upon the application domains of patterns (software, network, user, etc.) [START_REF] Bunke | Organizing security patterns related to security and pattern recognition requirements[END_REF], but the notions of attacks or vulnerabilities are not mentioned. Vulnerabilities are taken into consideration for pattern classification in [START_REF] Anand | Vulnerability-Based Security Pattern Categorization in Search of Missing Patterns[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. This gives another point of view helping designers in the choice of patterns to fix software vulnerabilities. This vulnerability based classification seems meaningful since vulnerabilities are the natural causes of attacks on software systems, but the vulnerability concept is not the most known by designers. This is why other authors proposed security pattern classifications, which refer to the attack concept [START_REF] Wiesauer | A security design pattern taxonomy based on attack patterns[END_REF][START_REF] Tøndel | Combining misuse cases with attack trees and security activity models[END_REF][START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF][START_REF] Uzunov | An extensible pattern-based library and taxonomy of security threats for distributed systems[END_REF]. Wiesauer et al. initially presented in (Wiesauer and Sametinger, 2009) a short taxonomy of security design patterns made from links found in the textual descriptions of attacks and the purposes and intents of security patterns. Tondel et al. presented in [START_REF] Tøndel | Combining misuse cases with attack trees and security activity models[END_REF] the combination of three formalisms of security modelling (misuse cases, attack trees and security activity models) in order to give a more complete security modelling approach. In their methodology of building attack trees, they linked some activities of attack trees with CAPEC attacks; they also connected some activities of SAGs (security activity diagrams) with security patterns. The relationships among security activities and security patterns are manually extracted from documentation and are not explained. Shortly after, Alvi et al. presented a natural classification scheme for security patterns putting together CAPEC attacks and security patterns for the implementation phase of the software life cycle [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. They analysed some security pattern templates available in the literature and proposed a new template composed of the essential elements needed for designers. They manually augmented the CAPEC attack documentation with a section named "Relevant security patterns" composed of some patterns [START_REF] Alvi | A Natural Classification Scheme for Software Security Patterns[END_REF]. After inspecting the CAPEC base, we observed that this section is seldom available, which limits its use and interest. Finally, Uzunov et al. proposed in (Uzunov and Fernandez, 2014) a taxonomy of security threats and patterns specialised for distributed systems. They proposed a library of threats and their relationships with security patterns in order to reduce the expertise level required for the design of secure applications [START_REF] Uzunov | An extensible pattern-based library and taxonomy of security threats for distributed systems[END_REF]. They considered that the use of the CAPEC base is cumbersome and assumed that their threat patterns are abstract enough to encompass security problems related to the specific context of distributed systems [START_REF] Uzunov | An extensible pattern-based library and taxonomy of security threats for distributed systems[END_REF].

Open issues and contributions

Alvi et al. outlined 24 of these classifications in [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF] and established a comparative study to point out their positive and negative aspects. They chose 29 classification attributes (purpose, abstraction levels, life-cycle, etc.) and compared the classifications against a set of desirable quality criteria (navigability, completeness, usefulness, etc.). They observed that several classifications were built in reference to a unique classification attribute, which appears to be insufficient. They indeed concluded that the use of multiple attributes enables the pattern selection in a faster and more accurate manner.

We also observed that the main issue of the above works lies in the lack of a precise methodology to build the classification. All of them are based upon the interpretation of different documents, which are converted to abstract relationships. The first consequence is that understanding the structure of categories and relationship is sometimes tricky. In addition, it becomes very difficult to extend these classifications.

Furthermore, we noticed that these classifications lack of navigability among patterns, which is an important property defined as the ability to guide the choice of designers among related patterns [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. We believe that a security pattern classification must be built from several security properties e.g., weaknesses, security principles, etc. to make the pattern choice more precise. The inter-pattern relationships should also be given: for instance, the conflicts among patterns, which may lead to inconsistencies in an application, must be noticeable.

In (Regainia et al., 2016a), we proposed a first semi-automatic methodology of classification and the classification itself, which exposes relationships among 185 software weaknesses of the CWE base (Mitre corporation, 2015b), security principles and 26 security patterns. It expresses which patterns partially mitigate a given weakness with respect to the security principles that have to be addressed to fix the weakness. This methodology is composed of some manual steps subdividing weaknesses and patterns into detailed security properties. Then, these are automatically associated together with respect to security principles. We organised the latter into a hierarchy to precisely express the security objectives of these properties.

In this paper, we continue the line of work previously initiated and present a methodology of classification to categorise the security patterns that can be used to mitigate attack patterns of the CAPEC base. Our classification aims at proposing a precise and accurate mapping between security patterns and CAPEC attacks: it is more accurate in the sense that we focus on the sub-properties of the security patterns and attacks and establish relations among these properties. In addition, the classification is completed with the inter-pattern relationships found in [START_REF] Yskout | A system of security patterns[END_REF]. This is why we claim that the proposed classification is more precise.

But, the strong contribution of this paper lies in the presentation of the methodology itself. This one is based on several automatic steps that can be followed again to complete the classification. We also propose the generation of Attack-Defense trees (ADTrees) putting CAPEC attacks as attack nodes and security patterns as defense nodes. These trees illustrate two points of view: they show the choice of an attacker (choice of attack, achieved with more concrete attacks) and the available mitigations that a designer can choose to devise its application. These are generated after the choice of an attack in the classification and are hence up-to-date w.r.t. the latter. Our ADTrees also express the relation among patterns (dependence, conflicts, etc.).

BACKGROUND

The proposed classification methodology is mainly based upon three security concepts: security patterns, CAPEC attacks and CWE weaknesses. We recall basics on these concepts below.

Security patterns

A security pattern is a generic solution to a recurrent security problem, which is characterised by a set of structural and behavioural properties [START_REF] Fernandez | Security patterns and secure systems design[END_REF]. It can be presented textually or with schema, e.g. UML diagrams. The quality of a pattern and its classification can be established with strong points, which correspond to sub-properties of the pattern. These properties characterize the forces and the consequences brought by the use of the pattern against a security problem [START_REF] Harb | Using an Ontology to Suggest Software Design Patterns Integration[END_REF]. Strong points are manually extracted from the forces and consequences of a security pattern.

In addition, a security pattern can be documented to express its relationships with other patterns. Such annotations may noticeably help combine patterns and not to devise unsound composite patterns. Yskout et al. proposed the following annotations between two patterns p 1 and p 2 [START_REF] Yskout | A system of security patterns[END_REF]:

• "depend"means that the implementation of p 1 requires the implementation of p 2 , • "benefit" expresses that implementing p 2 completes p 1 with extra security functionalities or decreases the development time. However, p 1 can be correctly implemented despite the absence of p 2 , • "impair" means that the functioning of p 1 can be obstructed by the implementation of p 2 , • "alternative" expresses that p 2 is a different pattern fulfilling the same functionality as p 1 , • "conflict" encodes the fact that if both p 1 and p 2 are implemented together then it shall result in inconsistencies. whose purpose is to filter requests and responses to and from an application, based on access control policies. This security pattern structures an application in such a way that the inputs filtering logic is centralised and decoupled from the functional logic of the application.

This pattern is related to two other security patterns [START_REF] Yskout | A system of security patterns[END_REF]: it is an alternative to the patterns "Input Guard" and "Output Guard" since the application firewall is able to filter input calls, and also output responses from the application.

CWE weaknesses

The CWE base (Mitre corporation, 2015b) provides an open catalogue of software weaknesses, which are software or design mistakes that can lead to vulnerabilities. At the moment, this database includes around 1000 software weaknesses but this number is still growing. A weakness is documented with a panoply of information, including a full description, its causes, detection methods, and relations with CAPEC attacks or vulnerabilities. In addition, a set of potential mitigations are often proposed.

Capec Attacks

The Common Attack Pattern Enumeration and Classification (CAPEC) is an open database offering a catalogue of attacks in a comprehensive schema (Mitre corporation, 2015a). Attack patterns are descriptions of common approaches that attackers take to attack software. An attack pattern, which we refer here as a document, consists of several sections; among them, a section describes the attack execution flow on vulnerable systems, other sections give the prerequisites, the severity, the impact, the required attacker skills, etc.

In our context, three sections sound particularly interesting for starting a classification: the section "Related attack patterns" shows some relationships among attacks, the section "Related Weaknesses" lists the CWE weaknesses targeted by the attack and the section "Relation security principles" catalogues some principles defined as desirable properties targeted by the attacks.

The attacks of the section "Related attack patterns", are characterised by a type and a relation. The former expresses a level of abstraction of the attacks. Different levels can be found, giving a hierarchical structure: We list them from the more to less abstract as follows: 1. Category: at this level, an attack pattern expresses the attack mechanisms/domains from a high point of view (Injection, Target analysis, Social engineering, etc.), 2. Meta pattern: as a refinement of Category, meta patterns express the possible specialisations of attack mechanisms without giving details neither the steps of the attack, nor the possible countermeasures, 3. Standard pattern: gathers more detailed attacks, i.e. the attack steps, countermeasures and the related CWE weaknesses of the attacks, 4. Detailed attack pattern: this lowest level of abstraction gathers the specialisations of standard attacks in some specific contexts or needs. For example, the "CAPEC-7 Blind SQL Injection" is a special case and therefore a child of the standard attack "CAPEC-66: SQL Injection".

The section "Related attack patterns" gives binary relations between two attacks (a, b). These relations can be:

• "a" is member of/child of "b": when the attack "a" is a refinement of the attack "b", • "a" has member/parent of "b": when the attack "a" is more abstract than the attack "b", • "a" can precede/can follow "b": when the attack "a" and "b" are put in sequence.

CLASSIFICATION METHODOLOGY

This methodology aims at inferring relationships among security attacks and security patterns, expressing which set of patterns can mitigate a given attack, completed with the relations among the patterns. Without loss of generality, we applied the following methodology on Web application attacks, but it can be applied on other kinds of applications.

After having studied the CAPEC base, we observed that attacks are described with a set of CWE weaknesses, a set of security principles and potential solutions and mitigations. These security activities can also be found in our previous classification (Regainia et al., 2016a), connecting weaknesses with security patterns. However, we noticed that the mitigations and security principles available in the attack documents often have a high level of abstraction making their use difficult. Furthermore, these are seldom supplied with attacks. As a consequence, to devise this classification with precision, we chose to decompose attacks into sub-properties, i.e. every attack is associated to its targeted weaknesses. We hence consider that a security pattern (or a set of patterns) is a solution to protect an application against a given attack if it is also the solution of a weakness targeted by the attack.

Our methodology is divided into five automatic steps, illustrated in Figure 2. In the first one, we collect the attacks of the CAPEC base and organise them into a hierarchy, from the more to the less abstract ones. In Step 2, we collect the relationships between every attack and CWE weaknesses, reflecting which weakness is targeted by an attack. In Step 3, we reuse our earlier classification (Regainia et al., 2016a) to extract for every CWE weakness, the security principles, mitigations and security patterns which fix the weakness. After the consolidation of the different databases built in the previous steps, we obtain a database DB f from which the classification is automatically extracted in Step 4. Finally, for a given attack, we depict with an ADTree the attack associated with its sub-attacks and with defenses in the form of security patterns, which are themselves combined by means of logic operations.

Each step of our proposed methodology is detailed below and illustrated with the attack "CAPEC-39: Manipulating Opaque Client-based Data Tokens", which expresses a threat on applications using tokens, e.g. cookies, which hold client data.

Step 1: CAPEC attack extraction and organisation

In this step, we want to extract the attacks found in the CAPEC base and organise them into a single tree, which describes a hierarchy of attacks from the most abstract to the most concrete ones so that, we can have, for a given attack, all its sub-attacks. To reach that goal, we rely on the relationships among attack patterns found in the CAPEC section "Related Attack Patterns" (CAPEC base, Version 2.8). Figure 3 presents an example for the attack CAPEC-39. The abstraction level of the attack is expressed in the column "Type" (C stands for Category, S for Standard pattern), the links with other attacks by "Nature".

By scrutinising all the CAPEC documents, it becomes possible to develop a hierarchical tree whose root node is unlabelled and connected to the attacks of the type "Category". These nodes may also be parent of attacks that belong to the type "Meta Attack pattern" and so on. The leaves are the most concrete attacks of the type "Detailed attack pattern".

We implemented this step with the tool Talend,1 an ELT (Extraction, Load, Transform) tool which allows an automated processing of data independently from the type of its source or destination, by scanning the CAPEC attacks from the more abstract (those of the type "Category") to the most concrete ones (in the type "Detailed Attack Patterns") and we stored the resulting hierarchical tree into a database DB 1 . This tree is currently composed of 215 attacks. The tree is composed of five levels w.r.t. the current CAPEC structure. If new attacks are added, our implementation can automatically take them into account to generate another tree.

Step 2: CWE weakness extraction from attacks

We automatically extract for every CAPEC attack of the database DB 1 the CWE weaknesses targeted by the attack. These can be found in the section "Related Weaknesses" of the CAPEC documents. Weaknesses are grouped into two categories, "Targeted" and "Secondary" ranking the impact degree of the attack on a weakness. We only focused on the type "Targeted" even though it could also be relevant to consider both types. The outcome of this systematic extraction is stored in a database DB 2 , which encodes a mapping from the 215 attacks to 136 CWE weaknesses. Unsurprisingly, we observed that the attacks having a high level of abstraction (those of Category and Meta Pattern) are not related to any CWE weakness.

The attack CAPEC-39, taken as example, targets six CWE weaknesses, which illustrates here that the attack is indeed segmented into security sub-properties. Among them, we have "Reliance on Cookies without Validation and Integrity Checking" or "Improper Authorization", which reflect more precise sub-properties than the attack itself. These can be mitigated by several security patterns, which are revealed by means of the next step.

Step 3: connection between CWE weaknesses and security patterns

We proposed in (Regainia et al., 2016a) a classification, which exposes relationships among software weaknesses, security principles and security patterns. More precisely, for a given weakness, it provides its mitigations, the security principles that have to be followed to fix the weakness, the strong points (sub-properties) of security patterns that meet these principles and finally the security patterns allowing to correct the weakness. From this classification, we automatically extract, for every weakness found in DB 2 the following information:

• the complete hierarchy of security principles Sp related to a weakness, i.e. the arrangements of principles from the most abstract ones to the most concrete principles,

• for every principle sp in Sp, the set P sp of security patterns associated with sp, the set P2 sp of patterns not in P sp that have relations with any pattern of P sp , and the nature of these relations defined for couples of patterns by the annotations in {depend, benefit, impair, alternative, conflict}.

This automatic step produces the database DB 3 .

Step 4: data consolidation and classification extraction

The databases obtained in the previous steps are integrated with the tool Talend into a single one, denoted DB f , which is available on-line in [START_REF] Regainia | Security pattern classification[END_REF]. With DB 1 , we have a hierarchical representation of attacks, which are eventually related to a set of CWE weaknesses given in DB 2 . DB 3 encodes the relations among these weaknesses, the related security principles and security patterns. Hence, DB f includes all the required information to expose several kinds of relations and classifications. For example, for a given attack, we can extract a hierarchical tree showing its sub-attacks. From this kind of extraction, attack trees [START_REF] Schneier | Attack trees: Modeling security threats[END_REF], could be generated. These show how a generic attack can be realised by more concrete attacks. Furthermore, the set of weaknesses targeted by an attack as well as the security principles that have to be followed to fix the weaknesses can also be selected from DB f . But, first and foremost, security patterns can be classified against attacks. We have chosen to catalogue the combinations of patterns that aim to mitigate a given attack, i.e. all the patterns that offer a mitigation for any weakness exploited by the attack. This step also automatically collects these combinations of patterns for every attack found in DB f . More precisely, for a given attack, we extract:

• the information about the attack (name, identifier, description, etc.),

• the set of patterns P that are related to all the weaknesses targeted by the attack and the set of patterns P2 not in P that have relations with any pattern of P , and the nature of these relations.

Figure 4 depicts an extraction example for the attack CAPEC-39. The tabular gives the attack name, the security pattern allowing to block the attack (column 3), another alternative pattern

Step 5: Attack-Defense Tree generation

We propose to greatly improve the readability of the classification, given in tabular form, by generating ADTrees, organising the attacks and the related security patterns. With ADTrees, attacks are illustrated with red nodes, which can be interconnected with the logic operations and , /or . An attack node can be mitigated with one defense node (in green squares) composed of sub defenses or one attack themselves combined the operations and /or . In our context, an ADTree shall be rooted by an attack chosen by a designer. This root node can be connected to other attack nodes, expressing sub-attacks, which can be connected to defense nodes, representing security patterns. Figure 5(a) illustrates a general example of ADTree. The "OR" operation is depicted with a group of classical edges, whereas "AND" is depicted with a group of classical edges connected with an arc.

ADTrees are generated by the following steps: 1. every CAPEC attack found in DB f has its own ADTree whose root node is labelled by its identifier. This root node is linked to other attack nodes if the attack has sub-attacks and so on until there is no more sub-attack. We obtain a sub-tree of the original hierarchical tree extracted in Step 1. All the attack nodes are here combined with the "OR" operation meaning that an attack can be accomplished if one of its sub-attacks is successfully done, 2. for every attack node A, we collect the set P of security patterns that mitigate the attack as well as the set P2 of security patterns having relations with some patterns of P . Given a couple of patterns (p 1 , p 2 ) ∈ P ∪ P2 , we illustrate these relations with new nodes and logic operations. If we have: We may denote that "Depend " and "Benifit" relationships are presented two of them with the same "and "and this is explained by the fact that ADtrees do not allow to make contrast between these two types of relationships. The parent defense nodes, resulting from the above steps, are combined to a defense node labelled by "Pattern Composition" with AND. This last defense node is linked to the attack node A. If we take back our example of attack, we obtain the ADTree of Figure 6, which shows that the attack CAPEC-39 has 1 sub-attack named "CAPEC-31 Accessing/Intercepting/Modifying HTTP Cookies". Because of lack of room, we presented in this example the security patterns directly related to the attack. An ADtree generated by our tool [START_REF] Regainia | Attack defence trees generator[END_REF] illustrates the patterns of the set P but also the set P 2 of patterns having a relation with those of P . Both of the two attacks target 17 weaknesses (6 for the CAPEC-39 and 11 for the CAPEC-31, which is more detailed). The attack and all its concrete forms can be mitigated by several combinations over 15 security patterns. For instance, the attack CAPEC-39 can be mitigated by two pattern combinations because the pattern "Application Firewall" can be replaced with "Input Guard". The number of security patterns related to both attacks CAPEC-39 and CAPEC-31 is explained here by the diversity of the targeted weaknesses. We assume for the classification generation that all of them have to be mitigated. As these ones cover different security issues here, e.g., input val-idation problems, privilege management, encryption problems, external control of the application state, etc., several patterns are required to fix the weaknesses and hence block the attacks.

This example illustrates that a designer can follow the concrete materialisations of an attack in an ADTree. He/she can choose the most appropriate attack with respect to the context of the application being designed. The ADTree provides the different security pattern combinations that have to be used to mitigate this attack. In the worst case, an attack node is not linked to a defense node, which means that either the classification is incomplete or the attack is relatively new and cannot be yet overcame by security patterns.

CLASSIFICATION DISCUSSION

Our current classification is an exemplary taxonomy built on a non exhaustive set of 215 CAPEC attacks, 26 security patterns and 136 CWE weaknesses related to Web applications. The classification and its complete list of elements is available in [START_REF] Regainia | Security pattern classification[END_REF]. Presented in tabular form, as illustrated in Figure 4, it enables multi-attribute based decisions insofar as patterns can be classified according to security principles, weaknesses and attacks.

The proposed classification complies with several quality criteria defined in [START_REF] Alvi | A Comparative Study of Software Security Pattern Classifications[END_REF]. Among them, we have noted Navigability, Unambiguity and the Usefulness of the classification:

• Navigability, which is defined as the ability to direct designers among related patterns, is satisfied since we illustrate the classification with ADTrees. They indeed expose the hierarchical refinements of attacks and a combination of defenses that have to be applied to protect the application to design. The links between nodes exhibit the relationships considered in each step of the methodology,

• Unambiguity is taken into account since the classification is clearly defined by means of the methodology steps, which provide relations among attacks, weaknesses, security principles and security patterns. All these steps and those given in (Regainia et al., 2016a) justify the soundness of the classification. In addition, the classification provides the rela-tionships among patterns, which help choose a correct combination of patterns, i.e. a conflicting combination can be avoided, the required patterns of another pattern are given,

• we believe the classification can be used in practice since it is based upon the CAPEC and CWE bases and of several security patterns presented in [START_REF] Fernandez | Security patterns and secure systems design[END_REF][START_REF] Slavin | Security patterns repository[END_REF]. In addition, the ADTree formalism is one of the most prominent security formalism for analysing threats, it is supported by tools [START_REF] Kordy | ADTool: Security Analysis with Attack-Defense Trees[END_REF] for editing, analysing and transforming them. Our ADTree generator actually generates XML files taken as inputs by these tools. Furthermore, a variety of statistical information can be automatically extracted from our classification, e.g., the ratio of weaknesses to attacks, of patterns to attacks, etc. For instance, Figure 7 also shows the number of attacks at least partially mitigated per pattern. Keeping in mind, that the set of patterns taken into consideration is not exhaustive, we can observe that 2 patterns seem to emerge for partly fixing a large part of the 210 attacks covered by the classification: "Input Guard" and "Application firewall", can overcome 113 and 109 attacks respectively. This kind of information shows that, from our classification, some useful outcomes can be extracted to guide designers towards security analysis and good practices. For instance, with the above chart and ADTrees, a designer can deduce that the patterns "Input Guard" and "Application firewall" are alternative security patterns and that one of them should be used in software design since they both partially block numerous attacks.

Our classification and methodology present some limitations, which could lead to some re-search future work. We did not envisaged the notion of attack combination. Such a combination could be seen as several attacks or as one particular attack. In the first case, an attack combination can be represented in the CAPEC base as a sequence, which is given in a specific CAPEC section called "Attack execution Flow". Our classification does not yet store and use the notion of ordered events. In the second case, if the attack has its own identification in the CAPEC base, it can be used with our methodology.

The classification is not exhaustive: it includes 215 attacks out of 569 (for any kind of application), 210 CWE weaknesses out of around 1000 and 26 security patterns out of around 176. It can be completed with new attacks automatically. But it worth mentioning that the addition of new security patterns or weaknesses requires some manual steps. Our previous classification, proposed in (Regainia et al., 2016a), associates weaknesses and security patterns from documentation: if a new security pattern has to be added, two steps have to be manually done (mapping between the pattern and its strong points, and mapping between strong points and security principles). In the same way, if a new CWE weakness is added, two other steps must be manually completed (mitigation extraction, mapping between mitigations and security principles). The re-generation of the whole classification, which includes new attacks, weaknesses or security patterns is automatically performed. It could relevant to investigate whether some text mining techniques would help partially automate these manual steps without adding ambiguity.

CONCLUSION

In this paper, we have presented a classification methodology putting together CAPEC attacks, CWE weaknesses and security patterns to guide designers in their pattern choices. Given an attack, the classification provides a hierarchical tree of its sub-attacks (up to the most concrete ones), the targeted weaknesses, the security principles that have to be addressed to fix the weaknesses and the combinations of patterns that overcome the attacks. The classification is available in [START_REF] Regainia | Security pattern classification[END_REF]. ADTrees are automatically generated from the classification to ease its readability. For each attack of the classification, they portray its sub-attacks and combinations of security patterns. These ADTrees can be taken as a first step of other security processes, e.g., threat modelling.

Our most immediate line of future work is related to a specific section of the CAPEC base, called "Attack execution Flow", listing the sequences of attacks (not the sets) that have to be followed to execute a meta-attack. We intend to take this section into consideration to extend the classification and the generation of extended ADTrees so that the latter explicitly show these attack sequences. The resulting trees (called SAND trees) shall increase the expressiveness of the ADTrees by adding the notion of ordered events. Then, from these SAND trees and the information included in the classification, we will focus on the generation of (generic) test cases to check whether an implementation is protected against the attacks or if security patterns are correctly contextualised and implemented w.r.t. the application context.

Figure 1 :

 1 Figure 1: Application Firewall pattern For example, Figure 1 portrays the UML class diagram of the pattern "Application Firewall "

Figure 2 :

 2 Figure 2: Classification methodology

Figure 4 :

 4 Figure 4: Data extraction for the attack CAPEC-39

Figure 6 :

 6 Figure 6: ADTree of the attack CAPEC-39

Figure 7 :

 7 Figure 7: Number of fixed attacks per pattern

  • (p 1 depend p 2 ) or (p 1 benefit p 2 ), we build three defense nodes, one parent node labelled by p 1 AND p 2 and two nodes labelled by p 1 , p 2 combined with this parent defense node by the AND operation, • (p 1 alternative p 2 ), we build three nodes, one parent node labelled by p 1 OR p 2 and tw nodes labelled by p 1 , p 2 combined with the parent defense node by the OR opera-

	attack node meaning that two conflicting
	security patterns used together constitute
	a kind of attack. The generic sub-tree is
	depicted in Figure 5(b),
	• p 1 having no relation with any pattern p 2
	in P ∪ P 2 , we add the parent defense node
	labelled with p 1 .
	tion,
	• (p 1 impair p 2 ) or (p 1 conflict p 2 ), we want
	to use (p 1 XOR p 2 ) since the presence of
	p 2 decreases the efficiency or conflicts with
	p 1 . Unfortunately, the XOR operation is
	not available with ADTrees. Therefore, we
	replace the operator by the classical formula
	(A xor B ) -→ ((A or B ) and not (A and B )).
	The NOT operation is here replaced by an

https://talend.com/