Gustavo González-Granadillo

José Rubio-Hernán

Joaquin Garcia-Alfaro

Hervé Debar

Considering internal vulnerabilities and the attacker's knowledge to model the impact of cyber events as geometrical prisms

We propose a model to represent graphically the information system and the impact of cyber events (e.g., attacks, countermeasures) as a prismatic instance of n-sides. The approach considers information about all entities composing an information system (e.g., users, IP addresses, communication protocols, physical and logical resources, etc.), as well as information about the attacker's knowledge, motivation and capabilities. The base of the prism is represented as an n-side polygon (e.g., triangle, square, pentagon, etc.) which depicts the internal information of the system, whereas the height of the prism is represented as a single axis which depicts the external information of the system. We propose geometrical operations to determine the impact of cyber security events (i.e., area, volume, event coverage, residual risk, and potential collateral damages). A case study is proposed at the end of the paper to show the applicability of the model in a scenario with multiple attacks.

I. INTRODUCTION

Computing the economic impact of cyber security events is an open issue in the ICT domain. Specialized information security organizations e.g., Computer Emergency Response Team (CERT) [START_REF]Common Cyber Attacks: Reducing the Impact[END_REF], Ponemon Institute [2], Verizon [3], etc., perform annual reports on such estimations based on realworld experiences and in-depth interviews with thousands of security professionals around the world. The research is designated to help organizations make the most cost-effective decisions possible in minimizing the greatest risk to their organizations.

A range of difficult issues confront the assessment of the impact of cyber events. (i) Accuracy, the risk of potential threats cannot be accurately described unless their consequences are properly identified and quantified. (ii) Collateral damage, while impact models provide an assessment of the risk and estimation of the economic impact over the target system, most of them fail at considering propagation and side effects in their evaluations. (iii) contextual criteria, impact models generally evaluate the impact on assets, neglecting the analysis of impacts and resulting responses with respect to time, geographic space, and affected populations [START_REF] Roberts | The macroeconomic impacts of the 9/11 attack: Evidence from real-time forecasting[END_REF].

Previous researches propose simulation models [START_REF] Dini | On simulative analysis of attack impact in wireless sensor networks[END_REF], [START_REF] Dini | A simulation tool for evaluating attack impact in cyber physical systems[END_REF] and geometrical models [START_REF] Gonzalez-Granadillo | Selecting optimal countermeasures for attacks against critical systems using the attack volume model and the rori index[END_REF], [START_REF] Gonzalez-Granadillo | Using a 3D geometrical model to improve accuracy in the evaluation and selection of countermeasures against complex cyber attacks[END_REF] to estimate and analyze the impact of cyber events. However, most of the proposed solutions are limited to three dimensions, making it difficult to provide a graphical representation of geometrical instances in four or more dimensions. Furthermore, most of the solutions proposed to estimate the impact of cyber security events do not consider information from the attacker's side (e.g., knowledge, motivation, capabilities, etc.). A wide variety of adversary models are proposed in the literature [START_REF] Mardziel | Modeling, Quantifying, and Limiting Adversary Knowledge[END_REF]- [START_REF] Libicki | Brandishing Cyberattack Capabilities[END_REF]. The knowledge of such adversaries can be either prior to the attack (a priori) or after the attack is executed (a posteriori).

In this paper, we propose a geometrical model to calculate the impact of cyber events as n-sided prisms. The approach considers information about all entities composing an information system (e.g., users, IP addresses, communication protocols, physical and logical resources, etc.), as well as contextual information (e.g., temporal, spacial, historical conditions), and the attacker's information (e.g., knowledge, motivation, skills, etc.), to plot cyber attacks and countermeasures in a geometrical system. The ultimate goal of our model is to help organizations make the most cost-effective decisions in minimizing the risk of the studied cyber events.

In addition, we are able to perform geometrical operations (e.g., area, volume) over the prismatic instances, which allows us to compare the impact of multiple cyber events. Such comparison provides the means to compute the coverage of events with respect to the system, the residual risk, and potential collateral damage that may occur out of the implementation of the security countermeasures.

The contributions on this paper are summarized as follows:

• A qualitative and quantitative assessment of the impact of cyber events (e.g., attacks, countermeasures) based on the target's information and the attacker's knowledge. • A model that projects the impact of security events in an n-sided geometrical system. The instances resulting from the model are regular or irregular prisms (e.g., triangular prisms, quadrilateral prisms, pentagonal prisms, etc). • A process that performs geometrical operations to calculate the size of the prismatic instances (i.e., area, volume), which allows us to compare the impact of multiple cyber events. • A process that computes the coverage of events (COV), the residual risk (RR), and potential collateral damage (PCD) that may occur out of the implementation of the security countermeasures.

• The deployment of our model in a case study with multiple security events over several dimensions. The rest of the paper is structured as follows: Section II introduces the cyber event information required to build the instances and analyze their impact. Section III presents our proposed prismatic model and discusses about its construction. Section IV details the main prismatic instances that result from our model. Section V details the impact measurement of the different geometrical instances. Section VI presents a case study with multiple events (e.g., attacks and countermeasures) to illustrate the applicability of our approach. Related work are presented in Section VII. Finally, conclusions are presented in Section VIII.

II. CYBER EVENT INFORMATION

For the scope of this article, we consider sets of individual actions performed either by the attacker (e.g., malicious actions executed in order to exploit a system's vulnerability) or by the target system (benign actions executed as a response to an adversary) as a cyber security event.

Internal and external information are required to analyze the impact of a cyber security event. Internal information represents all physical and logical data from the local network or from the information system, such as assets, vulnerabilities, defense mechanisms, etc. External information is related to the attacker's knowledge, motivation, and capabilities to exploit a given vulnerability from the target system. This section details both the information from the target and the attacker's side.

A. Information from the target's side

For the scope of this article, we consider a set of elements with rules and data in common as an entity. An entity represents a group of people, objects, activities, or concepts that affects directly or indirectly the execution of a given cyber security event. Considering the characteristics of access control models [START_REF] Kalam | Organization based access control[END_REF], [START_REF] Li | Security analysis in role-based access control[END_REF], we identified the following entities: U a, Re, Ch , where U a is the User Account associated to a given status in the system (e.g., system administrator, standard user, guest, internal user, nobody); Re corresponds to the system's Resources e.g., physical components (host, server, printer) or logical components (files, records, database) of limited availability within a computer system; and Ch are the Channels, which represents all actions needed for a user to have access to a resource (e.g., protocols, IP addresses, port numbers).

In addition, we consider the notion of contexts proposed in the Organization based Access Control (OrBAC) model [START_REF] Cuppens | Modeling contextual security policies[END_REF], [START_REF] Cuppens | Modelling contexts in the or-bac model[END_REF], such as temporal conditions. (e.g., granted privileges only during working hours), spatial conditions (e.g., granted privileges when connected within the company premises), and historical conditions (e.g., granted privileges only if previous instances of the same equivalent events were already conducted). For instance, in order to access a web-server (resource) of a given organization, an external user (user account) connects remotely (spatial condition) to the system by providing his/her login and password (channel) at a given date (temporal condition).

Information security properties (e.g., confidentiality, integrity, availability) are also a key aspect in the analysis of a cyber security event. An event can be associated to a particular issue compromising the system's confidentiality (e.g., unauthorized access to sensitive information, disclosure resources, etc), integrity (e.g., unauthorized change of the data contents or properties, etc), or availability (e.g., unavailable resources, denial of service, etc). Every organization must define their own entities based on their historical data, expert knowledge and assessments they perform on their information systems.

B. Information from the attacker's side

According to Krautsevich et al. [START_REF] Krautsevich | Towards modelling adaptive attacker's behaviour[END_REF], adversaries can be either (i) omniscient, when they know all vulnerabilities and all possible patches of the system; (ii) deterministic, when they have a belief knowledge of the system and they choose the best possible action to break into the system; or (iii) adaptive, when they adapt the strategy to complete the attack, using updated knowledge about the system . We divide the information from the attacker's side into two main categories: a priori and a posteriori. The remaining of this section discusses both categories.

1) A priori knowledge: A set of information about the system, possessed by the attacker before exploiting a given vulnerability on the system. If the attacker has a priori knowledge about the operation of the entire system, he/she would be able to inflict a much severe attack.

