Chapter 11: A simulation of the transit network of the Paris Metropolitan Region

Introduction

Once the transit assignment model is described and its behaviour is tested in simple networks, we wish to implement it in a large-scale network. Paris, capital of France, and the Ile-de-France region cover an area of 12 072 km2 and accommodate a population of 11,7 million (INSEE, 2012), making it an ideal field of application.

From the opening of the first metro line in 1900, an extensive public transportation system has been built, with a diversity of competing and complementary transit modes; boat, coach, buses, light rail, metro, RER and commuter rail. With 41 million daily trips by all motorized and non-motorized transport modes, the adequacy of the transportation system is crucial.

However, the population boom and transport policies favourable to public transportation have put the transit system under pressure, while the saturation of some of its elements make the travel conditions intolerable (Le Figaro, 2010).

The analysis of the results does not pretend to be a diagnosis of the state of Greater Paris transit network. It rather acts as a showcase for the simulation capabilities of the CapTA simulator on a large scale network and as a means further investigate its behaviour. In addition, the results have served in order to elaborate some indicators for the travel conditions on the network.

The chapter is articulated in 8 parts and a conclusion. Firstly, we present the transport demand and the transit supply of the application field, the Greater Paris Area. In section 4 the model variants as well as the simulation parameters and characteristics are described. Thereafter, sections 5-8 present the results from the simulations and the comparison among the model variants. The passenger flow and the traffic state are dealt in section 5. The effect of the passenger flow on the transit operation is treated in section 6. Finally, sections 7 and 8 deal with the impact of the capacity effects and the comfort on the passengers. We conclude by stating the main advantages of the CapTA model and some appreciation of further development. According to the last global survey - EGT 2010-(OMNIL, 2012), in 2010 we observed 41 million daily trips by all transport modes (not-motorized and motorized) of which 39% were pedestrian trips. The public transportation was involved in 34% of the motorized trips, with significant spatial diversity, whether the trip has an origin or destination at the centre of the agglomeration or not. In Figure 1, the modal shares are illustrated for the motorized trips by geographic relation. While, for the suburbs trips, the car captures nearly 80% of the motorized trips within Paris (intra-muros) and for the radial tripswhere Paris is at one endpublic transportation captures over 70% of the volume, due to a denser network and a greater efficiency compared to car. Even though the OD matrix correspond to the public transportation trips made in the most loaded period of the day, the morning peak hour, the results show only minor congestion for the worst case scenario in 2008. We wish to demonstrate that with a significantly greater passenger flow, as long as the demand is lower than the overall system capacity, the behaviour of the CapTA model is reasonable. Indeed, we choose to multiply the initial Origin -Destination Matrix with a 1,3 factor. That could make reference to a hyperpeak flow within the morning peak, but it is mainly used to show the validity of the results for high transport flows. The transit supply used in the CapTA model is based on the data provided by DRIEA, while doing the necessary transformations. The service timetable from the initial data was used in order to estimate the hourly frequency of each transit service. The in-vehicle travel time of the transit arcs was calculated on the basis of the actual length of the transit links within the network and an in-vehicle travel time ration per transit route provided. Further modifications were made to in order to adapt the travel time of the transit services to the actual station to station travel times.

The transit network is characterised by a multitude of different rolling stocks. There are at least 17 types of trains with different compositions and interior design characteristics. The same occurs in the metro, with 7 types of vehicle on rail or tyre. As long as the buses and coaches are concerned it is not simple to define the actual models circulating. However, we have defined 7 categories of road vehicles with average characteristics (Chandakas, 2012).

We assigned one rolling stock on each one of the transit routes of the Greater Paris network.

An additional table was created with the characteristics of the transit services: capacity, headway, dwell time and number of passenger stream for the passenger exchange at stations. The final service network is transformed into the calculation network for use in the transit assignment. The modifications mainly concern the guided transport modes (rail, metro, tramway and VAL) and their stations. The transit lines are identifiedas presented in chapter ..., acting as a basic component for the simulationand the station platforms for each direction are distinguished by an additional platform access/egress arc between them and the station concourse level. When the simulation included comfort on the buses, service legs are added to the calculation network.

Simulation Characteristics and Model Variants

The Greater Paris transit network was simulated by 4 variants of the CapTA model. The purpose is to investigate how the various effects contribute in the passengers' path choice and the traffic state of the transit network. These model variants are defined as follows:

 UC: It corresponds to the unbounded model, where no capacity constraints apply. The passenger flow under these free-flow conditions is assigned to the best hyperpath, or the preferred set of paths  CNC: This variant includes the total capacity and platform occupancy constraints, modelled with the transit bottleneck and the frequency modulation models, as described in Leurent et al (2011). Simple applications, such as in Leurent et al (2012) suggest there is a trade-off between waiting time on the platform (due to insufficient vehicle capacity) and in-vehicle comfort. The main global parameters in a CapTA simulation concern the penalty factor to be considered in the generalized cost function. Indeed, the generalized cost of a path will be the sum of the actual travel times for each arc in the path weighted by a penalty factor which depends on the importance of that element to the user's trip. In the simulation we distinguish four different types of cost components: accessegress, transfer, waiting and in-vehicle.

Each one has a different penalty factor, according to the following table: The model was coded in C++ using an object oriented approach. The simulation runs on a 2,66 GHz Intel PC with 4 GB of RAM. The average run time per iteration amounts to 8 minutes for the unbounded model (UC). Each iteration in the capacitated model (CWCF and CWCV)extending the in-vehicle comfort also to the bus servicesrequires about 23 minutes. Within an iteration, the in-vehicle comfort for the buses takes additional 6 minutes and for the guided transport, 7 minutes, for a total computing time of 13 minutes (of the 23 minutes of an iteration) for treating in-vehicle comfort.

The convergence is calculated by the average gap of the passenger flows on each arc. Figure 5 illustrates the convergence of the model variants, CNC, CWCF and CWCV. An acceptable level was reached after 50 iterations with a gap reduced to 1‰ of the initial value. The inclusion of comfort leads to a quicker convergence. For the bounded variants (CNC, CWCF, CWCV), the route choice takes into consideration the effect of the passenger flows on the generalized cost and the path choice due to the local capacity constraints: the vehicle and route total capacity, the seat occupation and the vehicle capacity of the station track. Figure 6 illustrates the passenger flows on the network (line width) and the flow to capacity ratio (colour) on the guided mode lines for the CWCV variant.

In light and dark green are the line segments with a flow up to 75% of total capacity and the yellow and orange the arcs designate a flow to capacity ratio comprised between 75% and 90% and 90% and 100% of the line's capacity respectively. In purple we illustrate the links where the hourly passenger flow exceeds the hourly capacity. However, for the CWCV Furthermore, by comparing the distributions of the unbounded (UC) and CNC models, we observe a similarity for low and medium flow-to-capacity ratios, until the 80%. As for the CNC model variant, a large number of arcscompared to all other variantslies between 80% and 100% of the nominal capacity, suggesting that it successfully reduces the flow of oversaturated arcs, just below their nominal capacity. As with the comfort variants (CWCF and CWCV), the distribution of the arcs has a peak around 35% of the capacity, reflecting the seat capacity. Indeed, the seat capacity corresponds to 40-60% of total vehicle's capacity for rail, 20% for metro and 30% for tramway. Comparing the two comfort variants, we observe higher concentration of arcs around the seat capacity for the CWCF and lower concentration at high flow-to-capacity ratio, than the CWCV model. That steams for the fixed penalty discomfort of the CWCF variant, penalizing all the comfort level, rather than tolerating low standing densities with a variable coefficient such as in CWCV.

