An Advanced Approach for Choosing Security Patterns and Checking their Implementation
AAn Advanced Approach for Choosing Security Patterns and Checking theirImplementation
S´ebastien Salva ∗ , Loukmen Regainia † LIMOS - UMR CNRS 6158University Clermont Auvergne, FranceEmail: ∗ [email protected], † [email protected] Abstract —This paper tackles the problems of generatingconcrete test cases for testing whether an application is vulner-able to attacks, and of checking whether security solutions arecorrectly implemented. The approach proposed in the paperaims at guiding developers towards the implementation ofsecure applications, from the threat modelling stage up tothe testing one. This approach relies on a knowledge baseintegrating varied security data, e.g., attacks, attack steps, andsecurity patterns that are generic and re-usable solutions todesign secure applications. The first stage of the approachconsists in assisting developers in the design of Attack De-fense Trees expressing the attacker possibilities to compromisean application and the defenses that may be implemented.These defenses are given under the form of security patterncombinations. In the second stage, these trees are used toguide developers in the test case generation. After the testcase execution, test verdicts show whether an application isvulnerable to the threats modelled by an ADTree. The laststage of the approach checks whether behavioural propertiesof security patterns hold in the application traces collectedwhile the test case execution. These properties are formalisedwith LTL properties, which are generated from the knowledgebase. Developers do not have to write LTL properties not tobe expert in formal models. We experimented the approach on10 Web applications to evaluate its testing effectiveness and itsperformance.
Keywords - Security Pattern; Security Testing; Attack-DefenseTree; Test Case Generation.
I. I
NTRODUCTION
Todays developers are no longer just expected to codeand build applications. They also have to ensure that ap-plications meet minimum reliability guarantees and securityrequirements. Unfortunately, choosing security solutions ortesting software security are not known to be simple oreffortless activities. Developers are indeed overloaded ofnew trends, frameworks, security issues, documents, etc.Furthermore, they sometimes lack skills and experience forchoosing security solutions or writing concrete test cases.They need to be guided on how to design or implementsecure applications and test them, in order to contribute ina solid quality assurance process.This work focuses on this need and proposes an approachthat guides developers devise more secure applications fromthe threat modelling stage, which is a process consisting inidentifying the potential threats of an application, up to thetesting one. The present paper is an extended version of [1], which provides additional details on the security test casegeneration, the formalisation of behavioural properties ofsecurity patterns with Linear Temporal Logic (LTL) proper-ties, and on their automatic generation. We also provide anevaluation of the approach and discuss the threats to validity.In order to guide developers, our approach is basedupon several several digitalised security bases or documentsgathered in a knowledge base. In particular, the latter in-cludes security solutions under the form of security patterns,which can be chosen and applied as soon as the applicationdesign. Security patterns are defined as reusable elementsto design secure applications, which will enable softwarearchitects and designers to produce a system that meetstheir security requirements and that is maintainable andextensible from the smallest to the largest systems [2].Our approach helps developers chose security patterns withregard to given security threats. Then, it builds security testcases to check whether an application is vulnerable, and testwhether security patterns are correctly implemented in theapplication. More precisely, the contributions of this workare summarised in the following points: • the approach assists developers in the threat modellingstage by helping in the generation of Attack DefenseTrees (ADTrees) [3]. The latter express the attackerpossibilities to compromise an application, and give thedefenses that may be put in place to prevent attacks.Defenses are here expressed with security patterns.We have chosen this tree model because it offers theadvantage of being easy to understand even for novicesin security; • the second part of the approach supports developersin writing concrete security test cases. A test suite isautomatically extracted from an ADTree. The test suiteis made up of test case stubs, which are completedwith comments or blocs of code. Once completed,these are used to experiment an application undertest (shortened AU T ), seen as a black-box. The testcase execution provides verdicts expressing whetherthe
AU T is vulnerable to the threats modelled in theADTree; • the last part of the approach allows developers to checkwhether security patterns are correctly implemented in a r X i v : . [ c s . S E ] J u l he application. Kobashi et al. dealt with this task byasking users to manually translate security pattern be-haviours into formal properties [4]. Unfortunately, fewdevelopers have the required skills in formal modelling.We hence prefer proposing a practical way to generatethem. After the security pattern choice, our approachprovides generic UML sequence diagrams, which canbe adapted to better match the application context.From these diagrams, the approach automatically gen-erate LTL properties. After the test case execution, wecheck if these properties hold in the application traces.The developer is hence not aware of the LTL propertygeneration.We have implemented this approach in a tool prototypeavailable in [5]. This tool was used to conduct severalexperiments on 10 Web applications to evaluate the securitytesting and security pattern testing effectiveness of the toolas well as its performance. Paper Organisation:
Section II outlines the context of thiswork. We recall some basic concepts and notations aboutsecurity patterns and ADTrees. We also discuss about therelated work and our motivations. Section III briefly presentsthe architecture of the knowledge base used by our approach.The approach steps are described in Section IV. These stepsare gathered into 3 stages called threat modelling, securitytesting, and security pattern testing. Subsequently, SectionV describes our prototype implementation, and Section VIevaluates the approach. Finally, Section VII summarizes ourcontributions and presents future work.II. B
ACKGROUND
This section recalls the basic concepts related to securitypatterns and Attack Defense trees. The related work ispresented thereafter.
A. Security Patterns
Security patterns provide guidelines for secure systemdesign and evaluation [6]. They also are considered ascountermeasures to threats and attacks [7]. Security pat-terns have to be selected in the design stage, integratedin application models, and eventually implemented. Theirdescriptions are usually given with texts or schema. But,they are often characterised by UML diagrams capturingstructural or behavioural properties.Several security pattern catalogues are available in the lit-erature, e.g., [8], [9], themselves extracted from other papers.In these catalogues, security patterns are systematically or-ganised according to features and relationships among them.Among these features, we often find the solutions calledintents, or the interests called forces. A security patternmay have different relationships with other patterns. Theserelations may noticeably help combine patterns together andnot to devise unsound composite patterns. Yskout et al.proposed the following annotations between two patterns
Figure 1. Class layout of the security pattern “Intercepting Validator”. [10]: “depend”, “benefit”, “impair” (the functioning of thepattern can be obstructed by the implementation of a secondone), “alternative”, “conflict”.Figure 1 depicts the UML structural diagram of thesecurity pattern “Intercepting Validator”, which is takenas example is the remainder of the paper. Its purpose isto provide the application with a centralized validationmechanism, which applies some filters (Validator classes)declaratively based on URL, allowing different requests to bemapped to different filter chains. This validation mechanismis decoupled from the other parts of the application and eachdata supplied by the client is validated before being used.The validation of input data prevents attackers from passingmalformed input in order to inject malicious commands.
B. Attack Defense Trees
ADTrees are graphical representations of possible mea-sures an attacker might take in order to compromise asystem and the defenses that a defender may employ toprotect the system [3]. ADTrees have two different kinds ofnodes: attack nodes (red circles) and defense nodes (greensquares). A node can be refined with child nodes and canhave one child of the opposite type (linked with a dashedline). Node refinements can be disjunctive or conjunctive.The former is recognisable by edges going from a nodeto its children. The latter is graphically distinguishable byconnecting these edges with an arc. We extend these tworefinements with the sequential conjunctive refinement ofattack nodes, defined by the same authors in [11]. Thisoperator expresses the execution order of child attack nodes.Graphically, a sequential conjunctive refinement is depictedby connecting the edges, going from a node to its children,with an arrow.For instance, the ADTree of Figure 2 identifies the ob-jectives of an attacker or the possible vulnerabilities relatedto the supply of untrusted inputs to an application. The rootnode is here detailed with disjunctive refinements connectingthree leaves, which are labelled by attack referenced in abase called the Common Attack Pattern Enumeration andClassification (CAPEC) [12]. The node CAPEC-66 refersto “SQL Injection”, CAPEC-250 refers to XML injectionsand CAPEC-244 to “Cross-Site Scripting via Encoded URISchemes”. igure 2. ADTree example modelling injection attacks
An ADTree T can be formulated with an algebraicexpression called ADTerm and denoted ι ( T ) . In short, theADTerm syntax is composed of operators having types givenas exponents in { o, p } with o modelling an opponent and p a proponent. ∨ s , ∧ s , −→∧ s , with s ∈ { o, p } respectively standfor the disjunctive refinement, the conjunctive refinementand the sequential conjunctive refinement of a node. Alast operator c expresses counteractions (dashed lines in thegraphical tree). c s ( a, d ) intuitively means that there existsan action d (not of type s) that counteracts the action a (oftype s). The ADTree of Figure 2 can be represented with theADTerm ∨ p ( ∨ p ( CAPEC-66, CAPEC-250 ) , CAPEC-244 ) . C. Related Work
The literature proposes several papers dealing with thetest case generation from Attack trees (or related models)and some other ones about security pattern testing. As thesetopics are related to our work, we introduce them below andgive some observations.
1) Security Testing From Threat Models: the generationof concrete test cases from models has been widely studiedin the last decade, in particular to test the security levelof different kinds of systems, protocols or software. Mostof the proposed approaches take specifications expressingthe expected behaviours of the implementation. But, otherauthors preferred to bring security aspects out and usedmodels describing attacker goals or vulnerability causes ofthe system. Such models are conceived during the threatmodelling phase of the system [13], which is consideredas a critical phase of the software life cycle since ”youcannot build a secure system until you understand yourthreats!” [14]. Schieferdecker et al. presented a survey paperreferencing some approaches in this area [15]. For instance,Xu et al. proposed to test the security of Web applicationswith models as Petri nets to describe attacks [16]. Attackscenarios are extracted from the Reachability graphs of thePetri nets. Then, test cases written for the Selenium toolare generated by means of a MIM (Model- ImplementationMapping) description, which maps each Petri net placeand transition to a block of code. Bozic et al. proposed asecurity testing approach associating UML state diagrams torepresent attacks, and combinatorial testing to generate input values used to make executable test cases derived from UMLmodels [17].Other authors adopted models as trees (Attack trees,vulnerability Cause Graphs, Security Activity Graphs, etc.)to represent the threats, attacks or vulnerability causes thatshould be prevented in an application. From these models,test cases are then written to check whether attacks can besuccessfully executed or whether vulnerabilities are detectedin the implementation. Morai et al. introduced a securitytesting approach specialised for network protocols [18].Attack scenarios are extracted from an Attack tree andare converted to Attack patterns and UML specifications.From these, attack scripts are manually written and arecompleted with the injection of (network) faults. In thesecurity testing method proposed in [19], data flow diagramsare converted into Attack trees from which sequences areextracted. These sequences are composed of events com-bined with parameters related to regular expressions. Theseevents are then replaced with blocks of code to producetest cases. The work published in [20] provides a manualprocess composed of eight steps. Given an Attack tree,these steps transform it into a State chart model, whichis iteratively completed and transformed before using amodel-based testing technique to generate test cases. In [21],test cases are generated from Threat trees. The latter arepreviously completed with parameters associated to regularexpressions to generate input values. Security scenarios areextracted from the Threat trees and are manually convertedto executable test scripts. Shahmehri et al. proposed a passivetesting approach, which monitors an
AU T to detect vul-nerabilities [22]. The undesired vulnerabilities are modelledwith security goal models, which are specialised directedacyclic graphs showing security goals, vulnerabilities andeventually mitigations. Detection conditions are then semi-automatically extracted and given to a monitoring tool.We observed that the above methods either automaticallygenerate abstract test cases from (formal) specifications orhelp write concrete test cases from detailed threat models.On the one hand, as abstract test cases cannot be directlyused to experiment an
AU T , some works proposed test casetransformation techniques. However, this kind of techniqueis at the moment very limited. On the other hand, Onlya few of developers have the required skills to write threatmodels or test cases, as a strong expertise on security is oftenrequired. Besides, the methods neither guide developers inthe threat modelling phase nor provide any security solution.We focused on this problem and laid the first stone of thepresent approach in [23], [24], [25]. We firstly presenteda semi-automatic data integration method [23] to buildsecurity pattern classifications. This method extracts securitydata from various Web and publicly accessible sourcesand stores relationships among attacks, security principlesand security patterns into a knowledge base. Section IIIsummarises the results of this work used in this paper, i.e.,he first meta-model version of the data-store. In [24], weproposed an approach to help developers write ADTrees andconcrete security test cases to check whether an applicationis vulnerable to these attacks. This work was extended in[25] to support the generation of test suites composed oflists of ordered GWT test cases, a list being devoted tocheck whether an AUT is vulnerable to an attack, whichis segmented into an ordered sequence of attack steps. Thistest suite organisation is used to reduce the test costs withthe deduction of some test verdicts under certain conditions.However, it does not assist developers to ensure that securitypatterns have been correctly implemented in the application.This work supplements our early study by covering this part.
2) Security Pattern Testing: the verification of patternson models was studied in [26], [27], [28], [4], [29]. In thesepapers, pattern goals or intents or structural properties arespecified with UML sequence diagrams [26] with expres-sions written with the Object Constraint Language (OCL)[27], [28], [4] or with LTL properties [29]. The patternfeatures are then checked on UML models.Few works dealt with the testing of security patterns,which is the main topic of this paper. Yoshizawa et al.introduced a method for testing whether behavioural andstructural properties of patterns may be observed in ap-plication traces [28]. Given a security pattern, two testtemplates (Object Constraint Language (OCL) expressions)are manually written, one to specify the pattern structureand another one to encode its behaviour. Then, developershave to make templates concrete by manually writing testsfor experimenting the application. The latter returns traceson which the OCL expressions are verified.We observed that these previous works require the mod-elling of security patterns or vulnerabilities with formalproperties. Instead of assuming that developers are expertin the writing of formal properties, we propose a practicalway to generate them. Intuitively, after the choice of securitypatterns, our approach provides generic UML sequencediagrams, which can be modified by a developer. From thesediagrams, we automatically generate LTL properties, whichcapture the cause-effects relations among pairs of methodcalls. After the test case execution, we check if these prop-erties hold in the application traces, obtained while the testcase execution. The developer is hence not aware of the LTLproperty generation. As stated in the introduction, this workprovides more details on test case generation and on theformalisation of behavioural properties of security patternswith LTL properties. We also complete the transformationrules allowing to derive more LTL properties from UMLsequence diagrams. We also provide an evaluation of theapproach targeting the security pattern testing stage anddiscuss the threats to validity. III. K
NOWLEDGE B ASE O VERVIEW
Our approach relies on a knowledge base, denoted KB inthe remainder of the paper. It gathers information allowingto help or automate some steps of the testing process. Wesummarise its architecture in this section but we refer to [23]for a complete description of its associations and of the dataintegration process.
A. Knowledge Base Meta-Model
Figure 3 exposes the meta-model used to structure theknowledge base KB. The entities refer to security propertiesand the relations encode associations among them. Theentities in white are used to generated ADTrees, while thosein grey are specialised for testing. The meta-model firstly as-sociates attacks, techniques, security principles and securitypatterns. This is the result of observations we made fromthe literature and some security documents, e.g., the CAPECbase or security pattern catalogues [8], [9]: we consider thatan attack can be documented with more concrete attacks,which can be segmented into ordered steps; an attack stepprovides information about the target or puts an applicationinto a state, which are reused by a potential next step. Attacksteps are performed with techniques and can be preventedwith countermeasures. Security patterns are characterisedwith strong points, which are pattern features extractablefrom their descriptions. The meta-model also captures theinter-pattern relationships defined in [10], e.g., ”depend” or”conflict”. Countermeasures and strong points refer to thesame notion of attack prevention. But finding direct relationsbetween countermeasures and strong points is tedious asthese properties have different purposes. To solve this issue,we used a text mining and a clustering technique to group thecountermeasures that refer to the same security principles,which are desirable security properties. To link clusters andstrong points, we chose to focus on these security principlesas mediators. We organised security principles into a hierar-chy, from the most abstract to the most concrete principles.We provide a complete description of this hierarchy in [24].In short, we collected and organised 66 security principlescovering the security patterns of the catalogue given in [9].The hierarchy has four levels, the first one being composedof elements labelled by the most abstract principles, e.g.,“Access Control”, and the lower level exhibiting the mostconcrete principles, e.g., “File Authorization”.Furthermore, every attack step is associated to one testcase structured with the Given When Then (GWT) pattern.We indeed consider in this paper that a test case is apiece of code that lists stimuli supplied to an AUT andresponses checked by assertions assigning (local) verdicts.To make test cases readable and re-usable, we use thebehaviour driven approach using the pattern “Given WhenThen” (shortened GWT) to break up test cases into severalsections: igure 3. Data-store meta-model • Given sections aim at putting the
AU T into a knownstate; • When sections trigger some actions (stimuli); • Then sections are used to check whether the conditionsof success of the test case are met with assertions. In thepaper, the Then sections are used to check whether an
AU T is vulnerable to an attack step st . In this case, theThen section returns the verdict “ P ass st ”. Otherwise,it provides the verdict “ F ail st ”. When a unexpectedevent occurs, we also assume that “ Inconclusive st ”may be returned.The meta-model of Figure 3 associates an attack step witha GWT test case by adding three entities (Given When andThen section) and relations. In addition, a test case sectionis linked to one procedure, which implements it. A sectionor a procedure can be reused with several attack steps orsecurity patterns. The meta-model also reflects the fact thatan attack step is associated with one “Test architecture”and with one “Application context”. The former refers totextual paragraphs explaining the points of observation andcontrol, testers or tools required to execute the attack stepon an AU T . An application context refers to a family, e.g.,Android applications, or Web sites. As a consequence, aGWT test case section (and procedure) is classified accord-ing to one application context and one attack step or patternconsequence.We finally updated the meta-model in such a way that a security pattern is also associated to generic UML se-quence diagrams, themselves arranged in Application con-texts. Security pattern catalogues often provide UML se-quence diagrams expressing the security pattern behavioursor structures. These diagrams often help correctly implementa security pattern with regard to an application context.
B. Data Integration
We integrated data into KB by collecting them fromheterogeneous sources: the CAPEC base, several papersdealing with security principles [30], [31], [32], [33], [34],the pattern catalogue given in [35] and the inter-patternrelations given in [10]. We details the data acquisition andintegration steps in [23]. Six manual or automatic steps arerequired: Steps 1 to 5 give birth to databases that storesecurity properties and establishing the different relationspresented in Figure 3. Step 6 consolidates them so thatevery entity of the meta-model is related to the other ones asexpected. The steps 1,2 and 6 are automatically done withtools.The current knowledge base KB includes informationabout 215 attacks (209 attack steps, 448 techniques), 26 se-curity patterns, 66 security principles. We also generated 627GWT test case sections (Given, When and Then sections)and 209 procedures. The latter are composed of commentsexplaining: which techniques can be used to execute anattack step and which observations reveal that the applicationis vulnerable. We manually completed 32 procedures, whichover 43 attack steps. Security patterns are associated to atleast one UML diagram. This knowledge base is availablein [5].It is worth noting that KB can be semi-automaticallyupdated if new security data are available. If a new threat ortype of attack is discovered and added to the CAPEC base,the steps 1, 2 and 5 have to be followed again. Likewise, ifa new security pattern is proposed in the literature, the steps3,4 and 5 have to be reapplied.IV. S
ECURITY T ESTING AND S ECURITY P ATTERN V ERIFICATION
A. Approach Overview
We present in this section our testing approach whosesteps are illustrated in Figure 4. As illustrated in the figure,the purpose of this approach is threefold:1)
Threat modelling: it firstly aims at guiding developersthrough the elaboration of a threat model (left sideof the figure). The developer gives an initial ADTreeexpressing attacker capabilities (Step 1). By meansof KB, this tree is automatically detailed and com-pleted with security patterns combinations expressingsecurity solutions that may be put in place in theapplication design (Step 2). The tree may be modifiedto match the developer wishes (Step 3). The resultingADTree, which is denoted T f , captures possible attackscenarios and countermeasures given under the formof security pattern combinations. The set of securitypatterns chosen by the developer is denoted SP ( T f ) .2) Security testing: from T f , the approach generates testcase stubs, which are structured with the GWT pattern(Step 4). These stubs guide developers in the writingof concrete test cases (Step 8). The final test suiteis executed on the AU T to check whether the AUTis vulnerable to the attack scenarios expressed in theADTree T f (Step 9).3) Security pattern verification: the last part of theapproach is devoted to checking whether securitypattern behaviours hold in the
AU T traces. A set ofgeneric UML sequence diagrams are extracted, fromKB, for every security pattern in SP ( T f ) (Step 5).These show how security patterns classes or compo-nents should behave and help developers implementthem in the application. These diagrams are usuallyadapted to match the application context (Step 6).The approach skims the UML sequence diagramsand automatically generates LTL properties encodingbehavioural properties of the security patterns (Step 7).While the test case execution, the approach collects the AU T method-call traces on which it checks whetherthe LTL properties are satisfied (Step 10).The remaining of this section describes more formally thesteps depicted in Figure 4.
B. Threat Modelling, Security Pattern Choice (Step 1 to 3)
Step 1: Initial ADTree Design
The developer draws a first ADTree T whose root noderepresents some attacker’s goals. This node may be refinedwith several layers of children to refine these goals. Differentmethods can be followed, e.g., DREAD [36], to build thisthreat model. We here assume that the leaves of this ADTreeare exclusively labelled by CAPEC attack identifiers, sinceour knowledge base KB is framed upon the CAPEC base.Figure 2 illustrates an example ADTree achieved for thisstep. The leaves of this tree are labelled by CAPEC attacksrelated to different kinds of injection-based attacks. Itsdescribes in general terms attacker goals, but this model isnot sufficiently detailed to generate test cases or to choosesecurity solutions. Step 2: ADTree Generation
KB is now queried to complete T with more details aboutthe attack execution phase and with defense nodes labelledby security patterns. For every leave of T labelled by anattack A , an ADTree T ( A ) , is generated from KB. We referto [24] for the description of the ADTree generation.We have implemented the ADTree generation with a tool,which takes attacks of KB and yields XML files. These canbe edited with the tool ADTool [3]. For instance, Figures 6and 7 show the ADTrees generated for the attacks CAPEC-66 and CAPEC-244. The ADTrees generated by this step arecomposed of several levels of attacks, having different levelsof abstraction. The attack steps have child nodes referring toattack techniques, which indicate how to carry out the step.For instance the technique 1.1.1 is “Use a spidering toolto follow and record all links and analyze the web pages tofind entry points. Make special note of any links that includeparameters in the URL”. An attack step node is also linkedto a defense node expressing security pattern combinations.Some nodes express inter-pattern relations. For instance,the node labelled by “Alternative” has children expressingseveral possible patterns to counter the attack step.Figures 6 and 7 also reveal that our generated ADTreesfollow the structure of our meta-model of Figure 3. Thisstructure has the generic form given in Figure 5: ADTreeshave a root attack node, which may be disjunctively refinedwith other attacks and so forth. The most concrete attacknodes are linked to defense nodes labelled by securitypatterns. We formulate in the next proposition that thesenodes or sub-trees also are encoded with specific ADTerms,which shall be used for the test case generation:
Proposition 1
An ADTree T ( A ) achieved by the previoussteps has an ADTerm ι ( T ( A )) having one of these forms: ∨ p ( t , . . . , t n ) with t i (1 ≤ i ≤ n ) an ADTerm alsohaving one of these forms: −→∧ p ( t , . . . , t n ) with t i (1 ≤ i ≤ n ) an ADTerm havingthe form given in 2) or 3); DTree generationInitial ADTree modellingADTree for each CAPEC attackSecurity pattern choice & ADTree editionThreat modelling stage GWT test casecompletionTest caseexecutionSecurity Testing verditsVulnerable(Tf)123 GWT test case generation489
AutomaticstepManual step
UML seq. Diag.extraction5 UML seq. DiagramOptional edition6 LTL propertygeneration7) verification10 Security pattern verification verditsUnsat(SP(Tf))Final ADTree TfSecurity patterns SP(Tf) GWT Test case stubs (Eclipse project) UML Seq. Diag.Method-callTracesTraces(AUTSecurity testing stage Security pattern verification stage
Figure 4. Overview of the 10 steps of the approachFigure 5. Genenal form of the generated ADTrees c p ( st, sp ) , with st an ADTerm expressing an attackstep and sp an ADTerm modelling a security patterncombination. The first ADTerm expresses child nodes labelled by more concrete attacks. The second one represents sequences ofattack steps. The last ADTerm is composed of an attackstep st refined with techniques, which can be counteractedby a security pattern combination sp = ∧ o ( sp , . . . , sp m ) .In the remainder of the paper, we denote the last expres-sion c p ( st, sp ) a Basic Attack Defence Step , shortened asBADStep:
Definition 2 (Basic Attack Defence Step (BADStep))
ABADStep b is an ADTerm of the form c p ( st, sp ) , where st is a step only refined with techniques and sp an ADTerm ofthe form: sp , with sp a security pattern, ∧ o ( sp , . . . , sp m ) modelling the conjunction of thesecurity patterns sp , . . . ,sp m ( m > . defense( b ) = def { sp } iff sp = sp , or defense( b ) = def { sp , . . . , sp m } iff sp = ∧ o ( sp , . . . , sp m ) . BADStep( T ) denotes the set of BADSteps of the ADTree T . Step 3: Security Pattern Choice and ADTree Edition igure 6. ADTree of the Attack CAPEC-66Figure 7. ADTree of the Attack CAPEC-244
The developer may now edit every ADTree T ( A ) gen-erated by the previous step and choose security patternswhen several possibilities are available. We assume thatthe defense nodes linked to attack nodes have conjunctiverefinements of nodes labelled by security patterns only.Figure 8 depicts an example of modified ADTree of theattack CAPEC-244.Every attack node A of the initial ADTree T is nowautomatically replaced with the ADTree T ( A ) . This stepis achieved by substituting every term A in the ADTerm ι ( T ) by ι ( T ( A )) . We denote ι ( T f ) the resulting ADTermand T f the final ADTree. It depicts a logical breakdown ofthe options available to an attacker and the defences, materi-alised with security patterns, which have to be inserted intothe application model and then implemented. The securitypattern set found in T f is denoted SP ( T f ) .This step finally builds a report by extracting from KBthe test architecture descriptions needed for executing theattacks on the AU T and observing its reactions. igure 8. Final ADTree of the Attack CAPEC-244
C. Security Testing
We now extract attack-defense scenarios to later build testsuites that will check whether attacks are effective on the
AU T . An attack-defense scenario is a minimal combinationof events leading to the root attack, minimal in the sensethat, if any event of the attack-defense scenario is omitted,then the root goal will not be achieved.The set of attack-defense scenarios of T f are extracted bymeans of the disjunctive decomposition of ι ( T f ) : Definition 3 (Attack scenarios)
Let T f be an ADTree and ι ( T f ) be its ADTerm. The set of Attack scenarios of T f ,denoted SC ( T f ) is the set of clauses of the disjunctivenormal form of ι ( T f ) over BADStep ( T f ) . BADStep ( s ) denotes the set of BADSteps of a scenario s . An attack scenario s is still an ADTerm. Its satisfiabilitymeans that the main goal of the ADTree T f is feasibleby achieving the scenario formulated by s . BADStep ( s ) denotes the set of BADSteps of s . Step 4: Test Suite Generation
Let s ∈ SC ( T f ) be an attack-defense scenario and b = c p ( st, sp ) ∈ BADStep ( s ) a BADSteps of s . Step 4generates the GWT test case T C ( b ) composed of 3 sectionsextracted from KB with the relations testG , testW and testT : we have one Given section, one When section andone Then section, each related to one procedure. This Thensection aims to assert whether the AU T is vulnerable to theattack step st executed by the When section.The final test suite T S , derived from an ADTree T f ,is obtained after having iteratively applied this test caseconstruction on the scenarios of SC ( T f ) . This is capturedby the following definition: Definition 4 (Test suites)
Let T f be an ADTree, s ∈ SC ( T f ) and b ∈ BADStep ( s ) . T S = { T C ( b ) | b = c p ( st, sp ) ∈ BADStep ( s ) and s ∈ SC ( T f ) } . @capec244Feature: CAPEC-244: Cross-Site Scripting viaEncoded URI Schemes Figure 9. The test case stub of the first step of the attack CAPEC 244
We have implemented these steps to yield GWT test casestubs compatible with the Cucumber framework [37], whichsupports a large number of languages. Figure 9 gives a testcase stub example obtained with our tool from the firststep of the attack CAPEC-244 depicted in Figure 7. Thetest case lists the Given When Then sections in a readablemanner. Every section is associated to a generic procedurestored into another file. The procedure related to the Whenand Then sections are given in Figure 10. The commentscome from KB and the CAPEC base. In this example, theprocedure includes a generic block of code, which may bereused with several applications; the “getSpider()” methodrelates to the call of the ZAProxy tool, which crawls aWeb application to get its URLs. Step 8: Test Case Stub Completion
In the beginning of this step, the test case procedures aregeneric, which means that they are composed of commentsor generic block of codes that help developers completethem. In the previous test case example, it only remains forthe developer to write the initial URL of the Web applicationbefore testing whether it can be explored. Unfortunately,with other test cases, the developer might have to implementit completely.After this step, we assume that the test cases are correctly When("Try to Survey the application for user-controllable inputs")public void trysurvey(){// Try one of the following techniques ://1. Use a spidering tool to follow and recordall links and analyze the web pages to findentry points. Make special note of anylinks that include parameters in the URL.//2. Use a proxy tool to record all user inputentry points visited during a manualtraversal of the web application.//3. Use a browser to manually explore thewebsite and analyze how it is constructed.Many browsers’ plugins are available tofacilitate the analysis or automate thediscovery.String url ="";ZAProxyScanner j = newZAProxyScanner("localhost", 8080, "zap");j.spider(url);}@Then("Assert the success of Survey theapplication for user-controllable inputs")public void asssurvey(){// Assert one of the following indications :// -A list of URLs, with their correspondingparameters (POST, GET, COOKIE, etc.) iscreated by the attacker.ZAProxyScanner j = newZAProxyScanner("localhost", 8080, "zap");int x =j.getSpiderResults(j.getLastSpiderScanId()).size();Assert.assertTrue(x>0);}}
Figure 10. The procedure related to the When and Then sections of Figure9 developed with assertions in Then sections as stated inSection III: a Then section of a test case
T C ( b ) returns theverdict ” P ass st ” if an attack step st has been successfullyapplied on the AU T and ”
F ail st ” otherwise; when T C ( b ) returns an unexpected exception or fault, we get the verdict” Inconclusive st ”. Step 9: Test Case Execution
The experimentation of the
AU T with the test suite
T S iscarried out in this step. A test case
T C ( b ) of T S , which aimsat testing whether the
AU T is vulnerable to an attack step st leads to a local verdict denoted Verdict(
T C ( b ) || AU T ) : Definition 5 (Local Test Verdicts)
Let
AU T be an appli-cation under test, b = c p ( st, sp ) ∈ BADStep ( T f ) , and T C ( b ) ∈ T S be a test case.
Verdict(
T C ( b ) || AU T ) = • P ass st , which means AU T is vulnerable to the attackstep st ; • F ail st , which means AU T does not appear to bevulnerable to the attack step st ; • Inconclusive st , which means that various problemsoccurred while the test case execution. We finally define the final verdicts of the security test-ing stage with regard to the ADTree T f . These ver-dicts are given with the predicates Vulnerable( T f ) and Inconclusive( T f ) returning boolean values. The interme-diate predicate Vulnerable( b ) is also defined on a BAD-Step b to evaluate a substitution σ : BADStep ( s ) →{ true, f alse } on an attack-defense scenario s . A scenario s holds if the evaluation of the substitution σ to s , i.e.,replacing every BADStep term b with the evaluation of Vulnerable( b ) , returns true. The predicate Vulnerable( s ) expresses whether an attack-defense scenario of T f holds.In that case, the threat modelled by T f can be achieved on AU T . This is defined with the predicate
Vulnerable( T f ) : Definition 6 (Security Testing Verdicts)
Let
AU T be anapplication under test, T f be an ADTree, s ∈ SC ( T f ) and b = c p ( st, sp ) ∈ BADStep ( s ) . Vulnerable( b ) = def true if Verdict(
T C ( b ) || AU T ) =
P ass st ; otherwise, Vulnerable( b ) = def f alse ; Vulnerable( s ) = def true if eval ( sσ ) returnstrue, with σ : BADStep ( s ) → { true, f alse } the substitution { b → Vulnerable( b ) , . . . , b n → Vulnerable( b n ) } ; otherwise, Vulnerable( s ) = def f alse ; Inconclusive( s ) = def true if ∃ b ∈ BADStep( s ) : Verdict(
T C ( b ) || AU T ) =
Inconclusive st ; other-wise, Inconclusive( s ) = def f alse . Vulnerable( T f ) = def true if ∃ s ∈ SC ( T f ) :Vulnerable( s ) = true ; otherwise, Vulnerable( T f ) = def f alse ; Inconclusive( T f ) = def true if ∃ s ∈ SC ( T f ) , Inconclusive( s ) = true ; otherwise, Inconclusive( T f )= def f alse .D. Security Pattern Verification Our approach also aims at checking whether securitypatterns are correctly implemented in the application. Thesecurity testing stage is indeed insufficient because thenon-detection of vulnerability in the
AU T does not implythat a security pattern is correctly implemented. As statedearlier, we propose to generate LTL properties that expressthe behavioural properties of a security pattern. Then, theseare used to check whether they hold on the
AU T traces.The originality of our approach resides in the fact that wedo not ask developers for writing formal properties, wepropose to generate them by means of KB.
Steps 5 and 6: UML Sequence Diagram Extraction andModification
After the threat modelling stage, this step starts by ex-tracting from KB a list of generic UML sequence diagramsfor each security pattern in SP ( T f ) . These diagrams showhow a security pattern should behave once it is correctlyimplemented, i.e., how objects interact in time. We now igure 11. UML sequence diag. of the pattern Intercepting Validator suppose that the developer implements every security patternin the application. At the same time, he/she may adapt thebehaviours illustrated in the UML sequence diagrams. In thiscase, we assume that the diagrams are updated accordingly.Figure 11 illustrates an example of UML sequencediagram for the security pattern “Intercepting Validator”.The diagram shows the interactions between an externalClient, the pattern and the application, but also theinteractions among the objects of the pattern. Here,the Intercepting Validator Object is called to validaterequests. These are given to another object ValidatorURL,which filters the request with regard to the URL type.If the request is valid, it is processed by the application(Controller object), otherwise an error is returned to theclient side. Step 7: Security Pattern LTL Property Generation
This step automatically generates LTL properties fromUML sequence diagrams by detecting the cause-effect re-lations among method calls and expressing them in LTL.Initially, we took inspiration in the method of Muramet al. [38], which transforms activity diagrams into LTLproperties. Unfortunately, security patterns are not describedwith activity diagrams, but with sequence diagrams. Thisis why we devised 20 conversion schemas allowing totransform UML sequence diagram constructs, composed oftwo or three successive actions, into UML activity diagrams.Table I gives 6 of these schemas. Intuitively, these translatetwo consecutive method calls found in a sequence diagramby activity diagrams composed of action states. The otherschemas (not all given in Table I) are the results of slightadaptations of the five first ones, where the number ofobjects or the guards have been modified. For instance, thelast schema of Table I is an adaptation of the first one, whichdepicts interactions between two objects instead of three.Then, we propose 20 rules to translate these activitydiagrams into LTL properties. The last column of Table Ilists 6 of these rules. Some of these rules are based on thoseproposed by Muram et al, but we devised other rules relatedto our own activity diagrams, which are more detailed. Forinstance, we take into account the condition state in the second rule to produce more precise LTL properties.At the end of this step, we consider having a set of LTLproperties P ( sp ) for every security pattern sp ∈ SP ( T f ) .Although the LTL properties of P ( sp ) do not necessarilycover all the possible behavioural properties of a securitypattern sp , this process offers the advantages of not askingdevelopers for writing LTL formula or to instantiate genericLTL properties to match the application model or code. Table IUML
SEQUENCE DIAGRAMS TO
LTL
PROPERTIES TRANSFORMATIONRULES .Sequence Diag. Activity Diag. LTL properties (cid:3) ( B. −→ ♦ C. (cid:3) ( B. −→ ♦ B. xor ( ¬ B. −→ ♦ C. (cid:3) ( B. −→ ( ♦ B. and ( ♦ C. (cid:3) ( B. xorC. −→ ♦ B. (cid:3) ( B. andC. −→ ♦ B. (cid:3) ( B. −→ ♦ B. From the example of UML sequence diagram given inFigure 11, 4 LTL properties are generated. Table II liststhem. These capture the cause-effect relations of every pairof methods found in the UML sequence diagram.
Step 10: Security Pattern Verification
As stated earlier, we consider that the
AU T is instru-mented with a debugger or similar tool to collect the methodscalled in the application while the execution of the test casesof
T S . After the test case execution, we hence have a setof method call traces denoted
T races ( AU T ) . able IILTL PROPERTIES FOR THE PATTERN I NTERCEPTING V ALIDATOR . p (cid:3) ( SecureBaseAction.invokes −→ ♦ InterceptingV alidator.validatep (cid:3) ( InterceptingV alidator.validate −→ ♦ V alidatorURL.create ) p (cid:3) ( V alidatorURL.create −→ ♦ V alidatorURL.validate ) p (cid:3) (( V alidatorURL.validate −→ ♦ Controller.call ) xor ( ¬ V alidatorURL.validate −→ ♦ SecureBaseAction.error )) Table IIIT
EST VERDICT S UMMARY AND R ECOMMENDATIONS . Vulnera-ble( T f ) Unsat b ( SP ( T f )) Incon ( T f ) Corrective actionsFalse False False No issue detectedTrue False False At least one scenario is successfully applied on
AUT .Fix the pattern implementation. Or the chosen patternsare inconvenient.False True False Some pattern behavioural properties do not hold. Checkthe pattern implementations with the UML seq. diag. Oranother pattern conceals the behaviour of the former.True True False The chosen security patterns are useless or incorrectlyimplemented. Review the ADTree, fix
AUT .T/F T/F True The test case execution crashed or returned unexpectedexceptions. Check the Test architecture and the test casecodes.
A model-checking tool is now used to detect the non-satisfiability of LTL properties on
T races ( AU T ) . Given asecurity pattern sp , the predicate U nsat b ( sp ) formulates thenon-satisfiability of a LTL property of sp in T races ( AU T ) .The final predicate Unsat b ( SP ( T f )) expresses whether allthe LTL properties of the security patterns given in T f hold. Definition 7 (Security Pattern Verification Verdicts)
Let
AU T be an application under test, T f be an ADTree, and sp ∈ SP ( T f ) be a security pattern. Unsat b ( sp ) = def true if ∃ p ∈ P ( sp ) , ∃ t ∈ T races ( AU T ) , t (cid:50) p ; otherwise, Unsat b ( sp ) = def f alse ; Unsat b ( SP ( T f )) = def true if ∃ sp ∈ SP ( T f ) , Unsat b ( sp ) = true ; otherwise, Unsat b ( SP ( T f )) = def f alse ; Table III informally summarises the meaning of some testverdicts and some corrections that may be followed in caseof failure. V. I
MPLEMENTATION
Our approach is implemented in Java and is releasedas open source in [5]. At the moment, the
AU T must bea Web application developed with any kind of languageprovided that the
AU T may be instrumented to collectmethod call traces. The prototype tool consists of threemain parts. The first one comes down to a set of commandlines allowing to build the knowledge base KB. The dataintegration is mostly performed by calling the tool Talend,which is specialised into the extract, transform, load (ETL)procedure. An example of knowledge base is available in[5]. A second software program semi-automatically generatesADTrees and GWT test cases. ADTrees are stored intoXML files, and may be edited with
ADTool [3]. GWT testcases are written in Java with the Cucumber framework,which supports the GWT test case pattern. These test casescan be imported as an Eclipse project to be completedand executed. This software program also provides UMLsequence diagrams stored in JSON files, which have to bemodified to match the
AU T functioning. LTL properties areextracted from these UML sequence diagrams.The last part of the tool is a tester that experiments Webapplications with test cases and returns test verdicts. Whilethe test case execution, we collect log files including methodcall traces. The LTL property verification on these traces ismanually done by these steps: 1) the log files usually have tobe manually filtered to remove necessary events 2) the toolTexada [39] is invoked to check the satisfiability of everyLTL property on the log files. This tool takes as inputs alog file, a LTL property composed of variables and a list ofevents specifying variables in the formula to be interpretedas a constant event. Texada returns the number of times thata property holds in a log file. We have chosen the Texadatool as it offers good performance and can be used on largetrace sets. But other tools could also be used, e.g., the LTLchecker plugin of the ProM framework [40] or Eagle [41].VI. P
RELIMINARY E VALUATION
First and foremost, it is worth noting that we carried outin [24] a first evaluation of the difficulty of using securitypatterns for designing secure applications. This evaluationwas conducted on 24 participants and allowed us to concludethat the Threat modelling stage of our approach makes thesecurity pattern choice and the test case development easierand makes users more effective on security testing. In thispaper, we propose another evaluation of the security testingand security pattern testing parts of our approach. Thisevaluation addresses the following research questions: • Q1: Can the generated test cases detect security issues? • Q2: Can the generated LTL properties detect incorrectimplementation of patterns? • Q3: How long does it take to discover errors (Perfor-mance)?
A. Empirical Setup
We asked ten teams of two students to implement Webapplications written in PHP as a part of their courses.They could choose to develop either a blog, or a todolist application or a RSS reader. Among the requirements,the Web applications had to manage several kinds of users(visitors, administrators, etc.), to be implemented in object-oriented programming, to use the PHP Data Objects (PDO)extension to prevent SQL injections, and to validate all theuser inputs. As a solution to filter inputs, we proposed themo apply the security pattern Intercepting Validator. But itsuse was not mandatory.Then, we applied our tool on these 10 Web applicationsin order to: • test whether these are vulnerable to both SQL and XSSinjections (attacks CAPEC-66 and CAPEC-244). Withour tool, we generated the ADTrees of Figures 6 and 7,along with GWT test cases. We completed them to callthe penetration testing tool ZAProxy (as illustrated inFigure 10). All the applications were vulnerable to thesteps “Explore” of the ADTrees (application survey),therefore we also experimented them with the test casesrelated to the steps “Experiment” (attempt SQL or XSSinjections); • test whether the behaviours of the pattern InterceptingValidator are correctly implemented in the 10 Webapplications. We took the UML sequence diagram ofFigure 11 and adapted it ten times to match the contextof every application. Most of the time, we had to changethe class or method names, and to add as many validatorclasses as there are in the application codes. When aclass or method of the pattern was not implemented, weleaved the generic name in the UML diagram. Then, wegenerated LTL properties to verify whether they holdin the application traces. B. Q1: Can the generated test cases detect security issues?Procedure: to study Q1, we experimented the 10 appli-cations with the 4 GWT test cases of the two Steps Exploreand Experiment of the attacks CAPEC-66 and CAPEC-244.As these test cases call a penetration testing tool, whichmay report false positives, we manually checked the reportederrors to only keep the real ones. We also inspected theapplication codes to examine the security flaw causes andto finally check whether the applications are vulnerable.
Results:
Table IV provides the number of tests for bothattacks (columns 2 and 3), the number of security errorsdetected by these tests (columns 4 and 5) and executiontimes in seconds (column 6). As a penetration testing tool iscalled, a large amount of malicious HTTP requests are sentto the applications in order to test them. The test numberoften depends on the application structure (e.g., number ofclasses, of called libraries, of URLs, etc.) but also on thenumber of forms available in an application.Table IV shows that errors are detected in half of theapplications. After inspection, we observed that severalinputs are not filtered in App. 1, 5 and 6. On the contrary,for App. 3 and 7 all the inputs are checked. However,the validation process is itself incorrectly performed ortoo straightforward. For example, in App. 3 the validationcomes down to checking that the input exists, which isfar from sufficient to block malicious code injections. Forthe other applications, we observed that they all include acorrect validation process, which is called after every client request. After the code inspection and the testing process, weconclude that they seem to be protected against both XMLand SQL injections. These experiments tend to confirmthat our approach can be used to test the security of Webapplications.
Table IVR
ESULTS OF THE SECURITY TESTING STAGE : NUMBER OF REQUESTSPERFORMED , NUMBER OF DETECTED SECURITY ERRORS , ANDEXECUTION TIMES IN SECOND
App.
C. Q2: Can the generated LTL properties detect incorrectimplementation of patterns?Procedure:
To investigate Q2, the PHP applications wereinstrumented with the debugger Xdebug, and we collectedlogs composed of method call traces while the test caseexecution. Then, we used the tool Texada to check whetherevery LTL property holds in these method call traces. Whenthe pattern is strictly implemented as it is described in theUML sequence diagram of Figure 11 (1 class Validator), 4LTL properties are generated, as in Table I. However, thenumber of LTL properties may differ from one applicationto the other, with regard to the number of classes used toimplement the security pattern. When there are more than 4LTL properties for an application, the additional ones capturethe call of supplementary Validator classes and only differfrom the properties of Table I by the modification of thevariable ValidatorURL. To keep our results comparable fromone application to another, we denote with the notation p i the set of properties related to the property p i in I.Furthermore, both authors independently checked the val-idation part in every applications to assess how the securitypattern is implemented in order to ensure that a propertyviolation implies that a security pattern behaviour is notcorrectly implemented. Results:
Table V lists in columns 2-5 the violations ofthe properties derived from those given in Table I for the 10applications. These results firstly show that our approachdetects that the security pattern Intercepting Validator isnever correctly implemented. The pattern seems to be almostimplemented in App. 2 because only p does not holdhere. An inspection of the application code confirms thatthe pattern structure is correctly implemented as well asmost of its method call sequences. But we observed thathe application does not always return an error to the userwhen some inputs are not validated. This contradicts one ofthe pattern purposes.App. 3, 4, 7-10 include some sorts of input filteringprocesses at least defined in one class. But, these do notrespect the security pattern behaviours. Most of the time,we observed that the validation process is implemented ina single class instead of having an Intercepting Validatorcalling other Validator classes. This misbehaviour is detectedby the violations of the properties p and p . Besides,we observed that the input validation is not systematicallyperformed in App. 1, 5 and 6. This is detected by ourtool with the violation of p . As a consequence, it is notsurprising to observe that these applications are vulnerableto malicious injections. We also observed that when App.5 validates the inputs, it does not define the validationlogic in a class. The fact that the security pattern is notinvoked is detected by the violation of p . But, this propertyviolation does not reveal that there is another validationprocess implemented.In summary, our application code inspections confirmedthe results of Table V. In addition to assessing whetherthe security pattern behaviours are correctly implemented,we observed that our approach may also help learn moreinformation about the validation process, without inspectingthe code. For instance, the properties based on p checkwhether a validation method defined in a class is calledevery time a client request is received. The properties basedon p give information about the error management. Theirviolations express that users are not always warned wheninvalid inputs are provided to the applications. Table VR
ESULTS OF THE SECURITY PATTERN TESTING STAGE : VIOLATION OFTHE
LTL
PROPERTIES AND EXECUTION TIMES IN SECOND
App. p p p p Time(min)1 X X 4,022 X 51,153 X X 19,124 X X 29,345 X X X X 6,56 X X X X 14,407 X X 24,778 X X X 7,249 X X X 5,5610 X X 67,03
D. Q3: How long does it take to discover errors (Perfor-mance)?Procedure:
We measured the time consumed by the toolto carry out security testing and security pattern verificationfor the 10 applications. Execution times are given in TablesIV and V. Furthermore, we also measured the number ofLTL properties that are generated for 11 security patterns,which are often used with Web applications, as the LTLproperty number influences execution times.
Figure 12. Execution times of the security testing stage for the tenapplications
Results:
The plot chart of Figure 12 shows that securitytesting requires less than 2 minutes for 7 applications inde-pendently on the number of tests, whereas it requires morethan 15 minutes for the 3 others. The security testing stagedepends on several external factors, which makes it difficultto draw consistent conclusions. It firstly depends on the testcase implementation; in our evaluation, we choose to calla penetration testing tool, therefore, execution times mostlydepend on it. Another factor is the application structure (nbof classes, calls of external URLS, etc.). Therefore, we canonly conclude here is that execution times are lower than25 minutes, which remains reasonable with regard to thenumber of requests sent to applications.The time required to detect property violations in methodcall traces is given in Column 6 of Table V. Executiontimes vary here between 4 and 67 minutes according tothe number of traces collected from the application and thenumber of generated LTL properties. For example, for App.1O, 17237 security tests have been executed, and 17237traces of about 30 events have been stored in several logfiles. Furthermore, 7 LTL properties have been generatedfor this applications. These results, and particularly the sizeof the trace set, explain the time required to check whetherthe LTL properties hold. In general terms, we consider thatexecution times remain reasonable with regard to the traceset sizes of the applications.Table VI finally shows the number of LTL propertiesgenerated from generic UML properties (without adaptingthem to application contexts) for 11 security patterns whosedescriptions include UML sequence diagrams. For thesepatterns, the property number is lower or equal than 13. Forevery pattern, the property number is in a range that seemsreasonably well supported by model checkers. However,if several security patterns have to be tested, the propertynumber might quickly exceed the model-checker limits. Thisis we have chosen in our approach to check the satisfiabilityof each LTL property, one after the other, on method calltraces. able VILTL
PROPERTY GENERATION FOR SOME SECURITY PATTERNS
Security pattern
E. Threat to Validity
This preliminary experimental evaluation is applied on10 Web applications, and not on other kinds of softwareor systems. This is a threat to external validity, and thisis why we avoid drawing any general conclusion. But, webelieve that this threat is somewhat mitigated by our choiceof application, as the Web application context is a rich fieldin great demand in the software industry. Web applicationsalso expose a lot of well-known vulnerabilities, which helpsin the experiment set-up. In addition, the numbers of secu-rity patterns considered in the evaluation were insufficient.Hence, it is possible that our method is not applicable toall security patterns. In particular, we assume that genericUML sequence diagrams are provided in the security patterndescriptions. This is the case for the patterns available inthe catalogue of Yskout et al. [35], but not for all thepatterns listed in [8]. To generalise the approach, we alsoneed to consider more general patterns and employ large-scale examples.The evaluation is based on the work of students, but thispublic is sometimes considered as a bias in evaluations.Students are usually not yet meticulous on the securitysolution implementation, and as we wished to experimentvulnerable applications to check that our approach can detectsecurity flaws, we consider that applications developed bystudents meet our needs.A threat to internal validity is related to the test case devel-opment. Our approach aims at guiding developers in the testcase writing and security pattern choice. In the evaluation,we chose to complete test cases with the call of a penetrationtesting tool. The testing results would be different (better orworse) with other test cases. Significant advances have beenmade in these tools, which are more and more employedin the industry. Therefore, we believe that their use and thetest cases considered in the experiments are close to real usecases. In the same way, we manually updated UML sequencediagrams to generate LTL properties that correspond to theapplication contexts. But, it is possible that we inadvertentlymade some mistakes, which led to false positives. To avoid this bias, we manually checked the correctness of the resultsby replaying the counterexamples returned by the model-checker and by inspecting the application codes.VII. C
ONCLUSION
Securing software requires that developers acquire a lotof expertise in various stages of software engineering, e.g.,in security design, or in testing. To help them in thesetasks, we have proposed an approach based on the notion ofknowledge base, which helps developers in the implemen-tation of secure applications through steps covering threatmodelling, security pattern choice, security testing and theverification of security pattern behavioural properties. Thispaper proposes two main contributions. It assists developersin the writing of concrete security test cases and ADTrees.It also checks whether security patterns properties are metin application traces by automatically generating LTL prop-erties from the UML sequence diagrams that express thebehaviours of patterns. Therefore, the approach does notrequire developers to have skills in (formal) modelling orin formal methods. We have implemented this approach ina tool prototype [5]. We conducted an evaluation of ourapproach on ten Web applications, which suggests that itcan be used in practice.Future work should complement the evaluation to confirmthat the approach can be applied on more kinds of applica-tions. We also mentioned that security pattern descriptionsdo not all include UML sequence diagrams, which are yetmandatory by our approach. We will try to solve this lackof documentation by investigating whether security patternbehavioural properties could be expressed differently, e.g.,with annotations added inside application codes. In addition,we intend to consider how our ADTree generation couldsupport the teaching of security testing and security bydesign. R
EFERENCES [1] L. Regainia and S. Salva, “A practical way of testing securitypatterns,” in
Thirteenth International Conference on SoftwareEngineering Advances (ICSEA’18) , Nice, France, Oct. 2018,pp. 1–7.[2] E. Rodriguez, “Security Design Patterns,” in ,2003.[3] B. Kordy, S. Mauw, S. Radomirovi´c, and P. Schweitzer,“Attack–defense trees,”
Journal of Logic and Computation ,pp. 1–38, 2012.[4] T. Kobashi, M. Yoshizawa, H. Washizaki, Y. Fukazawa,N. Yoshioka, T. Okubo, and H. Kaiya, “Tesem: A tool forverifying security design pattern applications by model test-ing,” in , April 2015, pp.1–8.5] L. Regainia and S. Salva. (2019) Security patternclassification, companion site. (Date last accessed march2019). [Online]. Available: http://regainia.com/research/companion.html[6] J. Yoder, J. Yoder, J. Barcalow, and J. Barcalow, “Architec-tural patterns for enabling application security,”
Proceedingsof PLoP 1997 , vol. 51, p. 31, 1998.[7] M. Schumacher,
Security Engineering with Patterns: Origins,Theoretical Models, and New Applications . Secaucus, NJ,USA: Springer-Verlag New York, Inc., 2003.[8] R. Slavin and J. Niu. (2017) Security patterns repository.[Online]. Available: http://sefm.cs.utsa.edu/repository/[9] K. Yskout, R. Scandariato, and W. Joosen, “Do securitypatterns really help designers?” in
Proceedings of the 37thInternational Conference on Software Engineering - Volume1 , ser. ICSE ’15. Piscataway, NJ, USA: IEEE Press, 2015,pp. 292–302.[10] K. Yskout, T. Heyman, R. Scandariato, and W. Joosen, “Asystem of security patterns,” 2006.[11] R. Jhawar, B. Kordy, S. Mauw, S. Radomirovi´c, andR. Trujillo-Rasua, “Attack trees with sequential conjunc-tion,” in
IFIP International Information Security Conference .Springer, 2015, pp. 339–353.[12] Mitre corporation. (2019) Common attack patternenumeration and classification, url:https://capec.mitre.org/.(Date last accessed march 2019). [Online]. Available:https://capec.mitre.org/[13] P. Torr, “Demystifying the threat modeling process,”
IEEESecurity Privacy , vol. 3, no. 5, pp. 66–70, Sept 2005.[14] M. Howard and D. LeBlanc,
Writing Secure Code , M. Press,Ed., 2003.[15] I. Schieferdecker, J. Grossmann, and M. A. Schneider,“Model-based security testing,” in
Proceedings 7th Workshopon Model-Based Testing, MBT 2012, Tallinn, Estonia, 25March 2012. , 2012, pp. 1–12.[16] D. Xu, M. Tu, M. Sanford, L. Thomas, D. Woodraska,and W. Xu, “Automated security test generation with formalthreat models,”
IEEE Transactions on Dependable and SecureComputing , vol. 9, no. 4, pp. 526–540, July 2012.[17] J. Bozic, D. E. Simos, and F. Wotawa, “Attack pattern-basedcombinatorial testing,” in
Proceedings of the 9th InternationalWorkshop on Automation of Software Test , ser. AST 2014.New York, NY, USA: ACM, 2014, pp. 1–7.[18] A. Morais, E. Martins, A. Cavalli, and W. Jimenez, “Se-curity protocol testing using attack trees,” in , vol. 2, Aug 2009, pp. 690–697.[19] A. Marback, H. Do, K. He, S. Kondamarri, and D. Xu,“Security test generation using threat trees,” in , May 2009, pp.62–69. [20] O. El Ariss and D. Xu, “Modeling security attacks withstatecharts,” in
Proceedings of the Joint ACM SIGSOFT Con-ference – QoSA and ACM SIGSOFT Symposium – ISARCSon Quality of Software Architectures – QoSA and ArchitectingCritical Systems – ISARCS , ser. QoSA-ISARCS ’11. NewYork, NY, USA: ACM, 2011, pp. 123–132.[21] A. Marback, H. Do, K. He, S. Kondamarri, and D. Xu, “Athreat model-based approach to security testing,”
Softw. Pract.Exper. , vol. 43, no. 2, pp. 241–258, Feb. 2013.[22] N. Shahmehri et al. , “An advanced approach for modelingand detecting software vulnerabilities,”
Inf. Softw. Technol. ,vol. 54, no. 9, pp. 997–1013, 2012.[23] S. Salva and L. Regainia, “Using data integration to helpdesign more secure applications,” in
Proceedings of the 12thInternational Conference on Risks and Security of Internetand Systems . Dinard, France: Springer-Verlag, Aug. 2017.[24] ——, “Using data integration for security testing,” in
Pro-ceedings 29th International Conference, ICTSS 2017 , St.Petersburg, Russia, Oct. 2017, pp. 178–194.[25] ——, “An approach for guiding developers in the choiceof security solutions and in the generation of concretetest cases,”
Software Quality Journal , vol. 27, no. 2,pp. 675–701, January 2019. [Online]. Available: https://hal-clermont-univ.archives-ouvertes.fr/hal-02019145[26] J. Dong, T. Peng, and Y. Zhao, “Automated verification ofsecurity pattern compositions,”
Inf. Softw. Technol. , vol. 52,no. 3, pp. 274–295, Mar. 2010.[27] B. Hamid, C. Percebois, and D. Gouteux, “A methodology forintegration of patterns with validation purpose,” in
Proceed-ings of the 17th European Conference on Pattern Languagesof Programs , ser. EuroPLoP ’12. New York, NY, USA:ACM, 2012, pp. 8:1–8:14.[28] M. Yoshizawa et al. , “Verifying implementation of securitydesign patterns using a test template,” in ,Sept. 2014, pp. 178–183.[29] L. Regaigna, C. Bouhours, and S. Salva, “A systematicapproach to assist designers in security pattern integration,”in
Second International Conference on Advances and Trendsin Software Engineering (SOFTENG 2016) , Lisbon, Portugal,Feb. 2016.[30] J. H. Saltzer and M. D. Schroeder, “The protection of in-formation in computer systems,”
Proceedings of the IEEE ,vol. 63, no. 9, pp. 1278–1308, 1975.[31] J. Viega and G. McGraw,
Building Secure Software: How toAvoid Security Problems the Right Way, Portable Documents .Pearson Education, 2001.[32] J. Scambray and E. Olson,
Improving Web Application Secu-rity , 2003.[33] V. Dialani, S. Miles, L. Moreau, D. De Roure, and M. Luck,“Transparent fault tolerance for web services based architec-tures,” in
Euro-Par 2002 Parallel Processing . Springer, 2002,pp. 889–898.34] J. Meier, “Web application security engineering,”
Security &Privacy, IEEE , vol. 4, no. 4, pp. 16–24, 2006.[35] K. Yskout, R. Scandariato, and W. Joosen. Securitypattern catalog. (Date last accessed march 2019). [Online].Available: https://people.cs.kuleuven.be/ ∼ Proceedings 11thInternational Workshop on Formal Engineering approachesto Software Components and Architectures, FESCA 2014,Grenoble, France, 12th April 2014. , 2014, pp. 93–107.[39] C. Lemieux, D. Park, and I. Beschastnikh, “General ltl spec-ification mining (t),” in , Nov2015, pp. 81–92.[40] F. M. Maggi, M. Westergaard, M. Montali, and W. M. P.van der Aalst, “Runtime verification of ltl-based declarativeprocess models,” in
Runtime Verification , S. Khurshid andK. Sen, Eds. Berlin, Heidelberg: Springer Berlin Heidelberg,2012, pp. 131–146.[41] H. Barringer, A. Goldberg, K. Havelund, and K. Sen, “Pro-gram monitoring with ltl in eagle,” in18th InternationalParallel and Distributed Processing Symposium, 2004. Pro-ceedings.