We distinguish two types of a priori knowledge: the knowledge about the information system, and the knowledge about the attack. The former considers the understandings that the attacker has about the system, whereas the latter considers the skills and experience of the attacker in executing a given attack. a) About the information system: In this category, we consider the known vulnerabilities of the information system that can be exploited by an attacker to access the system, and the impact in terms of confidentiality, integrity and availability. Following the common vulnerability system scoring method (CVSS) [START_REF] Mell | A complete guide to the common vulnerability scoring system version 2[END_REF], we model the attacker's knowledge about the information system as a six-tuple: A V , A C , A U , Conf, Int, Avail , where A V considers the required access vector used by the attacker to exploit a system's vulnerability (e.g., local access, adjacent network access, network access); A C considers the complexity (e.g., high, medium, low) of the attack required to exploit the vulnerability; A U considers the authentication the attacker requires before launching an attack (i.e., multiple, single, none); and Conf, Int, Avail considers the impact in terms of confidentiality, integrity and availability of a successfully exploited vulnerability. b) About the attack: In this category, we consider the information about the motivation of the attacker, the threat level, the minimum level of required resources to execute the attack, and the attacker's skills in executing the attack. The attacker's knowledge about the attack itself is modeled as AK(A) = M O , T H , R E , S K , where M O considers the different goals (motives) that can encourage an attacker to exploit a vulnerability on the system such as low (e.g., just for fun), medium (e.g., political motives), and high (e.g., for monetary profit; anger, revenge and other emotional drivers; sexual impulses; psychiatric illness) [START_REF] Bielecki | A prototype for support of computer forensic analysis combined with the expected knowledge level of an attacker to more efficiently achieve investigation results[END_REF], [START_REF] Shinder | Scenes of the cybercrime. computer forensics handbook[END_REF]; T H considers the impact level (e.g., low, medium, high) associated to the threat; R E considers the minimum level of tangible resources and intangible resources (e.g., high, medium, low) required by the attacker to exploit a system's vulnerability; and S K defines the level of skills and/or experience (e.g., high, medium, low) required by the attacker to execute a given attack.

2) A posteriori knowledge: A set of information gained by the attacker after a successful exploitation of a system's vulnerability [START_REF] Krautsevich | Towards modelling adaptive attacker's behaviour[END_REF]. The system can release information that improves the attacker's knowledge to exploit vulnerabilities or to overcome the security controls set by the system, however, the adversary knowledge is generally incomplete [START_REF] Krautsevich | Evaluation of Adaptive Attacker Models[END_REF]. In this section we study the attacker's knowledge with respect to the system evolution (e.g., deployment of countermeasures). a) About the countermeasures: From the adversary point of view, the ability to penetrate a system does not necessarily implies the ability to break into a system. Breaking a system means making the system to fail and keep on failing. It is more hostile, and more difficult than penetrating into the system, since it requires an understanding of what makes the system fail [START_REF] Libicki | Brandishing Cyberattack Capabilities[END_REF]. However, penetrating the system is the first step for an attacker to improve his/her knowledge about the system.

According to [START_REF] Krautsevich | Towards modelling adaptive attacker's behaviour[END_REF], an attacker observes a system and can influence its behavior by making actions at a given moment. The system responds to an action probabilistically. Attackers do not make decisions about actions blindly. Instead, they take into account past, current, and possible future states of the system, as well as possible rewards that are connected with the actions. The goal of the attacker is to maximize the expected total reward according to a sole criterion.

We define the attacker's a posteriori knowledge based on the actions the defender performs to protect the system against a given attack (e.g., implementing security countermeasures). Following the formalism proposed in [START_REF] Krautsevich | Towards modelling adaptive attacker's behaviour[END_REF], we model the attacker's a posteriori knowledge as a set A K (C) = S T , P A , P R , R W , D E , where S T corresponds to the system state, P A considers the probability that the attacker executes an action in the state S T i , P R corresponds to the probability that the system transits from state S T i to S T i+1 in response to attacker's actions, R W considers a set of rewards functions dependent on the state and the actions, and D E corresponds to a set of decisions available to the attacker.

III. PROPOSED MODEL DESCRIPTION AND CONSTRUCTION

Our geometrical model is proposed to represent cyber security events (e.g., attacks, countermeasures) as prismatic instances of n-sides. The base of the prism integrates the information from the target's side (internal entities), whereas the height of the prism integrates the information from the attacker's side (external entities). Our proposed geometrical model has the following characteristics:

• There are at least two internal entities and one external entity represented in the geometrical instance; • The base of the geometrical instance is an n-sided polygon; • Each axis of the prism's base represents an internal entity affected by the security event. Such affectation is measure by the contribution of the axis; • All external entities are merged to compute a global contribution. Such value represents the height of the prism; • The end point of each axis is connected to form a polygon; • The contribution of each axis must be greater than zero and no more than one hundred percent; • Polygons can be regular, irregular, and/or convex;

• Concave polygons are excluded from our model since it is not possible to plot instances in which one or more interior angles are greater than 180 degrees; • Polygons are closed with no holes inside; • Polygons are not self-intersecting;

• The prism results out of the projection of the polygon base and height; The remaining of this section details the contribution calculation of the internal and external dimensions of our prismatic model.

A. Internal Axes

As previously stated, each axis composing the base of the prism represents an entity. Each entity contributes differently in the event impact calculation. Following the CARVER methodology [START_REF] Norman | Risk Analysis and Security Countermeasure Selection[END_REF], [START_REF] Of | Special operations forces intelligence and electronic warfare operations, appendix D: Target analysis process[END_REF], which considers six criteria (i.e., criticality, accessibility, recuperability, vulnerability, effect, recognizability), we assign numerical values on a scale of 1 to 10 to each type of element within the entity. As a result, we obtain a weighting factor (WF) that is associated to each type of element. Examples of the practical implementation of this methodology in real case scenarios can be seen in [START_REF] Gonzalez-Granadillo | Selecting optimal countermeasures for attacks against critical systems using the attack volume model and the rori index[END_REF], [START_REF] Gonzalez-Granadillo | Using a 3D geometrical model to improve accuracy in the evaluation and selection of countermeasures against complex cyber attacks[END_REF].

The contribution Co of each internal entity T i in the execution of an event E is a value than ranges from zero (when there is no element of the axis affected to a given event), to one (when all elements of the axis are affected to a given event). The contribution of an entity T i is calculated as stated in Definition 1.

Definition 1 (Internal Axes Contribution): Let X = x 1 , x 2 ,..., x i be a finite set of size i, namely Total E, and composed by the total number of elements integrating the internal entity T i ; and let Y = y 1 , y 2 ,..., y j be a finite set of size j, namely Affected E, and composed by the affected elements of the entity T . Knowing that the set Y is a subset of X, thus Y ⊆ X, then, the contribution Co of the entity T in the execution of event E is computed using Equation 1.

Co(T i , E) = n j=1 Y j × W F (Y j ) ∀j ∈ Y n i=1 X i × W F (X i ) ∀i ∈ X (1)
In order to apply Equation 1 in a practical case, let us consider the entities defined in the previous section. The contribution for the user account, for instance, can be evaluated as the number of users affected by a given attack over the total number of active users from the system. Similarly, the contribution of the confidentiality can be evaluated as the number of alerts indicating a confidentiality issue over the total number of alerts in a given period of time. For spacial contexts, we can evaluate the number of incidents occurring in a given location over the total number of reported incidents within a period of time.

B. External Axis

Contrary to the information about the target, that is modeled as an n-sided polygon (which can be mono-axial, bi-axial or multi-axial), the information about the attacker is modeled as a single entity (i.e., mono-axial), which represents the height of the prismatic instance.

The contribution Co of the external entity T e in the execution of an event E is a value than ranges from zero to one. Such contribution represents the level of information possessed by the attacker regarding the system, the exploited attack, and/or the countermeasures implemented by the system. The greater the attacker knowledge, the greater the impact, and therefore, the larger the prism's height. The a priori and a posteriori contribution Co(T e ) is calculated as stated in Definitions 2 and 3.

Definition 2 (A Priori Contribution):

Let Exp be the level of exploitability of a given vulnerability in terms of access vector (A V ), access complexity (A C ) and authentication (A U ); let Imp be the impact level in terms of confidentiality (Conf ), integrity (Int), and availability (Avail); and let M ot and Res be the attacker's motivation and resources respectively. The a priori contribution Co a of the external entity T e in the execution of an event E is computed using Equation 2.

Co a (T e , E) = 1 2 Exp + 1 4 Imp + 1 4 Goal + 1 4 Res (2) Where Exp = A V × A C × A U Imp = 1 -[(1 -Conf ) × (1 -Int) × (1 -Avail)] Res = R S Goal = S K × T H × M O
From the previous equation, the more remote an attacker is from the host, the greater the A V score; the higher the complexity to access the system, the lower the A C score; the higher the number of required authentication methods, the lower the A U score, and the higher the level of impact in terms of confidentiality, integrity and availability, the greater the Conf , Int, and Avail scores. In addition, the higher the level of resources and skills required by the attacker to exploit a system's vulnerability, the lower the R S and S K scores. The higher the threat level and motivation, the higher the T H and M O scores.

The height h of the prismatic instance I a priori is therefore equivalent to value of the external axis contribution a priori e.g., h(I a ) = Co(T e , E). Note that levels and values refer to the corresponding qualitative and quantitative assessments of each parameter. Our approach considers the scores proposed in the CVSS v2.0 for the exploitability and Impact parameters. For the rest of values, we consider three levels (e.g., low, medium, high) in which the lowest score is 1/3, the medium score is 2/3 and the highest score is 3/3.