The operation of transit routes under capacity constraints

The vehicle flowing along a fixed track considers the effect of passenger flows according to the track occupancy and frequency modulation model, as indicated in Leurent et al (2011).

The model assumes that the operative frequency, z  , of a transit route at a station depends on the dwell time (and therefore the boarding and alighting flows) and the safe separation time between two following vehicles for all vehicles using the track occupancy of all the transit routes sharing the track infrastructure.

The simulation of the Grand Paris transit network allows investigating the behaviour of the bounded variants. We can make two observations with concordance to the theoretic model.

First, due to the initial "free-flow" passenger flows, the frequency modulation happens abruptly at the first intermediate traffic state calculated, due to the initial "free-flow" passenger flow. As we approach the stationary point, the route frequency oscillates around a certain value and seems to approach a stationary point. In Figure 9 we illustrate the relative frequency drop in the central sector of the Greater Paris transit network. While the great majority of the structural transit lines are not affected, a reduction up to 5% of their initial frequency can be observed in lines such as Line 6, 7 and 9 (depending on direction) and the RER C. However, the most sensible lines to frequency modulation, with a reduction over 5% from scheduled frequency are mainly the metro lines.

The RER A eastbound service faces a reduction of its nominal frequency by 7,7% from 30 veh/h to 27,7 veh/h. However, other than the direct reduction of the frequency, it is important to note the secondary effects of the frequency modulation, such as the reduction of the seat and passenger's capacity offered downstream and the increase of the passengers willing to board each train. Indeed, the service capacity on the RER A eastbound service is reduced east of La Defense by 7,8% with a capacity loss downstream of approximately 4500 passengers and 1400 seats per hour. That corresponds to the equivalent capacity of 1,7 duplex highcapacity trainsets.

Impacts on users

The average generalized cost on the transit network includes the waiting and in-vehicle time as well as the walking time needed for a transfer and the access-egress time. In Tableau 5, we resume the average generalized time for the model variants and further detail their elements.

We analyse the composition of the average optimal generalized time (GT) for the CWCV model variant. By waiting time we consider the initial waiting time for the access to the network and any further waiting time due to transfer, which corresponds to the 29,1% of total GT. The most important element is the in-vehicle travel time with 41,5% of total GT, while the transfer is only 5,6% and the accessegress time forms the 23,8% of the total GT. We observe that in the CWCV variant the average generalized time for a journey on the network increases by 11,2% in comparison to the unbounded model (UC). The in-vehicle travel time faces a significant increase (by 26% and 23% for the CWCF and CWCV variants) in comparison to the UC (and the CNC) variant since the former variants include in-vehicle discomfort penalties. After all, 3/4 of the increase of the generalized travel time is attributed to the in-vehicle comfort. On the other hand, the increase in the waiting time is modest, reflecting the sufficient overall capacity of the transit network. That value is a weighted average of all the transit modes and includes the buses where no capacity effects are being applied (except in-vehicle comfort). However, the increase in the waiting time (in the CWCV variant) implies that approximately 14 800 hours are spent in additional queuing over the morning peak hour.

Excess passenger flows have an impact to the waiting time on the transit routes. However, many transit lines have some available capacity, suggesting that overall capacity of the transit network is sufficient. Congestion is concentrated on a number of lines, inducing a considerable increase in the waiting time. The average waiting time of the metro line 1 eastbound service increases by 14% (mainly due to the reduced capacity from the frequency modulation), while for the southbound line 11 increases by 22% and for both directions of line 14 there is an increase around 3%. These effects are considerable, as they correspond to an additional waiting time of 230h for the users of eastbound line 1 and 130h for the users of southbound line 11, during the morning peak hour.

Applying the capacity constraints to a simulation modifies significantly the distribution of the passenger flows on the transit lines. Figure 10 (left hand side) illustrates the total number of passengers travelling on each line during the simulation period for the unbounded (UC, in blue) and the bounded model (CWCV, in brown). We observe a reduction of the passenger flows on the second case. At the right hand side, the effect on the waiting time is illustrated, where passengers willing to board at the platform face the available capacity. The increase in the average waiting time is moderate (until 5%), except the eastbound RER A (+76%), the southbound M13 (+19%), M11 (+22%) and the eastbound M1 service (+14%). That suggests that a transit assignment model with capacity constraints, such as CapTA, succeeds to spread the passenger flows to alternative paths (if they exist), while it can evaluate the effect of punctually insufficient capacity.

Impact of in-vehicle comfort

As stated previously, the generalized time (and the path choice) seems to be strictly impacted by the in-vehicle comfort. Since the current transit network offers sufficient overall capacity, the transit bottleneck exists only punctually, at certain station and lines, indicating a semicongested traffic state (where at a platform at least one route is congested, while not all the available capacity is used). For these reasons, the in-vehicle comfort, which impacts the bus as well as the rail services, plays a more important role on the path choice. The comfort allocation model measures the number of standing passenger as well as their average density, in order to designate various levels of discomfort.

The impact of the in-vehicle comfort is significant. Standing passengers can be found in the tramlines, the metro, the RER and CR lines. However, due to the linear discomfort function of the central model variable (CWCV), the additional cost depends on the density of the standing passengers. The additional cost of an average trip (for sitting and standing passengers) on the metro lines varies from 27% of the average actual travel time for line 10 to 68% for the heavy-loaded line 14. While that value is high for line 14, the average standing time for a passenger varies only from 2,5 to 4,5 minutes according to the direction. Figure 11 illustrates the average sitting time for a trip and the average time a passenger travels standing for the UC and CWCV model variants. The impact of standing discomfort is higher for longer lines, such as M8, where if a passenger stands at any moment during the trip, he will stay in that comfort state on average 7,5 minutes (CWCV model) before sitting or getting off. The figure also demonstrates that the average sitting time increases in the case of the CWCV model (where passengers are sensible to in-vehicle comfort). That is a straightforward result, though it can be attributed both to the reduced number of transfers (-5%), since the transfer risk incites them to stay longer if seated, but also to reduced pressure for getting a seat. Therefore, the combination of fewer standing passengers due to the bounded passenger flow at the line model, and an equivalent number of sitting passengers that exit each station, since those who succeeded to sit may have boarded when the total capacity effect didn't affect the boarding flows, increases the probability of getting a seat at any moment of the trip.

Conclusion