In case the prismatic instance is the information system, we take a pessimistic approach, where the values of each parameters composing Equation 2 corresponds to the worst case scenario that could occur in the system. Otherwise, if the prismatic instance is an attack, we consider a more specific approach, where the parameter values correspond to those associated to the exploited vulnerability.

Definition 3 (A Posteriori Contribution): Let S T be the system state, P A the actions available for the attacker, P R the probability that the system transits from one state to another in response to attacker's actions, R W be the reward function, and D E a set of decisions taken by the attacker, then, the a posteriori contribution Co b of the external entity T e in the execution of an event E is computed using Equation 3.

Co b (T e , E) = 1 2 S T + (P A × P R ) + (R W × D E ) 2 (3)
From the previous equation, the higher the a priori knowledge about the system, the greater the S T score; the higher the number of possible actions for the attacker to exploit a vulnerability, the greater the P A score; the higher the probability that the system will react against the attacker's actions, the lower the P R score, the higher the level of reward that the attacker can obtain, the greater the R W score, and the higher the number of decisions available to the attacker, the greater the D E score.

The height h of the prismatic instance I (a posteriori) is therefore equivalent to the value of the external axis a posteriori contribution e.g., h(I b ) = Co(T e , E). Note that the impact of the attacker's a posteriori knowledge about the countermeasure (Co b (T e , C)) should be lesser or equal to the more pessimistic impact of the attacker's a priori knowledge about the system (Co a (T e , S)), therefore, the product of P A × P R and R W × D E should be lesser or equal to the S T value.

IV. EXAMPLE OF INSTANCES

A variety of geometrical instances (e.g., regular and irregular prisms) results from the analysis of the internal and external information related to a given cyber security event. The remaining of this section details the different prismatic instances.

A. Triangular Prisms (Two or Three Axis)

Plotting the contribution of two internal entities (e.g., user account, resource) results into a right triangle polygon (i.e., right isosceles, right scalene). The contribution of the external axis (attacker's information) allows to project the polygon in a three-dimensional space, which results into a right triangular prism. Let us consider, for instance, an event E 1 that compromises 25% of users Co(T 1 ) = 0.25, and 25% of resources Co(T 2 ) = 0.25, with 100% of the attacker's knowledge of the information system. The graphical representation of the impact contribution of event E 1 over the user and resource entities is depicted in Table III as a Triangular Prism. We obtain the base of the prismatic instance by connecting the end point of each internal axis (user, resource). The prism's height is represented by the contribution of the external axis.

Plotting the contribution of three internal entities (e.g., user, resource, time), results into a non right triangle polygon (e.g., equilateral, scalene, isosceles). In this category, we find obtuse triangles (instances with one angle greater than 90 degrees, and/or acute triangles (instances with all their angles less than 90 degrees). The contribution of the external axis (attacker's information) allows to project the polygon

Heptagonal

Octagonal Decagonal in a three-dimensional space, which results into a non-right triangular prism.

B. Quadrangular Prisms (Four Axes)

Plotting the contribution of four internal entities (e.g., user, channel, time), results into a quadrilateral polygon (e.g., square, rhomboid, kite, etc.). We exclude rectangles, since it is not possible to represent instances that have both: two equal alternate sides and right angles. In addition, we discard rhombus from our graphical representation, since it is not possible to represent instances that have both: equal lengths and non-right angles.

The contribution of the external axis (attacker's knowledge) allows to project the polygon in a 3D space, resulting in a quadrangular prism (e.g., parallelepiped, cube). We exclude rectangular parallelepipeds and cuboids, since it is not possible to obtain a rectangular base. In addition, we discard rhombohedrons 1 since we can only plot the height of the instance as a right straight line. However, it is possible to obtain square cuboids 2 from our model.

Let us consider, for instance, an event E 1 that compromises 50% of the system's users, physical resources, logical resources, and channels with 100% of the attacker's knowledge. The graphical representation of the impact contribution of event E 1 is depicted in Table III as a Quadrangular Prism (in this case, a Square Cuboid).

C. N-Polygonal Prisms (N Axes)

Plotting the contribution of five or more internal entities (e.g., user, physical resource, logical resource, channel, time, location, etc.), results into an n-sided polygon (e.g., pentagon, hexagon, heptagon, etc.). Polygons can be regular or irregular. The contribution of the external axis (attacker's knowledge) allows to project the polygon in a 3D space, resulting in an n-prism (e.g., pentagonal prism, hexagonal prism, heptagonal prism, etc.), as depicted in Table III. For instance, let us 1 a special case of a cube with rhombi faces 2 a special case of a cuboid in which at least two faces are squares consider an event E 1 that compromises 100% of the even axes and 10% of the odd axes from a 10-sided polygon (i.e., decagon). The contribution of the attacker's knowledge is 10%, resulting in a decagonal prism (with a star shape), as shown in Table III.

D. Exclusions

It is not possible to obtain prismatic instances with information of only one type of entity. In case of retrieving information of one internal axis (information about the target) and no information from the attacker's side, we will obtain straight lines as the resulting impact of the security event. In case of retrieving information of one internal and one external axis, their projection will result into a surface (i.e., square, rectangle). We exclude such cases from our analysis, since we require information of at least two internal axes, and the information of the attacker's knowledge, in order to build the resulting prisms.

Considering the characteristics of our geometrical model, we constraint our model to right prisms (n-sided prisms whose bases and joining faces are perpendicular to each other). The resulting instance must have identical bases joined together by flat faces and identical cross section along its length. The bases of the prism are polygons and the side faces must necessarily be parallelograms. Based on this, we exclude from our research the following geometrical instances:

• Oblique prisms, since their bases and joining faces are not perpendicular; • Twisted prisms and antiprisms, since their bases are twisted relative to each other, making the side faces be triangles instead of parallelograms; • Platonic solids, i.e., tetrahedron, octahedron, dodecahedron, and Icosahedron, except from the cube, the other platonic solids are excluding from our research, since their side faces are not parallelograms; • Circular solids (e.g., cylinder, cones and spheres), since they have curved surfaces, not flat faces; • Pyramids, since they have triangular sides instead of parallelograms. In addition, the base of the pyramid is not projected to the top, instead, they connect the polygonal base to a single point, called the apex; • Rectangular-based solids (e.g., rectangular parallelepipeds), since it is not possible to plot instances with two equal alternate sides and right angles;

• Prisms whose bases are self intersecting polygons, concave polygons, or open geometrical figures with holes inside.

It is important to note, that although very similar, circular prisms and cylinders are not the same. Technically a cylinder has curved sides, whereas a circular prism has parallelogram sides. However, geometrically, prisms with very large number of sides of regular polygonal bases, are similar to cylinders since the side faces tend to have the parallelograms of negligible width. In our model, prisms with a huge number of lateral sides are considered as polygonal prisms, and cylinders are excluded from our research since their base is circular and not polygonal.

V. GEOMETRICAL OPERATIONS

This section details the measurements of the different geometrical figures described in the previous section. Such measurement allows the mathematical computation of the impact of multiple events in the system.

A. Area (A)

The area (A) of a given event measures the amount of space inside the boundary of a flat (2-dimensional) object such as a triangle or square. We calculate the surface area of the base of a prism using Definition 4.

Definition 4 (Area (A)): Let b be the base of a prism. The area A of b is computed as the sum of the value of entity T i times the contribution value of entity T i+1 divided by two. Results are expressed in units 2 , using the following equation:

A(b) = n i=1 Co(T i ) × Co(T i+1 ) 2 (4)
For the previous Equation, note that in the last term (i.e., Co(T n )), the expression must wrap back to the first term (i.e., Co(T 1 )). This method works correctly for triangles, regular and irregular polygons, as well as convex and concave polygons, but it will produce wrong answers for self-intersecting polygons, where one side crosses over another. However, such cases are excluded from our research. Let us take an example of an attack A 1 that affects 60% of resources (T 1 ), 60% of channels (T 2 ), 80% of users (T 3 ) and requires 40% of recovery time (T 4 ). Attack

B. Volume (V)

The volume (V) of a prism (P) measures the threedimensional space enclosed by the boundary of a prismatic instance (e.g., triangular prism, pentagonal prism, octagonal prims, etc.). We calculate the volume of a prism using Definition 5.

Definition 5 (Volume (V)): Let P be a prism with base b and height h. The volume V of P equals the surface area of the base times the height of the prism. Results are expressed in units 3 , using the following equation:

V (P ) = A(b) × h (5)

C. Coverage of Events

The coverage (COV ) of events is a value that ranges between zero and one, and represents the portion of an event E x that is affected or controlled by an event E y . We calculate the coverage of events using Definition 6.

Definition 6 (Coverage (COV)): Let M be the measurement of an event (e.g., area, volume), and let E 1 and E 2 be two distinct events. The coverage (COV ) of event E 1 respect to event E 2 is computed as the ratio between the impact measurement of E 2 overlapping with the impact measurement of E 1 over the impact measurement of E 2 . Results are expressed in %, using the following equation:

COV (E 1 /E 2 ) = M (E 1 ∩ E 2 ) M (E 2 ) × 100 (6)

D. Residual Risk

The Residual Risk (RR) of an event E x is a value that ranges between zero and one, and represents the portion of the event E x that is left untreated by any control. We calculate the residual risk of events using Definition 7.

Definition 7 (Residual Risk (RR)): Let E 1 be a security incident, and E 2 its corresponding security control. The Residual Risk (RR) of event (E 1 ) after the implementation of event E 2 is computed as the difference between the maximal risk level (i.e., 100%) and the coverage of event (E 2 ) respect to event (E 1 ). Results are expressed in %, using the following equation:

RR(E 1 /E 2 ) = 100% -COV (E 1 /E 2 ) (7)

E. Potential Collateral Damage

The Potential Collateral Damage (P CD) of an event E x is a value that ranges between zero and one, and represents the portion of the event E x that affects elements in the system that are not compromised by the detected security incident. We calculate the P CD of events using Definition 8.

Definition 8 (Potential Collateral Damage (PCD)):

Let event E 1 be a security incident, and event E 2 be its corresponding security control. The potential collateral damage (P CD) of event E 2 is computed as the ratio between the portion of event E 2 that is not intersecting with event E 1 and the total impact measurement of E 2 . Results are expressed in %, using the following equation:

P CD(E 1 /E 2 ) = M (E 2 ) -M (E1 ∩ E 2 ) M (E 2 ) × 100 (8)

VI. USE CASE

A telecommunication company has detected a great number of alerts related to confidentiality and availability issues that affect most of its users and resources. Two main security incidents have been identified: A 1 (CVE-2016-0800), a crossprotocol attack that could lead to decryption of TLS sessions by using a server supporting SSLv2 and export cipher suites as a Bleichenbacher RSA padding oracle; and A 2 (CVE 2015-1787), a Denial of Service attack on applications compiled with OpenSSL library.

Both attacks affect services that rely on SSL/TLS protocols. Attack A 1 allows attackers to break the encryption and read or steal sensitive communications, including passwords, credit card numbers, trade secrets, or financial data, whereas attack A 2 allows remote attackers to cause a denial of service (daemon crash) via a ClientKeyExchange message with a length of zero.

The following security controls are proposed to mitigate both attacks: C1 Install patched version of OpenSSL; C2 Disable the SSLv2 protocol in all the SSL/TLS servers; C3 Reconfigure web servers, SMTP servers, IMAP and POP servers, and any other software that supports SSL/TLS to avoid the use of weak cipher suites. Table IV shows the affected entities and categories for the system S, attacks A 1 , and A 2 , as well as countermeasures C 1 , C 2 , and C 3 . Each entity has at least one category with a given number of elements. Each category has an associated weighting factor (WF), which indicates its priority on the system. The higher the WF, the higher the priority of the entity's category. The rest of the table's columns show the number of elements from the system S that are affected by attacks A 1 , A 2 , and countermeasures C 1 , C 2 , and C 3 . Table V shows the information about the attacker's a priori and a posteriori knowledge about system S, attacks A 1 , and A 2 , and countermeasures C 1 , C 2 , and C 3 . Note that the values of parameters for attacks A 1 , and A 2 are obtained from the National Vulnerability Database3 . The values for the system S are obtained by taking a pessimistic approach (the worst case scenario); and the values of parameters for the countermeasures C 1 , C 2 , and C 3 are first assessed qualitatively and then transformed into their corresponding quantitative values.

A. Impact Calculation 1. Internal Axes Size: We compute the size of each axis composing the system S, using information from Table IV, as follows:

• Ua = (2 × 5) + (63 × 2) = 136 units • Ch = 65 × 3 = 195 units • Re = (57 × 2) + (2 × 4) + (7 × 5) = 157 units TABLE V ATTACKER'S KNOWLEDGE (EXTERNAL AXIS) A Priori Knowledge Instance A V A C A U Conf Int Avail R E S K T H M O S
1.0 0.71 0.704 0.66 0.66 0.275 1.0 1.0 1.0 1.0 A 1 1.0 0.61 0.704 0.275 0.0 0.0 0.675 0.67 0.67 1.0 A 2 1.0 0.30 0.704 0.0 0.0 0.275 0.34 0.34 1.0 1.0 We calculate the contribution of each axis on the execution of the events (i.e., A 1 , A 2 , C 1 , C 2 , and C 3 ) with respect to the system value, using Definition 1. For instance, Countermeasure C 1 affects the following axis: 3. External Axis Contribution: We calculate the contribution of the attacker's knowledge (a priori and a posteriori) using Definitions 2 and 3. For instance, for system S, the most pessimistic a priori contribution is calculated as follows: h(S) = 1 2 (0.49984) + 1 4 (0.91619) + 1 4 (1.0) + 1 4 (1.0) = 97.90%

A 1 ∪ A 2 1.
• Ua = (2 × 5) + (63 × 2) = 136 units → 100.00% • Ch = 0 × 3 = 0 units → 0.00% • Re = (57×2)+(2×4)+(7×5) =
4. Impact Calculation: We calculate the geometrical operations of attack A 1 , A 2 , and countermeasures C 1 , C 2 , and C 3 , using Definitions 4 and 5. For Countermeasure C 1 , for instance, we compute the area and volume as follows: A(C 1 ) = 4, 612.19 units 2 V(C 1 ) = 4, 612.19 units 2 × 42.64 units = 196, 663.92 units 3

Coverage Calculation:

We calculate the coverage of attacks A 1 and A 2 with respect to system S, and the coverage of countermeasures C 1 , C 2 , and C 3 with respect to the combined attack A T = A 1 ∪ A 2 , using Definition 6. In addition, the residual risk (RR) is computed using Definition 7, and the potential collateral damage (PCD) is calculated using Definition 8. For instance, the coverage of countermeasure C 1 with respect to the combined attack A T = A 1 ∪A 2 is computed as follows: Table VI summarizes the impact values of all events. Attacks A 1 and A 2 are compared against both, the system S and all countermeasures (C 1 , C 2 , and C 3 ). The union of both attack A T = A 1 ∪ A 2 affects 15.32% of the total system area. Applying countermeasures individually will reduce part of the attack impact. However, if multiple countermeasures are implemented, the risk is expected to be reduced substantially.

A(C 1 ∩ A T )= 2,604.45 units 2 V(C 1 ∩ A T )= 2,

B. Graphical Representation

Table VII shows the graphical representation of the system S (in green), attacks A 1 and A 2 (in red), and countermeasures C 1 , C 2 , and C 3 (in blue). System S is represented as a regular pentagonal prism, whereas attacks and countermeasures are represented as irregular pentagonal prisms. The graphical representation of the combined attacks A 1 ∪ A 2 shows a higher impact over the system S than their individual representations. Similarly, the graphical representation of the countermeasures shows that their combined implementation has a higher impact over the system, which generally results into a lower residual risk level and a higher potential collateral damage. Countermeasures are plotted along with the system S and the combined attack A 1 ∪ A 2 to show their level of coverage.

While computing the impact of events, we must consider the fact that events can be joint or disjoint. If comparing two or more security incidents, the bigger the measurement, the higher the impact on the system. It is important, however, to compare the impact of events using the same unit scale (e.g., units 2 , units 3 ), and to avoid mixing them up.

If comparing two or more security controls, the bigger the measurement of the events, the higher the protection of the system's elements. However, this does not imply that such an event protects effectively the system from the detected incident. For this, it is necessary to compute the coverage of events. This latter indicates the portion of the incident that is mitigated by a given control. The coverage of events is generally used to compare the impact of incidents over the system, and/or to compare the impact of security controls over the incidents.

If the impact measurement of a given control (e.g., M (E 1 )) is higher than the impact measurement of the security incident (e.g., M (E 2 )), it means that event E 1 affects more system's elements than event E 2 , but it does not mean that event E 2 is totally covered by event E 1 . Computing the event coverage allows us determining the portion of the system under attack and the level of mitigation.

Implementing two or more security controls simultaneously generally increases the coverage area of the incident, which reduces the residual risk and makes the solution look more attractive than their individual implementation. However, the implementation of a set of security controls may require modifications (e.g., change configuration) on system's elements that are not under attack. Such action originates potential collateral damage (PCD) to the system. A higher PCD generally implies higher impact on the system. We should, therefore, search for solutions with the highest incident coverage and the lowest potential collateral damage.

One important aspect of our model is the fact that it only considers a percentage of affected elements to plot the impact contribution on each polygonal axis. It is therefore possible to fall into a situation where two disjoint events are graphically plotted as joint. For instance, if event E 1 covers 50% of the system's users and resources with 50% of the attacker's knowledge, and event E 2 covers 25% of the same axes, assuming that both events are disjoint (they have no affected elements in common), the graphical representation of both events will show that event E 2 is totally covered by event E 1 . Whereas, in reality, if both events are disjoint, they should be treated separately, by making a comparison on the impact size of both events (in this case, event E 1 is two times bigger than event E 2 ), and the coverage should be zero. To avoid the previous issues, we need to calculate the event coverage and plot the graphical representation of events only if they are partially or totally joint.

VII. RELATED WORK

Determining the impact of cyber security events is an open issue in the TIC domain. Several research works rely on metrics to quantitatively measure such impacts. Howard et al., [START_REF] Howard | Mitigate security risks by minimizing the code you expose to untrusted users[END_REF], [START_REF] Howard | Measuring relative attack surfaces[END_REF] and Manadhata et. al. [START_REF] Manadhata | An attack surface metric[END_REF], [START_REF] Manadhata | Measuring the attack surfaces of two ftp daemons[END_REF], for instance, propose a model to systematically measure the attack surface of different software. However, the approach presents the following shortcomings: it cannot be applied in the absence of source code; it includes only technical impact; it cannot be used to compare different system environments; and it does not evaluate the impact of multiple attacks occurring simultaneously in the system. Some researchers rely on simulations to analyze and estimate the impact of cyber events. Dini et. al [START_REF] Dini | On simulative analysis of attack impact in wireless sensor networks[END_REF], [START_REF] Dini | A simulation tool for evaluating attack impact in cyber physical systems[END_REF], for instance, present a simulative approach to attack impact analysis that allows for evaluating the effects of attacks, ranking them according to their severity, and provides valuable insights on the attack impact since during the design phase. As a result, the approach supports designers in deciding which attacks to address and which countermeasures to select. However, the simulation does not provide quantitative analysis on the impact of countermeasures while evaluating the impact of attacks.

Other approaches use frameworks to model the cyber physical attack space. Texeira et al. [START_REF] Teixeira | Attack Models and Scenarios for Networked Control Systems[END_REF], [START_REF] Teixeira | A secure control framework for resource-limited adversaries[END_REF], for instance, propose a framework to classify attacks in a cyber-physical system using a three dimensional taxonomy, whose main axes are the adversary's knowledge, disclosure and disruption of resources. The main drawback of this research is that authors concentrate only on the adversary a priori knowledge leaving aside the a posteriori knowledge. In addition, Krautsevich et al. [START_REF] Krautsevich | Towards modelling adaptive attacker's behaviour[END_REF] and Sarraute et al. [START_REF] Sarraute | POMDPs make better hackers: Accounting for uncertainty in penetration testing[END_REF] propose adversary models that allow understanding the attacker's behavior. The main shortcoming of these researches is that their analysis is based on the adversary's point of view. Our proposed model considers the main aspects of these models to analyze both, the attacker's a priory and a posteriori knowledge.

Based on the aforementioned shortcomings, we propose a geometrical approach to project the impact of cyber events as an n-dimensional prism. The approach uses geometrical operations to compute the size of the polygon, and thus the impact of the represented event. As a result, we are able to project multiple events (e.g., attacks, countermeasures), in a variety of dimensions (e.g., users, channels, resources, Confidentiality, Integrity, Availability, time, etc.), which provides the means to propose security countermeasures as a reaction strategy to mitigate the detected attacks.

VIII. CONCLUSION

In this paper we proposed a novel approach that considers internal vulnerabilities and the attacker's knowledge to model the impact of cyber security events as geometrical prisms. The approach considers internal information about the assets that compose the information system (e.g., users, IP addresses, communication protocols, physical and logical resources, etc.), and external information, about the attacker's knowledge (a priori and a posteriori).

Each element composing the model is assigned a quantitative value (depending on their relevance, priority, or impact over the system). Similar elements are regrouped to form one axis of the model. The projection of all axes (internal and external) results into an n-sided prism, whose base is represented by the internal axes and the height is represented by the external axis. It is therefore possible to plot multiple events (attacks and countermeasures) over the same system which allows the comparison of their size, and thus, their associated impact.

We propose a quantitative approach to compute the area and volume of each geometrical instance, making it possible to compute the coverage of events with respect to the system, the residual risk, and the potential collateral damage that may occur out of the implementation of the security countermeasures. As a result, our model is seen as a tool that helps organizations to make the most cost-effective decisions in minimizing the risk of the studied cyber events.

  A 1 will have an area equal to A(Quadrilateral) = [(60 × 60) + (60 × 80) + (80 × 40) + (40 × 60)]/2 = 700 units 2

  157 units → 100.00% • Lo = (0 × 2) + (35 × 4) = 140 units → 32.71% • Sp = (48 × 4) + (0 × 5) = 192 units → 44.86%

  604.45 units 2 × 42.64 units = 111,053.82 units 3 COV (C 1 /A T ) = 111,053.82×100 374,202.28 = 29.68% RR(C 1 /A T ) = 100 -29.68 = 70.32% PCD(C 1 /A T ) = (196,663.92-111,053.82)×100 196,663.92 = 43.53%

  Table I depicts the possible values of the parameters composing Equation 2.

  Table II depicts the possible values of the parameters composing Equation 3.

https://nvd.nist.gov/

Acknowledgements: The research in this paper has received funding from the PANOPTESEC project, as part of the Seventh Framework Programme (FP7) of the European Commission (GA 610416).


Axel Halin
email: axel.halin@student.unamur.be

Alexandre Nuttinck
email: alexandre.nuttinck@student.unamur.be

Mathieu Acher
email: mathieu.acher@irisa.fr

Xavier Devroey
email: xavier.devroey@unamur.be

Gilles Perrouin
email: gilles.perrouin@unamur.be

Patrick Heymans
email: patrick.heymans@unamur.be

Yo Variability! JHipster: A Playground for Web-Apps Analyses

Keywords: engineering → Software testing and debugging, Empirical software validation, Software configuration management and version control systems, Software product lines, •Social and professional topics → Software engineering education, Case Study, Web-apps, Variability-related Analyses

Though variability is everywhere, there has always been a shortage of publicly available cases for assessing variabilityaware tools and techniques as well as supports for teaching variability-related concepts. Historical software product lines contains industrial secrets their owners do not want to disclose to a wide audience. The open source community contributed to large-scale cases such as Eclipse, Linux kernels, or web-based plugin systems (Drupal, WordPress). To assess accuracy of sampling and prediction approaches (bugs, performance), a case where all products can be enumerated is desirable. As configuration issues do not lie within only one place but are scattered across technologies and assets, a case exposing such diversity is an additional asset. To this end, we present in this paper our efforts in building an explicit product line on top of JHipster, an industrial open-source Web-app configurator that is both manageable in terms of configurations (≈ 163,000) and diverse in terms of technologies used. We present our efforts in building a variability-aware chain on top of JHipster's configurator and lessons learned using it as a teaching case at the University of Rennes. We also sketch the diversity of analyses that can be performed with our infrastructure as well as early issues found using it. Our long term goal is both to support students and researchers studying variability analysis and JHipster developers in the maintenance and evolution of their tools.

CCS Concepts

•Software and its

INTRODUCTION

JHipster [START_REF]Jhipster website[END_REF] is an open-source generator for Web applications (Web-apps). Started in 2013 by Julien Dubois, JHipster aims at supporting all cumbersome aspects of Web applications development: choice of technologies on the client and server sides as well as integrating them in a complete building process. On the server side, JHipster relies on a Java stack (with Spring Boot). On the client side Angu-larJS and Bootstrap (a HTML/CSS and JavaScript framework) are used. Finally, Yeoman, Bower, Gulp and Maven automate the building process, including the management of dependencies across the offered technologies [START_REF]Jhipster website[END_REF]. JHipster is used all over the world both by independent developers and large companies 1 such as Adobe, Google, HBO, etc..

The setup of a Web-app with JHipster is performed in two phases: configuration and generation. The configuration is done via a command-line interface (see Figure 1) through which the user can select the technologies that will be included. The result of this configuration is a yo-rc.json file (see Listing 1) used for the generation phase. To achieve this generation, JHipster relies on Yeoman 2 using npm and Bower tools to manage dependencies, and yo tool to scaffold projects or useful pieces of an application [START_REF] Raible | The JHipster mini-book[END_REF]. Based on the content of the yo-rc.json file, JHipster's generator produces relevant artefacts (Java classes and so on). Beyond this generator -the main focus of this paper -JHipster offers multiple sub-generators and even has its own language, JHipster Domain Language, to easily generate entities and all related artefacts (e.g., Spring Service Beans).

From its inception to this day, JHipster has constantly grown throughout 146 releases. It now has more than 5000 stars on GitHub and can count on a community of 250 contributors. In October 2016, it has been downloaded 22739 times 3 . This constant evolution allows JHipster to offer up-to-date frameworks and technologies to its users (for instance, the infrastructure can be generated using Docker since release 3.0.0).

By combining configuration and generation in a constantly evolving stack of technologies, JHipster is akin to Mr Jourdain's prose: a software product line initiative without naming it as such. In this paper, we describe our efforts in building an explicit product line on top of JHipster to expose it as a case for research, education and to ease the development of JHipster itself. Our preliminary infrastructure applied on only 300 variants (out of ≈ 160,000) already disclosed some unreported issues, which we perceive as an incentive to pur-Listing 1: _yo-rc.json excerpt { " generator -jhipster " : { ( ... ) " useSass " : false , " applicationT ype " : " monolith " , " testFrameworks " : [] , " jhiPrefix " : " jhi " , " enableTransl a t i o n " : false } } Figure 1: JHipster command line interface sue in this direction. Though "lifting" such infrastructure in the web domain is not new (e.g., [START_REF] Sanchez | A Comparison of Test Case Prioritization Criteria for Software Product Lines[END_REF][START_REF] Nguyen | Exploring variability-aware execution for testing plugin-based web applications[END_REF]), JHipster offers interesting assets beyond replication studies: (a) it covers key aspects of product line development, variability, product derivation and evolution; (b) the number of variants is large enough to require automated derivation support (on top of Yeoman) but small enough to be enumerated through distributed computing facilities yielding exact results to assess various kinds of analyses; (c) it allows to address variability modelling and configuration challenges across technological spaces [START_REF] Jin | Configurations everywhere: implications for testing and debugging in practice[END_REF]. All sources of our preliminary infrastructure can be found at https://github.com/axel-halin/Thesis-JHipster.

In the remainder, we present our efforts to manually reverse engineer variability from JHipster artefacts and define a Web-app software product line (Section 2). We analyse current state of the art for products' analyses, familybased analyses, and product line evolution in Section 3, and presents the JHipster's potential for each of those research fields. Section 4 reports our experiences in using JHipster as an education case study for software product line teaching. Finally, Section 5 concludes this paper and presents future works using JHipster.

JHIPSTER AS A PRODUCT LINE

Although never explicitly acknowledged by the JHipster developer, it is straightforward to think JHipster supported technologies 4 (microservice architecture, authentication, etc.) as variation points to be resolved during product line application engineering.

Based on this vision, we decided to model the system in a feature model using FAMILIAR [START_REF] Acher | FAMILIAR: A domain-specific language for large scale management of feature models[END_REF]. This decision was motivated by our will to assess automatically a maximum of configurations authorized by the JHipster generators. The first step was to identify the variability. To do so, we retrieved the publicly available source code 5 and analysed it. We quickly identified interesting artefacts: prompts.js files. JHipster's Yeoman generator is divided in multiple prompts.js files, each of which handles specific parts of the configuration pro- 4 The complete list is available on https://jhipster.github.io/ cess. For instance, client/prompts.js offers the possibility to use LibSass, while, as illustrated in Listing 2, the type of database is selected in server/prompts.js.

From these artefacts, we derived the feature model presented in Figure 2. In this model, the abstract features represent the multiple choices questions (typically, which of these technologies do you wish to use?) while the concrete features are the different choice(s) available to the user. Except for the testing frameworks, all of these multiplechoice questions are exclusive (choose only one production database, for instance), mapped as alternate groups. Yes or no questions are represented by optional features. So, if we consider Listing 2 as an example we have: database as an optional abstract feature, with SQL, Mongodb and Cassandra as concrete alternate sub-features. We also identified several constraints in the JavaScript files (when (...) return ap-plicationType === 'microservice', in Listing 2, is one of them) which we synthesized in 15 constraints. For the sake of conciseness, we only present few of them in Figure 2.

At the variability realization level, JHipster relies on Yeoman template files (JavaScript, Java, HTML, XML, ...) for holding common parts but also properties specific to some variants. Conditional compilation is the main implementation mechanism for realizing variability. With Yeoman templates, some specific code in the different artefacts is activated depending on user's configuration. A first example is given in Listing 3 for Maven files: hikaricp.version Maven property is defined only if the configuration includes an SQL database. A second example in given in Listing 4 for Java files. The method h2TCPServer is only used in configurations relying on H2 databases (either h2Disk or h2Memory). The inheritance of AbstractMongoConfiguration depends on the activation of mongodb. Java annotations are also subject to variations. Thus, variability information is scattered in different artefacts (e.g., Maven, Java, JavaScript, etc.).

Analysis Workflow

From the feature model, we devised an automated way to generate JHipster's variants in order to check their validity (are the variants correctly generated? do the Web-apps compile? Can we build them?). This was done by building for each variant the matching .yo-rc.json file and then calling the generator (yo jhipster ) on each of them. The keys Yeoman expects to find in the .yo-rc.json file can be found in the function saveConfig of JHipster's index.js files. From there we can then run variant dependent commands (Maven or Gradle, Docker, ...) to compile, build and test them (see Figure 4). For each variant, we store some interesting information in a CSV file to analyse later on. Currently, this information is the result of the generation/compilation/build processes; the logs from each process if there is a problem; the duration of the generation, compilation, and build phases; the size of the Docker image; and the results from the unit tests. This analysis workflow currently runs on a subset of JHipster's variants: we do not, yet, generate client or server standalone application variants (which may be obtained using JHipster sub-generator); we exclude variants with an external databases (Oracle or H2); and we include all test frameworks in each variant (if the constraints allow it), as it prevents the generation of similar variants with only different test frameworks. These choices were motivated both by technical reasons (Oracle being a proprietary database additional work is needed to use it properly) and practical reasons (What can we test with client only app? Are client/server parts not tested in the other types of application?). This selection decreased the total number of variants to about 4600.

Preliminary Analyses

With the analysis workflow presented in Figure 4, we have already tested the validity (generation, compilation, build) of about 300 variants and found unreported bugs (i.e., anything that would prevent the generation, compilation, or execution of a variant of JHipster, or lead to deviant behaviour) in a few of them. For example, the first bug we found is related to the Docker image of the MariaDB database, in monolithic applications, and it is encountered while trying to deploy the application via Docker. Basically, Docker is looking for the wrong repository/tag, one that doesn't exist. The cause of this error is a missing line in the file /src/main/docker/app.yml: a condition prodDatabase-Type == 'mariadb' on line 5. This issue is still found in JHipster 3.9.1 and doesn't seem to have been detected (currently no related issue post mention it). We will extend the number of tested variants to possibly all of them. We will also use the 3 supported testing frameworks (Cucumber, Protractor and Gatling) to evaluate beyond the correctness of the applications their non-functional properties (performance testing, UI testing, etc. see Section 3).

We started investigating preliminary results. For instance, the correlation between generation time and the type of the application (see Figure 3). We observe on this boxplot that micro-service applications and UAA servers require shorter generation times than monolithic applications or micro-service gateways. Indeed, micro-service applications and UAA servers do not need the client part of JHipster's applications. We hope to extract information regarding non-functional properties of the generated Web-apps. q q q q "gateway" "microservice" "monolith" "uaa"

A CASE FOR RESEARCHERS

In the previous section, we presented our derivation infrastructure as well as a few statistics on the generated products and issues found. In this section, we explore two vertices of the "PLA cube" [START_REF] Von Rhein | The pla model: on the combination of product-line analyses[END_REF]: product-based and family-based analyses. We explain why JHipster is a good candidate to devise new techniques and perform additional empirical assessment of existing ones.

Products' Analyses

Product lines usually allow a large number of products. Two approaches are possible to validate them. The use of formal methods which prove correctness properties in the specification at the product line level such that all derived products satisfy the same properties, without needing to enumerate all of them [START_REF] Beek | Modelling and analysing variability in product families: Model checking of modal transition systems with variability constraints[END_REF][START_REF] Classen | Featured Transition Systems: Foundations for Verifying Variability-Intensive Systems and Their Application to LTL Model Checking[END_REF]. Another approach is to rely on testing, which main goal is to select and sort the fittest set of products to test according to given criteria in order to detect as much bugs as possible. Systematic studies show that a lot of effort has been put on SPL testing [START_REF] Da Mota Silveira Neto | A systematic mapping study of software product lines testing[END_REF][START_REF] Engström | Software product line testing -A systematic mapping study[END_REF][START_REF] Machado | On strategies for testing software product lines: A systematic literature review[END_REF].

Structural Sampling

Sampling techniques. To reduce the number of products to test, one popular research direction is to use Combinatorial Interaction Testing (CIT) techniques [START_REF] Cohen | Constructing Interaction Test Suites for Highly-Configurable Systems in the Presence of Constraints: A Greedy Approach[END_REF][START_REF] Lopez-Herrejon | A first systematic mapping study on combinatorial interaction testing for software product lines[END_REF] and pairwise (generalized to t-wise) criteria [START_REF] Lochau | Model-based pairwise testing for feature interaction coverage in software product line engineering[END_REF][START_REF] Lopez-Herrejon | Multi-objective Optimal Test Suite Computation for Software Product Line Pairwise Testing[END_REF][START_REF] Marijan | Practical pairwise testing for software product lines[END_REF][START_REF] Perrouin | Pairwise testing for software product lines: Comparison of two approaches[END_REF]. Over the years, several tools have been developed and support pairwise based selection on the feature model, e.g., [START_REF] Hervieu | PACOGEN: Automatic Generation of Pairwise Test Configurations from Feature Models[END_REF][START_REF] Johansen | An algorithm for generating t-wise covering arrays from large feature models[END_REF]. In order to support larger t values, as well as larger feature models, other search-based heuristics have been proposed [START_REF] Al-Hajjaji | IncLing: efficient product-line testing using incremental pairwise sampling[END_REF][START_REF] Henard | Bypassing the Combinatorial Explosion: Using Similarity to Generate and Prioritize T-Wise Test Configurations for Software Product Lines[END_REF][START_REF] Sayyad | On the value of user preferences in search-based software engineering: A case study in software product lines[END_REF][START_REF] Parejo | Multi-objective test case prioritization in highly configurable systems: A case study[END_REF]. All of those CIT, t-wise, and other search-based techniques make the hypothesis that bugs come from interactions between few features and try to select an adequate set of products to test in order to cover as much feature combinations as possible. They have been extensively validated on a large number of feature models, with different sizes, and coming from different sources. However, very few evaluations have actually built the set of products to test in their process.

JHipster potential for Sampling. With ≈ 163,000 possible products, JHipster is both non-trivial (as opposed to some academic models in the SPLOT repository) without being as large a Linux, WordPress or Drupal cases. This particularity makes accessible the generation of all the variants. The idea is to be able to obtain a ground truth to compare the efficiency of sampling algorithms. By being able to compute absolute values for the numbers and types of interaction bugs, biases when assessing techniques can be reduced. As noted by Jin et al. [START_REF] Jin | Configurations everywhere: implications for testing and debugging in practice[END_REF], configuration issues can happen everywhere: we believe that the variety of technologies at work in a JHipster derived product is also an opportunity to study such aspects. As seen in Section 2, our feature model integrates variability information from different files and will lead researchers to study different kinds of interaction bugs.

Functional Testing

Product-level functional testing. As noted by Von Rhein et al. [START_REF] Von Rhein | The pla model: on the combination of product-line analyses[END_REF], product-based analysis strategy is simple: we analyse each product individually without taking into account variability (it has been resolved using sampling or enumerating all products). The benefit is that single-product analysis tools can be used. Researchers have proposed to derive test cases from product line scenarios and use cases (e.g., [START_REF] Nebut | System Testing of Product Lines: From Requirements to Test Cases[END_REF]) promoting the reuse of test models and artefacts.

JHipster's potential. As opposed to Drupal or Wordpress cases, where test cases are either optional or solely depending on the will of plugin developers [START_REF] Sanchez | A Comparison of Test Case Prioritization Criteria for Software Product Lines[END_REF][START_REF] Nguyen | Exploring variability-aware execution for testing plugin-based web applications[END_REF][START_REF] Greiler | Test confessions: A study of testing practices for plug-in systems[END_REF], JHipster comes with a systematic testing infrastructure and test cases are deployed for every Web-app deployed. In particular, Cucumber [START_REF]Cucumber website[END_REF] supports early testing in the form of scenarios. Integration with code coverage tools is also available. However our preliminary analyses shown that the provided tests were quite simple, product-agnostic (based on a generic application that is the root of all products) and code coverage was quite low. Thus, we should derive test cases that take into account the specificities of each product, to get a better base coverage prior to the development of a richer Web-app on top of the derived product.

Non-Functional Analyses

Feature-related quality attributes. Recent research shifts from functional validation using testing to detect undesired feature interactions to non-functional analyses in order to predict performance of a given product [START_REF] Sarkar | Cost-Efficient Sampling for Performance Prediction of Configurable Systems (T)[END_REF][START_REF] Siegmund | Predicting performance via automated feature-interaction detection[END_REF][START_REF] Siegmund | Scalable prediction of non-functional properties in software product lines: Footprint and memory consumption[END_REF][START_REF] Siegmund | Performance-influence models for highly configurable systems[END_REF]. Using statistical learning [START_REF] Guo | Variability-aware performance prediction: A statistical learning approach[END_REF] and regression methods [START_REF] Valov | Empirical comparison of regression methods for variability-aware performance prediction[END_REF], or mathematical models to predict and detect (undesired) performance-relevant feature interactions [START_REF] Zhang | A mathematical model of performance-relevant feature interactions[END_REF].

JHipster potential for quality analyses. Web-apps are particularly interesting cases for performance, since this quality attribute has a direct influence on Websites' successes. To this end, JHipster comes with Gatling6 , a load testing tool. It is possible to experiment with feature-related performance techniques in order to assess the proposed theories and calibrate statistical learning. Note that performance is not the only quality attribute that can be studied: security is also key especially for e-commerce websites. While the JHipster infrastructure does not currently offer any security-dedicated analysis toolset, the diversity of technologies used in a JHipster application and our automated derivation approach allow to focus on a given technology in various security scenarios.

Family-based Analyses

Variability-aware techniques. So far, our infrastructure focuses on the product level by sampling products of interest and analysing them individually using provided validation environments (Protactor, Karma.js, Cucumber, etc.). While our goal is to obtain a ground truth by analysing all the variants [START_REF] Galindo | Exploiting the Enumeration of All Feature Model Configurations[END_REF], exploiting variability to reuse analyses (e.g. tests, proofs, etc.) in order to reduce the overall analysis effort and better scale large cases is relevant [START_REF] Liebig | Scalable analysis of variable software[END_REF]. Model-based testing approaches use behavioural models of the product line to generate test cases for the different products: (resp.) delta-oriented product line testing [START_REF] Lochau | Incremental Model-Based Testing of Delta-Oriented Software Product Lines[END_REF][START_REF] Lachmann | Delta-oriented test case prioritization for integration testing of software product lines[END_REF] and featured transition system based [START_REF] Devroey | Coverage Criteria for Behavioural Testing of Software Product Lines[END_REF][START_REF] Devroey | Statistical prioritization for software product line testing: an experience report[END_REF][START_REF] Devroey | Search-based Similarity-driven Behavioural SPL Testing[END_REF] approaches use (resp.) state machines and transition systems in order to capture the common and product specific behaviour of the product line. At the code level, variability-aware parsers [START_REF] Kästner | Variability-aware parsing in the presence of lexical macros and conditional compilation[END_REF], variational structures [START_REF] Walkingshaw | Variational data structures: Exploring tradeoffs in computing with variability[END_REF] and type-checking [START_REF] Kastner | Type-checking software product lines-a formal approach[END_REF] are of interest. They enable variability-aware testing [START_REF] Kästner | Toward variability-aware testing[END_REF] to, for example, evaluate a test case against myriads of configurations in one run [START_REF] Nguyen | Exploring variability-aware execution for testing plugin-based web applications[END_REF].

JHipster potential. JHipster offers an interesting playground for the aforementioned analyses. The difficulty for model-based approaches is to obtain accurate models of the case study when the implementation already exists. To this end, server execution logs of different variants can be used to extract part of the system behaviour [START_REF] Devroey | Statistical prioritization for software product line testing: an experience report[END_REF]. At the code level, the challenge is to specify annotations across multiple technological spaces, while performing commonality and variability analysis. JHipster provides a generic customisable Web-app for each variant, enabling a user to log in and to create entities, as a starting point. JHipster also includes a configurator, allowing to consider the interaction between configuration workflows [START_REF] Hubaux | Formal modelling of feature configuration workflows[END_REF] and derived products [START_REF] Perrouin | A complexity tale: web configurators[END_REF].

Product Line Evolution

Evolution techniques. From the evolution perspective, product lines represent an interesting challenge. Product lines developers have to manage updates at different levels: the evolution of the variability model and the mapping to other artefacts [START_REF] Dintzner | FEVER: Extracting Feature-oriented Changes from Commits[END_REF]; the evolution of the artefacts themselves which will impact several products [START_REF] Neves | Safe evolution templates for software product lines[END_REF][START_REF] Sampaio | Partially safe evolution of software product lines[END_REF]; and the evolution of the configurator and configuration workflow. To understand how existing SPL are updated, Passos et al. [START_REF] Passos | Coevolution of variability models and related software artifacts[END_REF] recently studied the Linux kernel variability models and other artefact types co-evolution.

JHipster potential. With 146 releases since 2013, JHip-ster is under active development and evolution. Therefore a challenge for researchers is to devise automated means to update the JHipster feature model. As opposed to the Linux case, where part of the variability model can be extracted from KConfig, several JavaScript files are necessary to build it, pushing for more versatile variability inference techniques.

A CASE FOR EDUCATION

JHipster has been used as part of different teaching courses. In this section, we report on such an experience and then argue that JHipster is a relevant case for education and in particular for SPL teaching.

Experiences

Experience #1. Our first teaching experience with JHipster started in 2015 at University of Rennes 1. The audience was 40+ MSc students with a speciality in software engineering or in software management. As part of a modeldriven engineering course, we used to teach variability modelling and implementation techniques. In 2015, we decided to slightly change the way variability is explained and we notably introduced JHipster, for the following reasons.

First, students used JHipster in another course dedicated to Web development. Therefore students could reuse JHipster for building a quite complex Web application in the model-driven engineering course: a Web generator of video variants called VideoGen. VideoGen is a software application that builds video variants by assembling different video sequences; it is a generalization of a real-world Web generator [START_REF] Bécan | On the variability secrets of an online video generator[END_REF]. Video variants can be randomly chosen or users can configure their videos through a Web interface. A textual specification, written in a domain-specific language, documents what video sequences are mandatory, optional, or alternatives. Frequencies and constraints can also be specified 7 . VideoGen challenges students to master Web development as well as variability modelling and implementation techniques: they should build a Web configurator, implement algorithms for randomly choosing and building a video variant, etc. The video generator was the running example of the course and was used in the lab sessions and in the project for evaluating students. JHipster was used all along to implement the Web application, including a Web configurator. In summary, JHipster was used as a relevant technology for showing the relations with other courses (Web development) and for implementing a non-trivial variability system (a video generator) based on modelling technologies.

The second reason is that we took the opportunity to explain how JHipster is implemented and more precisely how variability concepts and techniques are applied in practice. During the course, we used JHipster to define what a software product line is, making the correspondences with other well-known configurable systems like Linux, Firefox, or ffmpeg. We explained variability implementation techniques and in particular conditional compilation, templates and annotative-based approaches with the use of JHipster. From a variability modelling perspective, we introduced feature models by using the configurator of JHipster. In the lab sessions, students used the JHipster generator to obtain a Web stack and develop the video generator. They had to make the Web video generator configurable, for instance, they had to implement the ability to save or not a video variant. We have also proposed different exercises related to feature modelling. Along the way, students could exercise on variability concepts that were also found in JHipster.

Our experience was mostly positive. The evaluation of the students' projects on the Web video generator gives high marks. Interactions with students during the courses show that JHipster helps to understand more concretely variability concepts. However we noticed two limitations. First, students manipulated variability concepts at two levels and for two different purposes. The first level was for creating from scratch a configurable video generator, involving skills in domain-specific languages, model transformations, and variability modeling. The second level was for understanding and reusing the JHipster generator. There was some confusions between the two levels. The explanations on JHipster certainly deserve more time and a specific attention -perhaps a dedicated exercise, see hereafter. Second, the technology behind JHipster is quite advanced and requires numerous skills. Some students have technical difficulties to connect the dots and transfer their conceptual knowledge into concrete terms. We had to postpone the deadline for project delivery to let students enough time to master the Web stacks.

For mitigating the two weaknesses, we have decided in 2016 to play the full course on Web development before the model-driven engineering and variability courses. We expect that students can, prior to the course, master JHipster for (1) better understanding its internals; (2) better implementing the variability concepts.

Experience #2. Our second teaching experience with JHipster was in late 2015 at University of Rennes 1. This time the audience was MSc students with a strong interest in research. We reused almost the same material as previously but we also addressed more advanced topics like automated reasoning with solvers, software product line verification and validation, etc.. We used JHipster for the same previous reasons. Compared to the first experience, JHipster was the sole focus of this course and there was no video generator to develop. It simplified how variability concepts were introduced and explained. The project aimed at evaluating students and was oriented for addressing some open research questions: How to elaborate and reverse engineer a feature model of the JHipster generator? What are the configuration bugs of JHipster? How to automatically find those bugs?

With the JHipster case, students could elaborate a feature model based on a static analysis of several artefacts. They could apprehend the combinatorial explosion inherent to variability-intensive systems. Overall students could revisit the variability techniques of the course with a realistic and complex example. The JHipster case also shows to students the connection with other research works, mainly what we have described in the previous section. Some questions were voluntary open like the proposal of "a strategy for testing the configurations of JHipster at each commit or release".

Another motivation for us was to use JHipster to explore some research directions and make some progress with students. We asked them to collect and classify configuration bugs on GitHub. We also gathered several feature models based on their analysis. Such works help us to re-engineer JHipster as a software product line: we reused such feature models to initiate the work exposed in Section 2. Students of the course did not design or develop the workflow analysis of Figure 4. Discussions and insights, however, motivate the need to build such a testing infrastructure for JHipster.

Overall, the work of students was evaluated in a positive way. They demonstrated their abilities to understand and use variability concepts. It was also useful for our own research work.

Other experiences. We have used JHipster in other educating settings in 2015: (a) at University of Montpellier for MSc students; (b) within the DiverSE Inria team for forming PhD students to variability. Such experiences deserve less comments since the duration of the courses was one full-day. Yet the JHipster case was again useful to us, educators and researchers, to both illustrate the variability concepts and exchange on open issues.

JHipster for Education

A survey on teaching of software product lines showed that two recurring issues for educators are the absence of case studies and the difficulty to integrate product lines within a curriculum [START_REF] Acher | A survey on teaching of software product lines[END_REF]. Similar concerns have been raised at SPLTea'14 and SPLTea'15 workshops (see http://spltea. irisa.fr). JHipster acts as an interesting and useful case for addressing these issues. Specifically, JHipster can be used for: (i) illustrating a product line course and for describing variability modelling and implementation techniques with a real-world case over different technologies; (ii) conducting lab sessions in relation with variability; (iii) connecting or better integrating product line courses to other courses (e.g., Web development, model-driven engineering); (iv) exploring open research directions with students.

In conclusion, our experiences with JHipster were mostly positive, though some improvements can be made. All material (slides, instructions of lab sessions) can be found online: http://teaching.variability.io/. We are reusing the same case and material in 2016 at the University of Rennes 1.

CONCLUSION AND FUTURE WORK

In this paper, we described JHipster as a case for experimenting with various kinds of variability-related analyses and teaching software product lines. We introduced an analysis workflow that automates the derivation of JHipster variants (Web-apps) on the basis of a feature model manually extracted from Jhipster questionnaire's files. As the number of possibilities is within reach of current (distributed) computing facilities, some "all-products" information may be obtained, which is useful to assess some specific techniques such as sampling. Our analysis workflow is also relevant for education to understand and explore product line derivation testing and analysis concepts. Our analysis infrastructure is only in its premises and naturally calls for future developments. At the research level, we would like of course to share the results obtained on running analyses on the whole product line. This requires running our workflow on distributed infrastructure like Grid5000 (https://www.grid5000.fr/), an option that we are currently studying. We also want to share our results (bugs, performance issues) with the JHipster developers so that they can take advantage of them in their fixes and releases. We finally would like to introduce this workflow in our SPL teaching curriculum and continue to share it openly with the community.

Figure 2 :

 2 Figure 2: JHipster reverse engineered feature model

Listing 4 :

 4 DatabaseConfiguration.java Excerpt (...) @Configuration <% if ( databaseType == ' sql ') { % > @ E n a b l e J p a R e p o s i t o r i e s ( " <%= packageName % >. repository " ) @ E n a b l e J p a A u d i t i n g (...) @EnableTransactionManagement <% } % > (...) public class D a t a b a s e C o n f i g u r a t i o n <% if ( databaseType == ' mongodb ') { % > extends A b s t r a c t M o n g o C o n f i g u r a t i o n <% } % >{ <% _ if ( d evDa taba seT ype == ' h2Disk ' || de vDat abas eTy pe == ' h2Memory ') { _ % > /* * * Open the TCP port for the H2 database . * @return the H2 database TCP server * @throws SQLException if the server failed to start */ @Bean ( initMethod = " start " , destroyMethod = " stop " ) @Profile ( Constants . S P R I N G _ P R O F I L E _ D E V E L O P M E N T ) public Server h2TCPServer () throws SQLException { return Server . crea teTc pSe rver (...) ; } <% _ } _ % > (...)

Figure 3 :

 3 Figure 3: Distribution of generation time by application type boxplot

Figure 4 :

 4 Figure 4: Complete Analysis Workflow

http://gatling.io/

More details can be found online: https://github.com/ FAMILIAR-project/teaching/tree/gh-pages/resources/ Rennes2015MDECourse

ACKNOWLEDGEMENTS

The authors would like to thank the anonymous reviewers for their feedback. This work was partly supported by the European Commission (FEDER IDEES/CO-INNOVATION).

://jhipster.github.io/companies-using-jhipster/ 2 http://yeoman.io/ 3 https://www.npmjs.com/package/generator-jhipster