The paper offers a description of the CapTA transit assignment models for capacitated networks together with its application to the Great Paris Region. It is based on the line model as a framework to represent a variety of features and phenomena in a transit system, both of physical and microscopic nature. The bi-layer network representation allows focusing on a quasi-microscopic level when considering the flow loading and line costing process at a line level, while maintaining the macroscopic level for the passenger flow assignment to the transit network. The framework is essentially systemic and modular: some parts of it may be replaced by mode appropriate sub-models, for instance about track occupancy, or the interaction of access and egress flows in station dwelling.

The transit network of the Grand Paris Region with 4 tramlines, 14 metro lines and 13 commuter rail lines and a central core with line redundancies offers an ideal field for applying a transit assignment model with capacity constraints. Massive passenger flows are concentrated on main north-south lines, the RER B and metro line 13 and east-west axes such as the RER A and metro line 1 and 14. The bounded model variants (CNC, CWCF, CWCV) manage to disperse the passenger flows transiting from the congested lines to alternative paths, whereas the flow to total capacity ratio exceeds 100% only punctually, for certain line segments, by no more than 3,7% of the line capacity (for CWCV).

The high passenger flow impacts the operation of the transit routes and the frequency is modulated in most of the metro lines of the Paris network. The frequency is reduced up to 15 and 19% for the metro lines 14 and 1 respectively, inducing secondary effects along the lines due to the reduced downstream capacity and the increased passenger stock for each vehicle.

On the passenger side, these effects contribute to the increase of the average waiting time up to 14% and 22% for the line 1 and 11 respectively. Even though, the increase seems moderate, it corresponds, only for eastbound direction of line 1 to additional 230 actual hours waiting during the morning peak hour. In addition to longer waiting times, the passengers face invehicle discomfort when they travel standing. The average travel time a passenger stands depends on the topology and congestion of the line and therefore lines without excessive passenger flows may have the longest standing time, such as line 8 where it takes values from 5,5 to 7,5 minutes according to the direction. The computation time can be reduced if we treat in parallel order the multiple independent processes treated sequentially. Other than the computation efficiency, the model, being modular, can be further developed. A more detailed interaction may be considered between the boarding and alighting flows, the in-vehicle passenger load and passenger stock at the platform as well the vehicle's and platform's architecture and how these components influence the dwell time. Further microscopic phenomena can be added, such as a willingness to board an overcrowded vehicle, if the available capacity is insufficient and the passenger stock is too important, thus affecting the in-vehicle discomfort of on-board passengers.

Finally, additional models may be added, first, within the line model, by considering the effect of general traffic conditions to the vehicle's journey time and second, by developing a station model to capture the effect of passenger flows on the quality and travel time of transfers and access-egress trips.

Version

  Demand in the Greater ParisAlong with its big population, the Greater Paris accommodates massive transport flows.

Figure 1

 1 Figure 1 Modal Share of motorized trips by geographic relation (source: OMNIL, 2012)

Figure 2 :

 2 Figure 2: The map of the zones of the Greater Paris Region with Paris in the centre

Figure 3

 3 Figure 3 illustrates the line capacity per transit mode on the central section of the Greater Paris transit network. The green and red lines designate the commuter rail and RER, while the blue line corresponds to the metro lines.

Figure 3 :

 3 Figure 3: The total capacity of the transit lines, by transport mode (central sector)

  dual representation of the transit services is achieved by creating the transit subgraph; a line leg is added between each station couple within the line. Tableau 3 resumes the service network used as input for the assignment model. We observe that by substituting the line legs to the service arcs on the transit lines, there is only a slight increase of the link elements (+3,8%). In other words, some 19 560 transit arcs (boarding, in-vehicle sojourn and interstation and alighting arcs) are replaced by 30 729 line legs (+57%) that connect the station couples within each transit line. The number of line legs is sensible only to the number of stations on a transit line, whereas the arcs also depend on the number of alternative transit services within a transit line.

  It includes all the capacity constraints included in CapTA, namely, the total capacity and frequency modulation for guided transit (rail, metro, tramway) and the in-vehicle comfort for all the transit modes (guided transit and buses). The penalty factor for in-vehicle comfort is fixed for any density of on-board standing passengers  CWVC: Equivalently to the previous variant, all capacity constraints are applied.However, the in-vehicle comfort factor is variable, increasing linearly from the first standing passenger until the standing density of crush capacity. It is considered the central variant of the model. If not stated otherwise, the results of the bounded model correspond to the CWCV model variant.

  the in-vehicle comfort, we assume two distinct comfort states, standing and sitting. A fixed comfort penalty will penalize the trip for a medium load, contributing to a dispersion of the passenger flows to many transit paths. The fixed comfort coefficient is equal to 1,8 of the in-vehicle seating time, as suggested in Liu (2009). However, some researches(TRB, 2003, STIF, 2007) suggest that the penalty coefficient depends on the density of standing passengers. Therefore, we assume a linear function of the standing penalty factor ) density of standing passengers for a certain trip segment a . The CWCV variant adopts a standing penalty coefficient varying from 1,2 (for 0 

Figure 4

 4 Figure 4 The standing comfort penalty as a function of the density of standing passengers

Figure 5

 5 Figure 5 Convergence Indicator of the bounded model variants

  are limited (9 out of 1750) and the highest flow exceeds line capacity by only 3,75%. It is apparent that by applying the capacity constraints, the passengers faced with additional waiting time, due to the transit bottleneck model and in-vehicle discomfort, choose to transfer to alternative paths with lower congestion.

Figure 6 :

 6 Figure 6: Passenger flows and the ration between flow and capacity for the bounded model

Figure 7 :

 7 Figure 7: Number of Arcs in relation to flow/capacity ratio

Figure 8 :

 8 Figure 8: The initial and modulated frequency at the terminal for some rail lines in the Greater Paris transit network.

Figure 9

 9 Figure 9 The relative frequency drop due to the frequency modulation in the central sector of the Greater Paris

Figure 10 :

 10 Figure 10: Passenger Flows and Average Perceived Waiting Time on selected lines for the unbounded (UC) and bounded (CWCV) model

Figure 11 :

 11 Figure 11: Average Sitting and Standing time on selected lines for the unbounded (UC) and the bounded model (CWCV)

Tableau 1 : The characteristics of the Greater Paris transit system Transit Mode Lines Station or stops Total length (km)

	Rail	13	443	1401
	Metro	16	301	215
	Tram	4	71	42
	Bus	1372	30100	23263
	VAL	2	8	11

Tableau 3: The graph elements of the service network Service Network Elements

	Initial Nodes	17 413
	Service Network Nodes	159 447
	Initial Arcs	64 558
	Standard Arcs Representation	296 525
	Line Legs	30 729
	Total

Legs and Arcs (for assignment) 307 694

Tableau 5 : Average generalized time (in minutes) on the Greater Paris transit network

							16/10/2012
	Model	Optimal	Actual	Perceived	Perceived	Perceived	Perceived	Nb of
		TT	TT	WT	IVTT	Transfer T	Access-Egress	Transfers
	UC	61,56	40,63	18,79	23,10	3,96	15,71	1,42
	CNC	62,73	41,40	19,44	23,65	3,98	15,67	1,44
	CWCF	69,96	41,77	20,02	29,02	3,97	16,95	1,35
	CWCV	68,45	41,70	19,90	28,40	3,88	16,27	1,35
	%diff CWCV-UC	11,2%	2,63%	5,9%	23%	-2,04%	3,6%	-5,13%
	ECH							15/21
	31/10/2012

  Note sur la capacité du matériel roulant et son affectation sur le réseau francilien, Working Document, Ecole Nationale des Ponts et Chaussées,

		Date	Type	Remarques
	0	24/05/2012 Rédaction	Première version
	1	19/09/2012 Rédaction	Modifications depuis ETC_IDF
	2	16/10/2012 Correction	Correction et mise en cohésion
	10 References
	[ 1 ]	Le Figaro, 2010, Les franciliens souffrent de leurs transports en commun, Le
	Figaro report on 02/03/2010 <http://www.lefigaro.fr/entreprise/2010/03/02/05011-
	20100302ARTFIG00516-les-franciliens-souffrent-de-leurs-transports-en-commun-
	.php> (accessed on June 2012)
	[ 2 ]	INSEE, 2012 Population
	[ 3 ]	DREIF, 2004, Les déplacements des Franciliens en 2001-2002
	[ 4 ] Chandakas E (2012), Université Paris Est
	[ 5 ]	Liu K (2009) Thèse

II.

Semi-congested regime: at least one service is saturated, while others have still some capacity available to accommodate the additional flow. The accessegress flow is assigned to the alternative services within the reference period H . Both the expected waiting time and the in-vehicle travel time are increased.

III.

Congested regime: all the services are saturated. The accessegress flow is x cannot be served within the reference period, H . Insufficient capacity results in a significant increase in the expected waiting time by accessegress pair.


Martín Barrère
email: barrere@inria.fr

Rémi Badonnel
email: badonnel@inria.fr

Olivier Festor
email: festor@inria.fr

Towards the Assessment of Distributed Vulnerabilities in Autonomic Networks and Systems

Vulnerability management constitutes a crucial activity within autonomic networks and systems. Distributed vulnerabilities must be assessed over a consolidated view of the network in order to detect vulnerable states that may simultaneously involve two or more devices. In this work, we present a novel approach for describing and assessing distributed vulnerabilities in such self-governed environments. We put forward a mathematical construction for defining distributed vulnerabilities as well as an extension of the OVAL language called DOVAL for describing them. We then define a framework for assessing distributed vulnerabilities in autonomic environments that exploits the knowledge provided by such descriptions. We finally show the feasibility of our solution by analyzing the behavior of the proposed algorithms and strategies through a comprehensive set of experiments.

I. INTRODUCTION

Autonomic computing provides a promising paradigm for dealing with large scale network management [START_REF] Kephart | The Vision of Autonomic Computing[END_REF], [START_REF]An Architectural Blueprint For Autonomic Computing[END_REF]. In this context, autonomic networks and systems are responsible for their own management. They have to adapt their configurations with respect to their environment, to protect themselves against security attacks, to repair their own failures, and to optimize their various parameters. In order to achieve these objectives, autonomic related operations are performed modifying the environment. Such operations may lead to potential vulnerable states increasing the exposure to security threats. This article addresses the ability of autonomic networks and systems to deal with security issues, particularly, to detect distributed vulnerabilities and maintain safe configurations across the network.

As systems and technologies evolve, new space for vulnerabilities comes into scene. Autonomic networks must integrate support mechanisms for preventing vulnerabilities. Nowadays, networks are analyzed in order to detect vulnerabilities that may allow a malicious user to perform an attack. However, traditional mechanisms perform a global analysis by investigating each network element individually. Even though such approaches can detect sets of vulnerabilities that may allow an attacker to perform a multi-step attack, they do not provide the capability of detecting vulnerabilities that simultaneously involve two or more devices under specific conditions. The underlying problem relies in that each network device can individually present a secure state, but when combined across the network, a global vulnerable state may be produced.

In order to cope with this problem, several issues must be attended. Formal mechanisms for describing distributed vulnerabilities are required. Moreover, using standard means for achieving such objective can promote the exchange of security knowledge among practitioners and organizations. Such descriptions in turn must be integrated into the management plane of autonomic networks and systems. Mechanisms for interpreting and assessing theses security advisories must be provided. In addition, optimized algorithms and strategies for collaboratively assessing the network should be developed.

In this paper, we present a framework for describing and assessing distributed vulnerabilities in autonomic networks and systems. We put forward mechanisms for specifying distributed vulnerable states that are taken into account by the proposed framework thus increasing the vulnerability awareness of such self-governed environments. We also perform an analytical and technical evaluation of the proposed approach in order to analyze and show the feasibility of our solution. Our main contributions are: (1) a mathematical approach and an OVAL-based specification language allowing to describe distributed vulnerabilities independently of the technology used to its assessment, (2) a deployable infrastructure based on the Cfengine system, capable of enforcing the assessment and reporting of distributed vulnerabilities as security policies, (3) optimized algorithms and strategies for evaluating such security threats in the underlying network.

The remainder of this paper is organized as follows. Section II describes existing work and their limits to address complex vulnerability management. Section III presents the proposed approach for specifying distributed vulnerabilities in autonomic networks and systems. The architecture of our framework as well as the proposed algorithms and strategies for the assessment of distributed vulnerabilities are described in Section IV. Section V provides an evaluation of our solution through a comprehensive set of experiments and the obtained results. Section VI presents conclusions and future work.

II. RELATED WORK

Vulnerability management refers to the cyclical practice of identifying, classifying, remediating and mitigating vulnerabilities [START_REF] Foreman | Vulnerability Management[END_REF]. The ability of identifying host-based and distributed vulnerabilities constitutes the first step for such process to be completely embedded into the management plane of autonomic networks and systems.

Currently, several network scanners exist for assessing vulnerabilities on a target network [START_REF]Nessus[END_REF], [START_REF]OpenVAS[END_REF]. Some of them use the functionalities provided by powerful port scanners such as Nmap [6]. However, these tools do not provide standard means for describing and exchanging the vulnerabilities they are able to assess. The OVAL 1 language [START_REF]OVAL Language[END_REF], introduced by the MITRE corporation [4], is an information security community effort to standardize how to assess and report upon the machine state of computer systems. OVAL is an XML-based language that allows to express specific machine states such as vulnerabilities, configuration settings or patch states. Real analysis is performed by OVAL interpreters such as Ovaldi [START_REF] Ovaldi | the OVAL Interpreter Reference Implementation[END_REF] and XOvaldi [START_REF] Barrère | Towards Machine-assisted Formal Procedures for the Collection of Digital Evidence[END_REF]. Related technologies such as the XCCDF 2 language [START_REF] Ziring | Specification for the Extensible Configuration Checklist Description Format[END_REF], included in the SCAP 3 protocol [START_REF] Banghart | The Technical Specification for the Security Content Automation Protocol (SCAP)[END_REF], can be used for several purposes, including automating vulnerability checking, technical control compliance activities, and security measurement. XCCDF is a promising host-targeted language that can be used for expressing actions to take when a vulnerable condition is observed.

In our previous work, we proposed an OVAL-based approach for increasing vulnerability awareness in self-governed environments [START_REF] Barrère | Supporting Vulnerability Awareness in Autonomic Networks and Systems with OVAL[END_REF] that relies on the Cfengine tool [1], an autonomic maintenance system that provides support for automating the management of large-scale environments based on high-level policies. The proposed framework promotes the capitalization of external knowledge provided by OVAL repositories enabling autonomic environments to take into account such security advisories when self-management operations are performed. These operations in turn may perform changes on their environments producing unsafe states, thus change and risk management techniques must be considered [2], [START_REF] Diao | Predicting Labor Cost through IT Management Complexity Metrics[END_REF], [START_REF] Chiarini | Dynamic Dependencies and Performance Improvement[END_REF].

Several approaches also consider the idea of modeling a network intrusion as a sequence of steps where each gained privilege by the attacker opens new intrusion capabilities in the network [START_REF] Wang | OVM: An Ontology for Vulnerability Management[END_REF], [START_REF] Pandey | ACML: Capability Based Attack Modeling Language[END_REF], [START_REF] Templeton | A Requires/Provides Model for Computer Attacks[END_REF]. This concept provides robust foundations for attack graphs, a widely used approach for performing network vulnerability analysis as reported in [START_REF] Ammann | Scalable, Graph-Based Network Vulnerability Analysis[END_REF], [START_REF] Ou | MulVAL: A Logic-Based Network Security Analyzer[END_REF], [START_REF] Ou | A Scalable Approach to Attack Graph Generation[END_REF]. However, these approaches do not consider global vulnerable states produced by a simultaneous combination of network devices under certain conditions, thus uniform means for describing distributed vulnerabilities, analyzing and detecting them are deeply required as they provide essential building blocks for dealing with the vulnerability management process within autonomic networks and systems.

III. SPECIFICATION OF DISTRIBUTED VULNERABILITIES

This work is focused on describing and assessing distributed vulnerabilities. However, during our research, a recurrent question used to come up about the actual definition of a distributed vulnerability. In this section, we introduce a mathematical definition for distributed vulnerabilities and we present DOVAL, a language for describing such vulnerabilities in a machine-readable manner. 1 Open Vulnerability and Assessment Language 2 eXtensible Configuration Checklist Description Format 3 Security Content Automation Protocol

A. Distributed vulnerabilities

The concept of a distributed vulnerability may usually be understood as a set of individual vulnerabilities distributed in the network that potentially might allow a multi-step attack. We think that even though this definition provides a useful perspective to the topic in question, it does not offer a complete outlook of the problem. We consider a distributed vulnerability as a set of conditions over two or more network devices that if observed simultaneously, then a potential exploitable threat is present on the network under analysis. The main difference between considering a set of individual vulnerabilities over different network devices and the proposed definition is that the required conditions to be observed over one network device may not constitute a complete vulnerability description. We now present some required definitions in order to mathematically specify a distributed vulnerability:

• H = {h 1 , ..., h m } denotes the set of devices in the network (e.g. hosts, routers).

• R = {(h i , ..., h j ) * } denotes the set of relationships between devices in the network (e.g. reachability, service provisioning).

• P = {p 1 , ..., p n } denotes the set of device properties (unary predicates p i (h j )) required to be observed for the distributed vulnerability to be present in the network under analysis.

• P H = {s 1 , ..., s k } denotes the set of subsets of P where s j = (P ) = {p i * }, i ∈ {1, ..., n}. s j denotes the set of properties, called role, required to be observed on one specific device.

• P R = {r 1 , ..., r v } denotes the set of relationships between devices (n-ary predicates r i (h i , ..., h j )) required to be observed for the distributed vulnerability to be present in the network under analysis.

Based on the previous definitions, we define a distributed vulnerability DV as the compliant projection of the pattern (P H , P R ) over the network (H, R) as illustrated in Figure 1.

B. DOVAL, a distributed vulnerability description language

We have conceived the DOVAL language (Distributed OVAL) on top of OVAL as a means for expressing the proposed mathematical approach in a machine-readable manner.

The OVAL perspective can be seen as a host-based approach, capable of describing specific host states independently. DOVAL leverages the OVAL language by providing mechanisms for describing vulnerabilities that involve two or more network devices at the same time. While the universe of discourse in the OVAL language is composed by digital components (e.g. processes, files), DOVAL extends it by considering network devices as well. In addition, we extend the semantic of the language by allowing to express relationships between objects in order to describe conditions involving several devices simultaneously. In this manner we can for instance specify that a network is vulnerable, if a given traffic between specific processes and devices is allowed.

Within the DOVAL language, the required conditions over each involved device are described using standard OVAL definitions. An OVAL definition is intended to describe a specific machine state using a logical combination of tests that must be performed over a host. If such logical combination is observed, then the specified state is present on that host (e.g. vulnerability, specific configuration) [START_REF]OVAL Language[END_REF]. Under a logical perspective, this combination can be understood as a first order formula where each test corresponds to an atomic unary predicate over that system [START_REF] Barrère | Supporting Vulnerability Awareness in Autonomic Networks and Systems with OVAL[END_REF]. DOVAL extends this concept by enabling the expression of predicates that involve more than one device, thus allowing the specification of required relationships over the network. Figure 2 depicts the main DOVAL constructs and provides a description of the intended purpose of each main building block. A DOVAL document is intended to meet the specification of several components required to describe a set of distributed vulnerabilities. Each distributed vulnerability is specified by a DOVAL definition, which provides the capability of expressing a logical formula that involves several DOVAL tests. Each DOVAL test in turn constitutes the container of an n-ary predicate over a set of network devices (h i , ..., h j ) and it is in charge of putting together the required devices and the states expected to be observed between them.

We consider a required network device as a device that meets certain conditions (s j ) and that is required to be present for the distributed vulnerability DV to be true in the network under analysis (H, R). Required network devices (P H ) are described by means of DOVAL objects. In order to express DOVAL objects, we take advantage of the very final objective of the OVAL language, this is to say, to express specific machine states. Thus, a DOVAL object is actually a set of references to OVAL definitions, where each one describes a required specific machine state (p i ) on that device. Finally, the expected relationships over the network (P R ) are expressed using DOVAL states. A DOVAL state (r i ) specifies properties between devices and the roles each device has within such relationship, and can be seen as an actual predicate itself.

There exist several situations where neither individual host assessments nor inference chains over individual exploitable vulnerabilities can expose potential security threats in a wide network. Mechanisms for globally specifying and evaluating network distributed vulnerabilities are essential.

C. A case study

We motivate the use of the DOVAL language by considering the scenario described in [START_REF] Zhang | Denial of Service Attack and Prevention on SIP VoIP Infrastructures using DNS Flooding[END_REF] and depicted in Figure 3 where two related hosts, a SIP4 server and a DNS5 server, each one with specific properties, constitute a potential exploitable network vulnerability.

Fig. 3: Distributed vulnerability scenario

In this example, a denial of service (DoS) attack over the SIP server can be performed by flooding it with unresolvable domain names that must be solved by a local DNS server. The local DNS server in turn, is configured for requesting the resolution of unknown domains to external servers, increasing the number of waiting requests and therefore the response time for each SIP request. Under these configuration states, flooding a SIP server with such type of messages will prevent it to respond to legitimate requests. It is important to highlight that both servers and the relationship between them are required conditions for the distributed vulnerability to be present. If the DNS server is not present or it is not compliant with the required specific conditions, the SIP server would immediately respond to a SIP client that its SIP request has failed.

Even in such a situation, thousands of SIP requests may collapse the SIP server anyway, though it is a slightly different scenario that could be specified using standard OVAL definitions. On the other hand, if there is no SIP server, it is quite clear that the distributed vulnerability has no place in this environment. Such scenario can be specified using the DOVAL language as illustrated in Listing 1. A DOVAL definition with id "doval:fr.inria.doval:def:1" identifies which DOVAL tests must be performed in order to detect the distributed vulnerability that such definition is intended to describe. The DOVAL test with id "doval:fr.inria.doval:tst:4141" identifies the required devices as DOVAL objects and the relationships between them by referencing DOVAL states. The required devices, namely a SIP server with no flooding protection (s 1 ) and a local DNS server with external unknown domain resolution (s 2 ), are specified using two DOVAL objects, "doval:fr.inria.doval:dev:222" and "doval:fr.inria.doval:dev:256" respectively. Each DOVAL object enforces the required properties over the device it describes by considering a set of OVAL definitions, one for each needed condition. Each DOVAL state specifies the characteristics of the relationship expected to be observed between both devices.

Within the current example, two relationships are required: (1) DNS traffic is allowed between the SIP server and the DNS server (r 1 ), specified by a DOVAL link state with id "doval:fr.inria.doval:ste:4444", and (2) the SIP server has configured the DNS server as its DNS service provider (r 2 ), specified by a DOVAL service state with id "doval:fr.inria.doval:ste:7777". In order to assess such a specification, a deployable distributed infrastructure capable of enforcing its evaluation and notification is required.

IV. A FRAMEWORK FOR ASSESSING DISTRIBUTED

VULNERABILITIES

The main objective of DOVAL is targeted on describing conditions involving several network devices that if observed, the underlying network presents a vulnerable state that can be exploited by an attacker. In order to detect such scenarios, DOVAL descriptions must be interpreted and evaluated on the target network. We propose a framework based on Cfengine, a widely deployed configuration and administration system, capable of enforcing security policies for discovering distributed vulnerabilities across the network.

A. Architecture overview

Due to the size and dynamics of current networks, the assessment and detection of vulnerable distributed states is not a trivial task. We partition the problem into several steps, namely, (1) generation of a minimized loop-free topology of the underlying network, (2) collection of hosts and network information, and (3) assessment of DOVAL specifications over the gathered data. Figure 4 illustrates the steps and the architecture of the proposed approach. Fig. 4: Overall architecture Within this architecture, distributed vulnerabilities are specified using the DOVAL language and stored in a database. A Cfengine server is fed with such knowledge and translated as Cfengine policy rules. Our approach considers a deployment of Cfengine agents across the network, where each agent is in charge of controlling one network device. In order to evaluate the existence of a distributed vulnerability, a spanning tree is built on top of the target network in order to minimize paths and avoid loops. The DOVAL specification is then transmitted across the tree and the required information is gathered by performing an aggregation algorithm over the nodes. Each Cfengine agent assesses the device it controls in order to discover which roles such device can play within the distributed vulnerability specification. This information is returned back until all the information is stored at the root node of the spanning tree. Finally, the specification of the distributed vulnerability is projected over the information gathered from the network, and a DOVAL report is generated informing about distributed vulnerable states across the network.

B. Assessment strategies

Several strategies for assessing the required properties on each network device can be used. Considering the number of potential combinations, an optimized algorithm for evaluating the network is required. Within our approach, we consider the aggregation algorithm proposed in [START_REF] Burgess | Network Patterns in Cfengine and Scalable Data Aggregation[END_REF] for building a treebased overlay network with the information of each device in the network under analysis. We now proceed to explain our strategy in a constructive manner considering two situations. The first situation presents a simplified scenario where exists full connectivity between each pair of nodes in the network and no further relationships between nodes are required. The second situation puts forward a more realistic scenario that extends the first one by considering network constraints such as reachability restrictions or service provisioning requirements.

When starting a DOVAL definition assessment, the set of required devices for the distributed vulnerability to be present can be seen as an empty tuple t = ( 1 , 2 , ..., k ). Each blank field represents the placeholder for a required role characterized by P H = {s 1 , ..., s k } according to the definitions given in Section III-A. During the assessment across the spanning tree, t will be collaboratively fulfilled as each Cfengine agent will indicate which of these fields the device it controls can play. At the end, several combinations can occur thus the final computation will be performed over a set T = {t 1 , ..., t w }. Let DV be a distributed vulnerability where t = { s1 , s2 , s3 } specifies the set of roles required to be observed in the network. Figure 5 depicts the steps taken during the algorithm execution for discovering the roles each network device is able to play. At the initial step, a spanning tree covering every node in the network is considered. The tree is explored using a post-order traversal. At Step 1, the node h4 is assessed reporting that it matches roles s1 and s3. Then, the node h2 fulfills its temporal role list and continues with the node h5 as shown in Step 2. At Step 3, h2 is assessed in order to detect which roles it can play and the role list for the sub-tree with root h2 is returned to the caller h1. The node h3 is assessed at Step 4 identifying its ability to perform the role s2. At Step 5, the temporal role list describes the roles that the nodes h2, h3, h4 and h5 are able to play. The assessment of the node h1 will complete the role list indicating that role s1 can be performed by the nodes h4 and h5, whereas the role s2 can be performed by h1, h3 and h5, and s3 by h1 and h4.

Fig. 5: Aggregation algorithm execution for role discovery

Usually, networks present complex topologies imposing reachability restrictions. We consider such constraints in the second situation, where distributed vulnerabilities require the existence of relationships among the involved network devices such as reachability or service provisioning. Under a logical perspective, a distributed vulnerability involving n roles may require at most the evaluation of n-ary predicates r i (h 1 , ..., h n ) where each device h i covers one specific role though it could cover more than one at the same time. Such scenarios require not only to discover the roles that each network device is able to play but also to assess the relationships between them. In order to deal with these more realistic situations, we extend the previous algorithm by performing a neighborhood discovery at each node and assessing the relationships each node supports with its neighbors. The idea behind this approach is to reduce the participation of nodes that can endorse an expected role but they do not satisfy the required relationships with other nodes. Considering the example given in Section III-B, the fact of finding a SIP server h 1 and a DNS server h 2 under the required conditions does not mean that the distributed vulnerability is necessarily present. For instance, if DNS traffic is not allowed between them, the predicate r 1 (h 1 , h 2 ) does not hold; then such pair of network devices does not constitute a candidate combination for the distributed vulnerability. In order to analyze the surrounding environment at each node, we take advantage of Cfengine's functionalities for performing a neighborhood discovery [START_REF] Burgess | Network Patterns in Cfengine and Scalable Data Aggregation[END_REF]. The process described by Algorithm 1 depicts the steps performed by each Cfengine agent while assessing the roles the device can play as well as the required relationships it supports with its neighbors. Algorithm 1: Node roles and relationships assessment Within our approach, a DOVAL object describes the required properties (s) that must be observed over a network device (h) that is part of a distributed vulnerability. Each device compliant with such description is able to perform the object's intended role. The proposed algorithm is executed on each agent and analyzes every role (line 1) the device it controls can perform. For each supported role (line 2), its neighbors are stored in the set N (line 3) and the required relationships are assessed against them (line 4). Such relationships are described by means of DOVAL states and they can be seen as predicates involving w network devices. Only those relationships involving the current role s are assessed (line 5). Depending on the arity of the predicate (line 6), subsets of w -1 network devices are built (line 7) and the relationship among them is assessed (line 8). If such relationship holds, a tuple is added in the output list (line 10) indicating that the node n is able to perform the role s, and that under that role, the relationship r (described by a DOVAL state) holds when considering devices (h 2 , ..., h w ) performing potential roles (s 2 , ..., s w ) respectively. The actual verification of devices (h 2 , ..., h w ) performing roles (s 2 , ..., s w ) is done at the end, when each node in the spanning tree has been evaluated and the root node has all the required information for the assessment of the distributed vulnerability in the network.

V. PERFORMANCE EVALUATION

In this section we present an analytical evaluation and a technical discussion of the proposed approach. We put forward the specification of two metrics in order to analyze the performance during the evaluation of a generic distributed vulnerability, namely, (1) the number of messages sent across the network, and (2) the total time required for the assessment. We also show the scalability of the proposed approach by modeling different scenarios based on the instantiation of various parameters within the specified metrics.

Let N be the network under analysis with a set of devices H = {h 1 , ..., h n } and relationships R = {(h i , ..., h j ) * }. Let DV be a distributed vulnerability that requires a set of k roles defined by P H = {s 1 , ..., s k } and v relationships defined by the set P R = {r 1 , ..., r v }. We consider the following assumptions during the assessment of DV over N :

• a binary spanning tree is built on top of N ,

• each device h has in average q neighbors, • each predicate r i has in average arity b (we define the variable a = b -1 in order to simplify the equations),

• the probability for a device to play a role s j (event A) is given by P (A) = α,

• the probability for a role s j to occur on a predicate r i (event B) is given by P (B) = β,

• the evaluation of any role s j over any device h takes in average γ units of time,

• the evaluation of any predicate r i takes in average δ units of time.

Number of messages.

In order to analyze the traffic generated across the network, we consider the number of messages sent during the evaluation of a generic distributed vulnerability DV . We define the metric M that estimates the amount of messages transmitted as follows:

M = n * (1 + k * P (A) * P (B|A) * v * M pred )
where M pred = P R (q + 1, a) * a = (q + 1) a * a When traversing the spanning tree (n nodes), each node receives one message in order to start its own evaluation. At each node, k roles must be evaluated. Because not every device will play every role, we model this uncertainty as an event A that occur with probability 6 P (A) = α. Given the event A for a role s j , we model the probability of such role to be involved on each predicate r i by considering the conditional probability P (B|A) = β and the multiplier v. The final factor M pred represents an upper bound of the number of messages sent when evaluating one single predicate among the node under analysis and its neighbors. P R (q + 1, a) denotes the number of a-permutations with repetition of a set of q neighbors plus the node itself. For each possible permutation that may fulfill the arguments (roles) required by the predicate under analysis, a messages must be sent. M pred represents an upper bound because we consider that multiple roles can be covered by one single device, which means that for those combinations assigning for instance the same device to each role, only one instead of a messages will be sent.

Assessment time.

We analyze here two distributed approaches that have a direct impact on the total assessment time for a distributed vulnerability DV . The first one consists on sequentially assessing the network, analyzing one node at a time. In this case, we define the total assessment time as:

T S = n * k * (γ + P (A) * P (B|A) * v * T pred )
where T pred = δ * P R (q + 1, a) = δ * (q + 1) a

For each node in the network, k roles are evaluated where each one takes γ units of time. The probability for the node to perform a role is given by P (A) whereas P (B|A) defines the probability for that role to be involved on each one of the v predicates. T pred involves the same permutations among neighbors as M pred does, but for each possible sequence T pred considers the parameter δ that models the average time for evaluating a predicate r i .

An alternative to the sequential modality consists on using a parallel computing approach. Such approach enables the evaluation of every node simultaneously thus reducing the sequential assessment time. Under this perspective, the total assessment time becomes:

T P = max node (k * (γ + P (A) * P (B|A) * v * T pred ))
and the worst case is:

T P w = k * (γ v * T pred )
T P w describes the extreme case where a node is able to perform every required role that in turn is involved in each predicate. Such case maximizes the amount of time among the times required by the nodes in the spanning tree.

The proposed metrics have several parameters that affect the final result such as the number of nodes (n) or the probability for an arbitrary node to play a given role (P (A)). Typical scenarios usually involve predicates conceived as peer to peer properties (binary predicates, a = 1) as well as a restricted number of roles (small k). Each required predicate in turn usually involves all roles, thus simplifying conditional probabilities (P (B|A) = 1). Under this perspective, we have performed several experiments using the example illustrated at Section III-B as a case study in order to analyze the behavior of our approach. In this scenario we have k = 2, v = 2, a = 1 and q = n -1 depicting a full mesh network. We have also simplified the units of time considering γ = δ = 1. Networks nature can vary depending on the context and the purpose they have been built for. Therefore, we use the parameters n and P (A) for analyzing such situations. The experiment depicted in Figure 6 considers a uniform distribution for role assignment (P (A) = 1 n ), meaning that only one of n nodes may play a given role s j . These curves depict how much grows the number of messages (solid line) as well as the assessment time under a sequential computing approach (dotted line) and a parallel computing approach (dashed line) when the number Fig. 6: Statistics with uniform distribution on role assignment of nodes in the network becomes bigger. We can observe a proportional growth on every metric (M , T S , T P w ) under a constant rate. This is easily verifiable by looking at the inner graph of Figure 6 that shows the first derivatives of each curve.

Considering that only one device can perform a required role may apply just on special cases so we have analyzed the behavior of our approach when increasing the number of potential devices able to perform the required roles. This is achieved by modifying the probability for a device to play a role (P (A)) as shown in Figure 7. We observe that even though the assessment time using a sequential approach is not linear, its growth rate illustrated in the inner graph of Figure 7 remains linear. We get a maximum assessment time when P (A) = 1 (dotted line) because every node is able to play every role. When P (A) = 1 2 (solid line), a half of the network can perform each role and the assessment time is lower though the curve demonstrates similar behavior as with P (A) = 1. When a parallel approach is used (dashed line), a constant behavior is observed in the worst case (P (A) = 1) making it clear that such approach is better than the sequential one. From a more technical point of view, the proposed approach requires mechanisms for interpreting and assessing descriptions of distributed vulnerabilities. We have developed Ovalyzer [START_REF] Barrère | Supporting Vulnerability Awareness in Autonomic Networks and Systems with OVAL[END_REF], a tool capable of translating OVAL advisories to Cfengine policy rules. Within our approach, the Cfengine system is the component to be embedded within target autonomic networks and systems. It is in charge of enforcing security policies including the assessment of distributed vulnerabilities. To achieve this, policy rules directly interpretable by Cfengine are needed. We are currently developing a tool called Dovalyzer capable of translating DOVAL specifications into Cfengine policy rules that represent them. Dovalyzer uses the functionalities provided by Ovalyzer for translating OVAL definitions and complements the generated code in order to cover distributed assessment tasks specified by DOVAL definitions. The translator takes as input the content of DOVAL documents and produces Cfengine code that is structured as Cfengine policy files that can be later consumed by a Cfengine running instance. The Cfengine rules currently generated are compliant with Cfengine 2.2.10 [1]. Dovalyzer is a Java-based application built on top of the Spring framework 3.0. It uses JAXB [START_REF]Java Architecture for XML Binding[END_REF] for managing XML related issues and provides a plugin-based architecture enabling seamless functional extensions.

VI. CONCLUSIONS AND FUTURE WORK

Our work addresses the integration of distributed vulnerability descriptions into the management plane of autonomic networks and systems as well as mechanisms for assessing such security advisories. We have mathematically defined the concept of a distributed vulnerability and we have developed DOVAL, an OVAL-based language capable of expressing these formal constructions. A case study has been presented showing DOVAL's main constructs. As in OVAL, DOVAL descriptions can constitute useful security repositories that in turn can be exploited by self-managed environments in order to ensure safe configurations. We have proposed a framework based on the Cfengine system for assessing distributed vulnerabilities in autonomic networks as well as optimized algorithms and collaborative strategies for performing such evaluations. We have analyzed the proposed algorithms by mathematically defining computation costs that show the feasibility of the model through a comprehensive set of experiments. We also have presented a technical discussion about the proposed framework implementation where Cfengine policies are fed by Dovalyzer, a DOVAL to Cfengine translator prototype capable of producing Cfengine policy rules that represent DOVAL security advisories. For future work we plan to investigate further the actual impact of our solution on the normal management operations performed by autonomic networks and systems. Optimized algorithms and strategies are essential due to network dynamics thus we aim at analyzing other techniques in order to tackle these problems and take advantage of previous experience for reducing computation costs. We also plan to extend the proposed approach to the execution of remediation actions. XCCDF's philosophy can be exploited over distributed scenarios in order to correct distributed vulnerable states too.

Fig. 1 :

 1 Fig. 1: Distributed vulnerability matching process

Fig. 2 :

 2 Fig. 2: DOVAL logical description

<

  ? xml v e r s i o n=" 1 . 0 " e n c o d i n g ="UTF-8" ?> <d o v a l d o c u m e n t > <d o v a l d e f i n i t i o n s> <d o v a l d e f i n i t i o n i d =" d o v a l : f r . i n r i a . d o v a l : d e f : 1 " c l a s s =" d i s t r i b u t e d v u l n e r a b i l i t y "> <m e t a d a t a> <t i t l e>SI P DoS a t t a c k u s i n g DNS f l o o d i n g</ t i t l e> <d e s c r i p t i o n>. . .</ d e s c r i p t i o n> <d o v a l r e p o s i t o r y>. . .</ d o v a l r e p o s i t o r y> </ m e t a d a t a> <c r i t e r i a> <c r i t e r i o n comment =" . . . " t e s t r e f =" d o v a l : f r . i n r i a . d o v a l : t s t : 4 1 4 1 " / > </ c r i t e r i a> </ d o v a l d e f i n i t i o n> </ d o v a l d e f i n i t i o n s> <t e s t s> <d o v a l t e s t i d =" d o v a l : f r . i n r i a . d o v a l : t s t : 4 1 4 1 " comment ="DOVAL t e s t co m bi ni ng two s p e c i f i c t e s t s , r e a c h a b i l i t y and c o n f i g u r a t i o n . " c h e c k e x i s t e n c e =" a t l e a s t o n e e x i s t s " c h e c k =" a t l e a s t one "> <o b j e c t d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 2 2 " /> <o b j e c t d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 5 6 " /> <s t a t e s t a t e r e f =" d o v a l : f r . i n r i a . d o v a l : s t e : 4 4 4 4 " /> <s t a t e s t a t e r e f =" d o v a l : f r . i n r i a . d o v a l : s t e : 7 7 7 7 " /> </ d o v a l t e s t> </ t e s t s> <o b j e c t s> <! --d e v i c e s --> <d e v i c e o b j e c t i d =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 2 2 " / > <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 1 0 0 0 " /> <! --SI P s e r v e r r u n n i n g --> <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 1 0 0 1 " /> <! --P o r t 5060 o p en --> <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 1 0 0 2 " /> <! --S e c u r i t y mo d u l e n o t i n s t a l l e d--> </ d e v i c e o b j e c t > <d e v i c e o b j e c t i d =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 5 6 " / > <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 2 0 0 0 " /> <! --DNS s e r v e r r u n n i n g --> <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 2 0 0 1 " /> <! --P o r t 53 o p en --> <p r o p o v a l d e f r e f =" o v a l : o r g . m i t r e . o v a l : d e f : 2 0 0 1 " /> <! --Unknown d o mai n s s o l v e d by e x t e r n a l DNS s e r v e r s--> </ d e v i c e o b j e c t > </ o b j e c t s> <s t a t e s> <! --r e l a t i o n s h i p s --> <l i n k s t a t e i d =" d o v a l : f r . i n r i a . d o v a l : s t e : 4 4 4 4 " / > <! --T r a f f i c c a p a b i l i t y--> <p r o t o c o l o p e r a t i o n =" e q u a l s "> udp </ p r o t o c o l > <s r c p o r t d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 2 2 " o p e r a t i o n =" p a t t e r n match "> . * </ s r c p o r t> <d s t p o r t d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 5 6 " o p e r a t i o n =" e q u a l s "> 53 </ d s t p o r t> </ l i n k s t a t e> <s e r v i c e s t a t e i d =" d o v a l : f r . i n r i a . d o v a l : s t e : 7 7 7 7 " /> <! --S e r v i c e c o n f i g--> <name o p e r a t i o n =" e q u a l s "> d n s </ name> <co n su mer d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 2 2 " /> <p r o v i d e r d e v i c e r e f =" d o v a l : f r . i n r i a . d o v a l : d e v : 2 5 6 " /> </ s e r v i c e s t a t e> </ s t a t e s> </ d o v a l d e f i n i t i o n s> Listing 1: DOVAL document

Fig. 7 :

 7 Fig. 7: Statistics with an increased device participation

Session Initiation Protocol

Domain Name System

This is a simplified measure of the likelihood for the event A to occur since depending on the network nature, the probability of choosing, for instance, a SIP server within a standard company network will be presumably lower than picking up a standard workstation running any version of Windows

ACKNOWLEDGEMENTS

This work was partially supported by the EU FP7 Univerself Project and the FI-WARE PPP.