Carlos F Crispim-Junior

Francois Bremond

Uncertainty Modeling Framework for Constraint-based Elementary Scenario Detection in Vision System

Keywords: Uncertainty Modeling, Ontology, Event Detection, Activities of Daily Living, Older People

Event detection has advanced significantly in the past decades relying on pixel-and feature-level representations of video-clips. Although effective those representations have difficulty on incorporating scene semantics. Ontology and description-based approaches can explicitly embed scene semantics, but their deterministic nature is susceptible to noise from underlying components of vision systems. We propose a probabilistic framework to handle uncertainty on a constraint-based ontology framework for event detection. This work focuses on elementary event (scenario) uncertainty and proposes probabilistic constraints to quantify the spatial relationship between person and contextual objects. The uncertainty modeling framework is demonstrated on the detection of activities of daily living of participants of an Alzheimer's disease study, monitored by a vision system using a RGB-D sensor (Kinect , Microsoft c ) as input. Two evaluations were carried out: the first, a 3fold cross-validation focusing on elementary scenario detection (n:10 participants); and the second devoted for complex scenario detection (semiprobabilistic approach, n:45). Results showed the uncertainty modeling improves the detection of elementary scenarios in recall (e.g., In zone phone: 85 to 100 %) and precision indices (e.g., In zone Reading: 54.71 to 73.15%), and the recall of Complex scenarios. Future work will extend the uncertainty modeling for composite event level.

Introduction

Event detection has been significantly advancing since the past decade within the field of Computer vision giving birth to applications on a variety of domains like safety and security (e.g., crime monitoring [START_REF] Kumar | Framework for real-time behavior interpretation from traffic video[END_REF]), medical diagnosis and health monitoring [START_REF] Zouba | An activity monitoring system for real elderly at home: Validation study[END_REF] [START_REF] Crispim-Junior | Evaluation of a monitoring system for event recognition of older people[END_REF], and even as part of a new paradigm of human-machine interface in gaming and entertainment (Microsoft c Kinect ).

Event detection methods in computer vision may be categorized in (adapted from Lavee et al. [START_REF] Lavee | Understanding video events: A survey of methods for automatic interpretation of semantic occurrences in video[END_REF]): classification methods, probabilistic graphical models (PGM), and semantic models; which are themselves based on at least one of the following data abstraction level: pixel-based, feature-based, or event-based.

Artificial Neural Networks, Support-Vector Machines (SVM), and Independent Subspace Analysis (ISA) are examples of classification methods. For instance, Le et al. [START_REF] Le | Learning hierarchical invariant spatiotemporal features for action recognition with independent subspace analysis[END_REF] have presented an extension of the ISA algorithm for event detection, where the algorithm learned invariant spatio-temporal features from unlabeled video data. Wang et al. [START_REF] Wang | Action recognition by dense trajectories[END_REF] have introduced new descriptors for dense trajectory estimation as input for non-linear SVMs.

Common examples of PGMs approaches are Bayesian Network (BN), Conditional Random Fields, and Hidden Markov Models (HMM). BNs have been evaluated at the detection of person interactions (e.g., shaking hands) [START_REF] Park | A hierarchical bayesian network for event recognition of human actions and interactions[END_REF], left luggage [START_REF] Lv | Left luggage detection using bayesian inference[END_REF], and traffic monitoring [START_REF] Kumar | Framework for real-time behavior interpretation from traffic video[END_REF]. Kitani et al. [START_REF] Kitani | Activity forecasting[END_REF] has proposed a Hidden Variable Markov Model approach for event forecasting based on people trajectories and scene features. Despite the advances, PGMs have difficulty at modeling the temporal dynamics of an event. Izadinia and Shah [START_REF] Izadinia | Recognizing complex events using large margin joint lowlevel event model[END_REF] have proposed to detect complex events from by a graph representation of joint the relationship among elementary events and a discriminative model for complex event detection.

Even though the two previous classes of methods have considerably increased the performance of event detection in benchmark data sets, as they rely on pixelbased and feature-based abstractions they have limitations in incorporating the semantic and hierarchical nature of complex events. Semantic (or Descriptionbased) approaches use descriptive language and logical operators to build event representations using domain expert knowledge. The hierarchical nature of these models allow the explicit incorporation of event and scene semantic with much less data than Classification and PGM methods.

Ceusters et al. [START_REF] Ceusters | Introducing ontological realism for semi-supervised detection and annotation of operationally significant activity in surveillance videos[END_REF] proposes the use of Ontological Realism to provide semantic knowledge to high-level events detected by a multi-layer hierarchical and dynamical graphical model in a semi-supervised fashion (human in the loop). Zaidenberg et al. [START_REF] Zaidenberg | A generic framework for video understanding applied to group behavior recognition[END_REF] have evaluated a constraint-based ontology language for group behavior modeling and detection in airport, subways, and shopping center scenes. Cao et al. [START_REF] Cao | An event-driven context model in elderly health monitoring[END_REF] have proposed an ontology for event context modeling associated to a rule-based engine for event detection in multimedia monitoring system. Similarly, Zouba et al. [START_REF] Zouba | An activity monitoring system for real elderly at home: Validation study[END_REF] have evaluated a video monitoring system at the identification of activities of daily living of older people using a hierarchical constraint-based approach. Oltramari and Lebiere [START_REF] Oltramari | Using ontologies in a cognitivegrounded system: Automatic action recognition in video surveillance[END_REF] presents a semantic infra-structure for a cognitive system devoted for event detection in surveillance videos.

Although Semantic models advantage at incorporating domain expert knowledge, the deterministic nature of their constraints makes them susceptible to noise from underlying componentse.g., people detection and tracking components in a pipeline of computer vision system -as they lack a convenient mechanism to handle uncertainty. Probabilistic reasoning has been proposed to overcome these limitations. Ryoo and Aggarwal [START_REF] Ryoo | Recognition of composite human activities through context-free grammar based representation[END_REF] [START_REF] Ryoo | Semantic representation and recognition of continued and recursive human activities[END_REF] have proposed hallucination concept to handle uncertainty from low-level components in a context-free grammar approach for complex event detection. Tran and Davis [START_REF] Tran | Event modeling and recognition using markov logic networks[END_REF] have proposed Markov logic networks (MLNs) for event detection in parking lots. Kwak et al. [START_REF] Kwak | Scenario-based video event recognition by constraint flow[END_REF] have proposed the detection of complex event by the combination of primitive events using constraint flows. Brendel et al [START_REF] Brendel | Probabilistic event logic for interval-based event recognition[END_REF] propose probabilistic event logic to extend an interval-based framework for event detection; by adopting a learned weight to penalize the violation of logic formulas.

We present a uncertainty modeling framework to extend the generic constraintbased ontology language proposed by Vu et al. [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF] by assessing the probability of constraint satisfaction given the available evidence. By combining both frameworks we allow domain expert to provide event models following a deterministic process, while probabilistic reasoning is performed in second plan to cope with the uncertainty in constraint satisfaction. In this paper we focus on handling uncertainty of elementary events.

Uncertainty Modeling Framework

Uncertainty may come from different levels of the event modeling task; from failures on the low-level components which provided input-data for the event detection task (e.g., sudden change in person estimated dimension) to the model expressiveness at capturing the real-world event. For instance, constraint violation may be due to person-to-person differences in performing an event (event intra-class variation). In both cases it may be desirable that the event model be still detected even with a smaller probability.

We propose here a framework to handle uncertainty on elementary events. The framework may be decomposed on: event modeling, uncertainty modeling, and inference. In event modeling step domain experts use the constraint-based video event ontology proposed in [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF] to devise event models based on attributes of tracked physical objects (e.g., a person) and scene semantics (contextual objects). In uncertainty modeling step we learn the conditional probability distributions about the constraints using annotation on the events and the event models provided by domain experts. The inference step is performed by the temporal algorithm of Vu et al. [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF] adapted to also compute event probability. The probability computation sub-step infers how likely a model is given the available evidence based on pre-learned conditional probabilities about the evaluated constraints.

Video Event Ontology

The constraint-based framework is composed of a temporal scenario (event) recognition algorithm and a video event ontology for event modeling. The video event ontology is based on natural terminology to allow end users (e.g., medical experts) to easily add and change event models of a system. The models take into account a priori knowledge of the experimental scene, and attributes of objects (herein called Physical Objects, e.g., a person, a car, etc. ) detected and tracked by the vision components. A priori knowledge consists of the decomposition of a 3D projection of the scene floor plan into a set of spatial zones which carry semantic information about the monitored scene (e.g., zones like "TV", "armchair", "desk", "coffee machine"). The temporal algorithm is responsible for the inference task, where it takes as input low-level data from underlying vision components, and evaluates whether these objects (or their properties) satisfy the constraints defined in the modeled events. An event model is composed of (up to) five parts [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF]:

-Physical Objects refer to real-world objects involved in the detection of the modeled event. Examples of physical object types are: mobile objects (e.g., person, or vehicle in another application), contextual objects (equipment) and contextual zones (chair zone). -Components refer to sub-events of which the model is composed.

-Constraints are conditions that the physical objects and/or the components should hold. These constraints could be logical, spatial and temporal.

-Alert define the level of importance of the event model, and -Action is an optional clause which works in association with the Alert type describes a specific course of action which should be performed in case the event model is detected,(e.g., send a SMS to a caregiver responsible to check a patient over a possible falling down).

The physical object types depend on the domain of application. Two disjoint default types are presented, Mobile and Contextual Objects, with one extensions each, respectively, Person and Contextual Zone. Mobile is a generic class which defines the basic set of attributes for any moving object detected in the scene (e.g., 3D position, width, height, depth). Person is an extension of Mobile class whose attributes are body posture and appearance signature(s). Contextual Object (CO) type refer to a priori knowledge of the scene. Contextual zone is an extension of CO commonly used to define a set of vertices in the ground plane which corresponds to a region with semantic information (e.g., eating table, tv, desk) for an event model. Contextual objects may be defined at the deployment of the system by the domain experts or by launching an object detection algorithm for scene description at system installation, and specific times where object displacement is identified. Physical object types can be expanded accordingly to describe all types of objects in the scene.

Constraints define conditions that physical object properties and/or components must satisfy. They can be non-temporal, such as spatial (person->position in a contextual zone; or displacement(person1) >1 m) and appearance constraints (person1->AppearanceSignature = person2->ApperanceSignature); or temporal to capture specific duration patterns or time ordering between a model sub-events (components). Temporal relation are defined following Allen's interval algebra (e.g., before, and, meet, overlaps). Fig. 1 describes the model P erson changing f rom zone1 to zone 2; which is defined in terms of a temporal relationship between two sub-events: e.g., c1, P erson in zone 1 before c2, P erson in zone 2.

The ontology hierarchically categorizes event models according to their complexity as (in ascending order):

-Primitive State models an instantaneous value of a property of a physical object (person posture, or person inside a semantic zone). -Primitive Event models a change in a value of physical object property (e.g., person changes from sitting to standing posture), and -Composite Event refers to the composition of two previous event models which should hold a temporal relationship (person changes from sitting to standing posture before person in corridor zone).

Uncertainty Modeling for Elementary Scenarios

For uncertainty modeling purposes we divided the constraint-based ontology event models into two categories: elementary and composite scenarios. The term scenario is used to differentiate the modeling and inference tasks. Elementary Scenario have a direct correspondence to the primitive state type of the ontology, and the Composite Scenario represents all other ontology event types (Primitive Event, Composite States and Composite Events). This simplification is performed since these ontology event categories were devised to help domain experts at devising models in a modular fashion and then reduce model complexity and increase its re-usability. But, none difference exists for the inference algorithm while processing these event categories besides to the hierarchy depth of the sub-events they define a relationship for.

The uncertainty modeling framework is based on the following concepts:

-Elementary Scenario(ES) is composed of physical objects and constraints. This scenario constraints are only related to instantaneous values (e.g., current frame) of physical object(s) attribute(s). -Composite Scenario(CS) is composed of physical objects, sub-scenarios (components) and constraints; where the latter generally refer to composition and/or temporal relationships among model sub-scenarios. -Constraint is a condition that physical object(s) or sub-scenarios must satisfy, and refer to the constraint types presented on the constraint-based ontology section. -Attributes correspond to the properties (characteristics) of real world objects measured by the underlying components of the event detection task (e.g., vision system).

Fig. 2 presents a description for the elementary scenario Person in zone Tea. This scenario is based on the physical objects Person and the semantic zone zoneTea. For instance, zoneTea would be polygon drawn on the floor -close or around the table where the kitchen tools to prepare tea are commonly placed a priori defined by a domain expert during system installation or automatically detected by the system. The model has two constraints: the logic constraint that the target zone is zoneTea; and a spatial constraint called In which verifies whether the person position lies inside the given zone. Fig. 3 illustrates an example of a scene where semantic zones were manually drawn on the floor plane where contextual objects are located.

Computation of Elementary Scenario Uncertainty

The uncertainty of an Elementary Scenario is formalized as function of the framework confidence on the satisfaction of the Elementary Scenario constraints. Equation 1 presents an formalization of Elementary Scenario Uncertainty using Bayes Rule.

P (E i |C i ) = P (C i |E i ) * P (E i ) P (C i ) (1)
where, The conditional probability of event E i given its set of observed constraints C i is given by the multiplication of the individual conditional probabilities of its constraints. We assumed all constraints contribute equally to the event model detection and are conditionally independent (see Equation 2).

-P (E i |C i ):
P (C i |E i ) = Nj ci,j ∈Ci P (C i,j |E i ) (2)
where C i,j :

-Conditional probability of Constraint j of given event i.

To avoid computing P (C i ) which can become costly as the number of constraints increase, we opted to use the non-normalized probability of P (E i |C i ) as described in Equation 3.

P (E i |C i ) = P (E i ) Nj ci,j ∈Ci P (C i,j |E i ) (3)
In its final form the proposed formula for elementary scenario uncertainty (Equation 3) addresses small violations of constraints from noise coming from underlying components and due to event intra-class variations.

Probabilistic Constraints

The uncertainty of a scenario model or its conditional probability given the evidence is addressed by associating each of its constraints to a Probability Density Function (PDF) responsible for quantifying how likely the constraint would be satisfied given the available evidence. The use of PDFs provide a modular and flexible way to model and change the uncertainty process that governs the conditional probability distribution of a constraint given the available evidence -e.g., by modeling the variation of the low level data the constraint is conditioned on during the targeted event execution -and allowing us to avoid the fully specification of the set of assignments of a conditional probability table. Moreover, different constraints may use different PDFs according to the low-level data, and the PDF may be easily changed without any other changes to the event model. Besides to selecting the fitting PDF to a given constraint it is also important to how we evaluate the constraint goal in a probabilistic fashion. In the case of the spatial operator In its deterministic version is susceptible to different sources of uncertainty: firstly, from the estimated position of the person which may be influenced by noise from low-level computer vision components; and secondly, from the semantic zone zoneTeaa priori defined by an expert -which may not accommodate the complete floor surface where people may stand to prepare tea. Its probabilistic counter-part should quantify how likely is the person position to be inside the zone of interest given these sources of noise. We here propose two probabilistic alternatives to the deterministic constraint In: the fully probabilistic In (FPIn) and the semi-probabilistic In (SPIn).

-The fully probabilistic In is fully based on a PDF with respect to the relative distance between the centroid of the person -projected onto the floor -and the central position of the given semantic zone. -The semi-probabilistic In is a hybrid implementation which provides maximum probability (100 %) when the person is anywhere inside the semantic zone, and a probability proportional to the distance of the person to the closest zone edge otherwise.

To model the conditional probability distribution of the distances between the person position and the semantic zone we have used Equation 4. Briefly, this equation converts the observed distance among objects into the corresponding value in an uniform Gaussian distribution using expected parameters pre-learned per semantic object. The corresponding value is then applied to an exponential function to obtain the probability of the constraint given the evidence, e.g., a specific low-level data value for elementary scenario. The resulting PDF provides a probability curve with maximum value around the mean parameter and a monotonically decreasing behavior is observed as the observed value distances from the mean.

P (C i,j ) = exp( 1 2 * ( observed value - x s ) 2 ) (4)
where, x : learned mean of constraint value, and s: standard deviation of x

Learning Constraint Conditional Probabilities

The conditional probability distribution of the elementary constraints were obtained by a learning step based on the event models provided by domain experts -using the constraint-based ontology -and annotated RGB-D recordings of the targeted events. The learning step was performed as follows: firstly, an event detection process was performed using the deterministic event models. Each time the deterministic In was evaluated the relative distance used by the probabilistic counterparts was stored independent of whether the current constraint is satisfied. Secondly, using the event annotation we collect the distance values frequently assumed by the In variants when elementary scenario annotation is present for the given RGB-D recording. Thirdly and finally, we computed statistics about the the collected values of the attribute the constraint was conditioned on. By performing the learning step using event models combined with event annotation (both provided by domain experts) we aim at capturing the Conditional Probability Distribution (CPD) of the constraints according to the event model semantics and maybe reduce the semantic gap between the event model and the real-world event.

Elementary Scenarios are assumed to be equally probable as their evidence is mainly related to a single time unit (e.g., a frame). The Temporal aspect of scenario models such as instance filtering is currently performed by a threshold method which removes low-probability events. The influence of previous instances probabilities into the evaluated time unit will be evaluated in the future in conjunction with uncertainty modeling at Composite Scenario level (Composite Event).

Evaluation

The proposed framework has been evaluated at modeling the uncertainty of activities of daily living of participants of a clinical protocol for Alzheimer's disease study. Two evaluations were performed, firstly on the detection of elementary scenarios, and secondly on the detection of complex events by using uncertainty framework for elementary scenarios as basis for the deterministic complex event models. The latter evaluation intends to assess the improvement brought to the detection of high-level scenario by low-level uncertainty modeling. For both evaluations contextual objects were defined a priori by domain experts and mostly refer to static furniture in the scene.

Concerning the learning step necessary to obtain the parameters for the constraint conditional probabilities, in the first evaluation the parameters were computed following the rules of the 3-fold cross-validation procedure. For the second evaluation, the 10 videos involved in the 3-fold cross-validation procedure were used for the learning procedure, and the complex detection performance was evaluated on a set of recordings of 45 participants new to the system, which were only annotated in terms of Composite Events.

Data set

Participants of 65 years and over were recruited by the Memory Center (MC) of a collaborating Hospital. Inclusion criteria of the Alzheimer Disease (AD) group The clinical protocol asks the participants to undertake a set of physical tasks and Instrumental Activities of Daily Living in a Hospital observation room furnished with home appliances [START_REF] Mf | The mini-mental state examination[END_REF]. Experimental recordings used a RGB-D camera (Kinect , Microsoft c ). The activities of the clinical protocol are divided into three scenarios: Guided, Semi-guided, and Free activities. With the guided-activities (10 minutes) the protocol intends to assess kinematic parameters of the participant gait profile (e.g., static and dynamic balance test, walking test); while in semi-guided activities (15 minutes) the aim is to evaluate the level of autonomy of the participant by organizing and carrying out a list of instrumental activities of daily living (IADL).

For the framework evaluation we have focused only on the recordings of patients in the semi-guided scenario. In these recordings the participant enters the observation room alone with a list of activities to perform, and he/she is advised to leave the room only when he/she has felt the required tasks are completed. The list of semi-guided activities is composed as follows:

-Watch TV, -Prepare tea/coffee, -Write the shopping list for the lunch ingredients, -Answer the Phone, -Read the newspaper/magazine, -Water the plant, -Organize the prescribed drugs inside the drug box according to the daily/ weekly intake schedule, -Write a check to pay the electricity bill, -Call a taxi, -Get out of the room.

RGB-D Monitoring System

The framework for uncertainty modeling was evaluated using a RGB-D sensorbased monitoring system, built on the event detection framework proposed by Vu et al. [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF], and later evaluated on the detection of daily living activities of older people by Crispim-Junior et al. [START_REF] Crispim-Junior | Evaluation of a monitoring system for event recognition of older people[END_REF] using a 2D-RGB camera as the input sensor.

The evaluation monitoring system can be composed into three main steps: people detection, people tracking, and event detection. People detection step is performed by a depth-based algorithm proposed in Nghiem et al. [START_REF] Nghiem | Head detection using kinect camera and its application to fall detection[END_REF], since we have replaced the 2D-RGB camera by a RGB-D sensor. The depth-based algorithm performs as follows: first, background subtraction is employed on the depth image provided by the RGB-D camera to identify moving regions. Then, region pixels are clustered in objects based on their depth and neighborhood information. Finally, head and shoulder detectors are employed to detect people amongst other types of detected objects. The set of people detected by the previous algorithm is then evaluated by a multi-feature tracking algorithm proposed in Chau et al. [START_REF] Chau | A multi-feature tracking algorithm enabling adaptation to context[END_REF], which employs as features the 2D size, the 3D displacement, the color histogram, and the dominant color to discriminate among tracked objects.

Event detection step has as input the set of tracked people generated in the previous step and a priori knowledge of the scene provided by a domain expert. This step was evaluated for two different components for comparison purposes: the proposed framework for uncertainty modeling, and the deterministic event modeling framework proposed by Vu et al. [START_REF] Vu | Automatic video interpretation: A novel algorithm for temporal scenario recognition[END_REF] and evaluated by Crispim-Junior et al. [START_REF] Crispim-Junior | Evaluation of a monitoring system for event recognition of older people[END_REF]. Both components frameworks used the same underlying components.

Performance Measurement

The framework performance on event detection is evaluated using the indices of Recall (Rec.) and Precision (Prec.) described in Equations 5 and 6, respectively in comparison to ground-truth events annotated by domain experts.

Recall =

T P T P + F N

P recision = T P T P + F P

where TP: True Positive rate, FP: False Positive rate and FN: False Negative rate.

Results and Discussion

Table 1 presents the performance of the uncertainty modeling framework on elementary scenario (primitive state) detection in a 3-fold cross-validation scheme. The cross-validation scheme used 10 RGB-D recordings of participants of the clinical protocol data set. "Deterministic" stands for the deterministic constraintbased approach. Results are reported as the average performance on the frameworks on the validation sets.

The proposed probabilistic constraints outperformed the deterministic approach on the recall index in all cases except for the detection of "In zone reading" event with FPIn constraint, where a slightly inferior performance is observed for this probabilistic constraint. In the precision index the FPIn constraint alternates with the deterministic approach as the constraint with highest performance among elementary scenarios; while a worse performance is observed for the SPIn constraint .

Table 2 presents the results of the framework on Composite Event Detection. Here an hybrid strategy is adopted where the uncertainty modeling is used on elementary scenarios and the deterministic constraint-based framework is used on composite event modeling.

12

ECCV-14 submission ID 3 The results on complex event detection showed SPIn and FPIn had similar performance and outperformed the deterministic approach in the recall index. In contrast FPIn outperformed SPIn in the precision index but was still worse than the deterministic approach in two out of for cases.

In general, the worse performance on this event level may be attributed to the fact that other model constraints, which play a key-role on the detection of the modeled events and did not have their uncertainty addressed, have degenerated the performance of the framework. But, in the case of watering plant event the observed low precision may be due to the learned parameters of this semantic zone were not appropriate to model its uncertainty probability distribution.

Given the presented results we have chosen the FPIn as the probabilistic alternative for the deterministic spatial constraint In in our future work. Further work will investigate new methods to model the uncertainty of elementary scenarios as well as extending the framework for Composite Scenario level.

Conclusions

We have presented a uncertainty modeling framework to handle uncertainty from low-level data in the form of constraints of elementary scenarios (lowlevel events). The framework successfully improves the recall performance of the event detection task in elementary scenarios, and in some cases the recall index on detection of Composite Scenarios (semi-probabilistic approach). Further development will investigate new methods to model the condition distribution of constraints for which the univariate Gaussian distribution is not appropriate.

Currently, a supervised learning step is necessary to compute the conditional probabilities associated to the event model constraints. To improve the usability of the framework in a system-wise approach, future work would also investigate possible alternatives to allow small deviations to the scenario constraint without the need of a learning step. Finally, an investigation will be carried out to extend the current framework to composite scenario models by proposing techniques to handle uncertainty related to composite and temporal relations among sub-scenarios.

Fig. 1 :

 1 Fig. 1: Person changing from zone 1 to zone 2

Fig. 2 :

 2 Fig. 2: Elementary Scenario Person in zone Tea

Fig. 3 :

 3 Fig. 3: Scene semantic zones

  of AD according to NINCDS-ADRDA criteria and a Mini-Mental State Exam (MMSE) 35 score above 15. AD participants who have significant motor disturbances (per the Unified Parkinson's Disease Rating Scale) are excluded. Control participants are healthy in the sense of behavioral and cognitive disturbances.

Table 1 :

 1 Average Performance of Framework on Elementary Scenario Detection on a 3-fold-cross-validation scheme

		Deterministic		SPIn		FPIn
	IADL	Rec.	Prec.	Rec.	Prec.	Rec.	Prec.
	In zone Pharmacy 100±0	83.33±28.87 100±0	85±13.23	100±0	85.71±24.74
	In zone Phone	85.2±15. 88.89±11.11 91.9±7.3 85.5±17.1	100±0	93.33±11.55
	In zone Plant	100±0	68.59±35.06 100±0	20.44±5.93 100±0	55.56±13.88
	In zone Tea	100±0	81.02±22.92 100±0	37.58±28.11 100±0	79.17±26.02
	In zone Read	80±34.64 54.71±21.11 100±0	33.96±12.92 72.38±24 73.15±27.82
	N : 10 participants; 15 min. each; T otal : 150 min.

Table 2 :

 2 Framework Performance on Composite Event Detection Level N : 45 participants; 15 min. each; T otal : 675min.

		Deterministic		SPIn		FPIn
	IADL	Rec.	Prec. Rec.	Prec. Rec.	Prec.
	Talk on Phone	89.6	86.7	90.8	72.5	88.5	80.2
	Preparing Tea/ Coffee 89.4	72.0	97.0	36.8	95.4	50.8
	Using Pharmacy Basket 95.4	95.4	97.7	93.5	97.7	93.5
	Watering plant	74.1	69.0	100.0 21.6	100.0 23.1


Thiago Barroero
email: thiago.barroero@unipv.it

Gianmario Motta
email: gianmario.motta@unipv.it

Giovanni Pignatelli
email: giovanni.pignatelli@unipv.it

Business Capabilities Centric Enterprise Architecture

Keywords: Enterprise Architecture, TOGAF, Business Capabilities

des établissements d'enseignement et de recherche français ou étrangers, des laboratoires publics ou privés.

Introduction

Enterprise Architecture and Business Capabilities modeling

Nowadays scenario of Enterprise Architecture (EA) testifies a plethora of frameworks [START_REF] Schekkerman | Institute for Enterprise Architecture Developments (IFEAD)[END_REF] from which it is hard to determine which one is better than another, for they differ in goal and in approach. The point is that each framework has specific characteristics and has been developed for a specific purpose. Still, The Open Group Architecture Framework (TOGAF) is the result of best practice [START_REF]TOGAF Version 9. The Open Group Architecture Framework[END_REF] and the second framework most used overall [START_REF] Minoli | Enterprise Architecture A to Z. Frameworks, Business Process Modeling, SOA, and Infrastructure Technology[END_REF]. TOGAF is specifically conceived as cross-industry open standard for enterprise architecture. Across the board the principle that EA is critical to business survival and success, and is an indispensable means to achieve competitive advantage through IT. Inspecting IBM CEO survey 2008 [START_REF]The Enterprise of the Future[END_REF], it is plain that the enterprise of the future requires EA for responsiveness and innovation are achievable only if an integrated and responsive IT environment is supportive of the delivery of business strategy. In order to overcome today's imperatives of growth and profitability, firms must focus on responsiveness, innovation, differentiation and efficiency [START_REF]The Enterprise of the Future[END_REF], and should embrace the concepts of Business Capabilities through Componentization of Business [START_REF] Cherbakov | Impact of Service Orientation at the Business Level[END_REF].

Componentization breaks down each enterprise capability into business component (BC). Each BC is an individual business model that encompasses a coherent set of activities, supported by assets including people, processes and technology. A component serves a unique purpose within the organization but could also, in principle, operate as an independent entity [START_REF] Pohle | The Specialized Enterprise. A Fundamental Redesign Of Firms And Industries[END_REF]. A BC is characterized by a distinctive high-level capability that it offers to the Enterprise. This possessed ability is used to achieve a specific purpose or outcome. In other words, BCs are the modular building blocks that compose an enterprise.

Business Capabilities Models

A Business Capability model includes the description of capabilities and connections, how services are provided, their performance metrics, the people responsible for the service, and the systems that provide support for them. In general, business component may be modeled in two very different ways [START_REF] Herzum | Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise[END_REF] that lead to diverse patterns described in Table 1. A BC is orthogonal to the overall domains of an EA. A generic EA divides the architecture in four domains [START_REF]TOGAF Version 9. The Open Group Architecture Framework[END_REF], namely Business, Data, Application and Technology Architecture shortly summarized inTable 2. The business strategy, governance, organization, and key business process.

Data Architecture

The structure of an organization's logical and physical data assets and data management resources Application Architecture A blueprint for the individual application systems to be deployed, their interactions, and their relationships to the core business processes of the organization Technology

The software and hardware capabilities required to support the deployment of business, data and application services. This includes IT infrastructure, middleware, networks, communications, processing, and standards.

BC modeling is incorporated in methodologies, including those by IBM and Microsoft. Let us consider their profile and position our approach.

IBM CBM Approach

IBM Component Business Modeling (CBM) [START_REF] Cherbakov | Impact of Service Orientation at the Business Level[END_REF][5] [START_REF] Ernest | Adding Value to the IT organization with the Component Business Model[END_REF] focuses on business change and transformation of enterprises. CBM identifies business challenges and business opportunities and analyzes the role of each BC in terms of specialization and differentiation. In other words, CBM enables to determine building blocks for the future business in different areas and across operational functions. The approach guides the architect in identifying gaps between current and future state showing requirements to be met (fit-gap analysis), but, alas, does not guide the analyst in defining how to bridge requirements with a data, application and technology architecture design.

Microsoft Motion

In [START_REF]TOGAF Version 9. The Open Group Architecture Framework[END_REF] [9] Homann and Tobey describe a Microsoft approach to "model a business architecture as a network of capabilities, and then transform the business architecture into a service-oriented architecture." The Microsoft Motion methodology provides an approach to link a business modeling to an IT implementation related to Web Service technology. Motion is a top-down approach, from business to IT requirements. The methodology addresses architectural issues like capabilities view, people view, process view, technology view and Service Level Expectations (SLE), but does not describe how steps are performed, e.g. how components should be selected or decomposed, nor links BC to the information systems.

Other Approaches

Business Capability Mapping and Analysis (BCMA) by Helix Commerce International Inc. [START_REF]Helix. Business Capabilities Mapping and Analysis[END_REF] focuses on capabilities and its alignment with business processes. It is based on customers' needs and priorities. The approach may be considered as an EA Framework as it bridges the chasm between Strategy, Process, Architecture, and Technology and brings greater clarity to the as-is state and capabilities of a organization, and its alignment to the to-be vision of the business.

Capgemini reports an approach adopted to support insurance companies that uses a business component architecture [START_REF] Linan | The Smart Insurance Enterprise System[END_REF]. The methodology divides the business into functions called components and analyzes each aspect of the business that impact on the performance of a business component. The Business Component Architecture models the business architecture by identifying components and their relationship, it designs a target solution based on the component map in a manner that covers all functions that must be supported with no overlap and finally design and implement a insurance enterprise system to support the business functions.

Finally, enhanced Telecom Operation Map (eTOM) [START_REF]The Business Process Framework. For the Information and Communication Industry[END_REF] is a detailed description of the business processes of a generic telecommunication company, decomposed to a deep level of detailed. If we observe the eTOM map decomposed down to the third level, we may consider those "processes" as components for they represent business functions.

Summary and positioning

After this short review, we position the BC models in terms of their orientation (functional or strategic), their target (industry, cross industry) as in On the other side, Zachman is the most used framework, but it is a taxonomy rather than a methodology [START_REF] Minoli | Enterprise Architecture A to Z. Frameworks, Business Process Modeling, SOA, and Infrastructure Technology[END_REF].

TOGAF Extension

"TOGAF provides the methods and tools for assisting in the acceptance, production, use and maintenance of an enterprise architecture. It is based on an iterative process model supported by best practices and a re-usable set of existing architecture assets." [START_REF]TOGAF Version 9. The Open Group Architecture Framework[END_REF] and includes several parts. The TOGAF structure includes a core and a certain number of extensions. Extensions add method steps, meta-model entities and artifacts. BCCE is one of the possible TOGAF extensions. Specifically Business Capabilities Centric Extension (BCCE) introduces the BC concept in the TOGAF core structure and changes it in some parts as shown in Table 4. .

Changes in TOGAF Part III -ADM Guidelines & Techniques

The first change is the Componentization of Business as a new principle for Enterprise Architecture (Table 5).

Table 5. The principle of Componentization of Business.

Name of principle

Componentization of Business

Statement

Well-defined business units called Business Components (BC) compose the Business Architecture. Each BC encompasses a distinctive set of capabilities, activities and resources, and interacts with other components through services.

Each BC has to be considered as a "centre of services".

Rationale

Componentization of business delivers a modular enterprise architecture that that potentially is more responsive to business changes. Implications -Componentization of business brings a revolutionary change to enterprise organization for it divides the business into separated business units. -Componentization places a big constraint on business inter-component communication, because every exchange of value or information should be conducted through business services.

-Componentization generates an environment where every unit of an enterprise acts like a producer of services; thus, every part could be managed as a single independent organization itself. The whole organization should be fully componentized in order to benefit from componentization.

Part III also contains new architectural artifacts that are required by method steps described in Part II. Figure 1 shows BCCE added artifacts and describes their respective content. The matrix shows which business component produces business services and which one consumes it.

Business Component/ Business Process Matrix

The matrix shows which business component is involved in which business process.

Business Service Dependencies Matrix

The matrix shows the dependencies between business services.

Business Component/ Information Matrix

This matrix shows for each component what source of information is required. Business Service /Data Entity Lifecycle Matrix

This matrix shows the data lifecycle (CRUD) used by business services.

Changes in TOGAF Part IV -Architecture Content Framework

We have extended the TOGAF core meta-model by introducing or redefining concepts of the BC approach. Figure 2 shows the changes to core TOGAF metamodel and Table 7 describes them. The foundations of our contents extensions are available in [START_REF] Ackermann | Specification of Customizable Business Components[END_REF] [14] [15].

Validation

Let's consider a telecommunication organization that whishes to capitalize the emerging of new opportunities such as DSL demand in his country. Due to processes inefficiency and the complexity of a DSL offer, the intervention requires a re-design of business processes and organization in order to govern and manage demand planning, network planning and order management. The case is taken from NGOSS Framework for it is a best practice on the Telecommunication industry adopted in the world by major Telco companies.

In order to assess enterprise capabilities we built a Business Component Map diagram based on eTOM level 3 processes. In Figure 3 we identified the direct and indirect impacted components in order to deliver a DSL service. The map quickly shows what components of the enterprise are required for the desired service and become a requirement for further modeling. For each business component a catalog of sub-capabilities is created to identify what ability should have each BC. Table 8 shows a catalog of capabilities for the Resource Provisioning BC aligned to the BC goals.

Goal

Guarantee that resource orders are issued correctly and complete.

Capability

Ability to issue correct and complete resource orders.

Ability to initiate a resource order assessing the information contained on a service order.

State Specified

Ability issue resource orders that require a feasibility assessment, new provisioning activities, change to a previous resource order, or require the deletion/recovery of previously delivered resource orders.

State Specified

Ability to manage specific or unusual requirements. State Specified

Then, we defined a business scenario for each process that composes a DSL Service, namely DSL Fulfillment, DSL Assurance and DSL Billing. For each one of them we designed a Business Component Collaboration diagram to identify main business services exchanged between components. Figure 4 shows the Collaboration Diagram referred to a DSL Fulfillment sub-process, i.e. DSL Pre-sales sub process. Those viewpoints together with the dynamic collaboration viewpoint addressed with UML Sequence Diagrams represent a high-level vision of the desired behavior and structure of our target enterprise architecture.

Hereafter we start a functional modeling of each component. For each Business Component Collaboration View, a process flow is drawn in order to identify activities and information flows and to validate business services. When the business architecture phase is over, an analysis of main source of data was conducted. For each business service we identified how data entity was manipulated building the Business Service / Data entity Lifecycle Matrix showing CRUD (Create, Read, Update, Delete) relations. Furthermore, we identified source of data for each activity described during the process flow analysis.

Finally, we identified system services by analyzing data manipulation. Our goal was not to provide a system design but describe system as group of low-level capabilities that manage data of the data architecture and support activities on business architecture. At last, we related application components to technology components.

Conclusions

We have illustrated the integration of a the Business Component approach into the TOGAF framework. This integration implies multiple potential benefits. First it links business strategy and IT strategy by a very convincing model. For Business Component approach is a very popular method among enterprise consultants to identify a modularization of the enterprise in the perspectives of business development, sourcing and out-sourcing.

Second the link between the business component concept and related information architecture is clear and easy to understand. In fact from a business strategic viewpoint Business Component is a Business Unit and from IT viewpoint it is a cluster that receives and delivers services.

Third Business Component allows by its very nature a modularization of IT architecture, that potentially enhancing its responsiveness to sudden business and environmental changes. Moreover the alignment of IT to Business comes almost as a byproduct of mating Business Component into Information Architecture.

Next steps include a formal field validation and a subsequent step its formal integration in the TOGAF framework body. Business Component Approach is a strategic modeling procedure that is taking place over last years. It focuses mainly on decision-making steps for it defines scopes, required capabilities and strategic evaluations. We used TOGAF 9 to fill the gap between the outcome of the business component approach and an EA framework. Next step would require a detailed description of EA with a service oriented architecture supporting business component approach.

-

  resources, guidelines, templates and background information ---------------2.3 Changes in TOGAF Part II -Architecture Development Model (ADM) The main changes in Part II -Architecture Development Model include • Integration of the Componentization of Business principle as a constraints of the Enterprise Architecture structure • Description of the Architecture Vision in terms of business capabilities trough Business Component Map Diagram and Business Component Collaboration Diagram; • Introduces in Capability Assessment the strategic value added by BC.

Figure 1

 1 Figure 1 TOGAF viewpoints taxonomy of BCCE

Figure 2

 2 Figure 2 Business Capabilities Centric Extension (BCCE): Changes to Metamodel

Figure 3

 3 Figure 3 Business Component Map Diagram for a telecommunication enterprise

Figure 4

 4 Figure 4 Business Component Collaboration Diagram. DSL Fulfillment. Pre-sales subprocess.

Table 1

 1 Modeling Business Capabilities Description

		Strategic Modeling	Functional Modeling
	Objective	To produce a model that enables	To produce a model of each
		the identification of business	business component that enables its
		challenges and business	implementation, either on a business
		opportunities.	view (i.e. organizational structure,
			accountability, processes and
			activities, business services etc.) or
			on a IT view (i.e. design of systems,
			applications, software artifacts etc.).
	Outcome	A business model, usually a paper	A detailed design of all dimensions
		or a tool-based model, that focuses	of each component
		on sensitive components.
	Primary Audience Business executives	Business and IT managers

Table 2

 2 Enterprise Architecture Domains

	Architecture Type	Description
	Business Architecture

Table .

 .

	Model Name	Orientation	Target	EA Integration
	IBM -CBM	Strategic	Cross Industry	Missing
	MS -Motion	Functional	Cross Industry	Missing
	Helix -BCMA	Strategic	Cross Industry	????
	Cap Gemini	Functional	Insurance	OK
	eTOM	Functional	Telecom	OK

Table 3 Comparative profile of business components models

 3

Apparently, a well-established and mature business capability centric approach that grants EA design, implementation and governs is still missing. The main purpose of this paper is to fill this gap. As a host methodology we have chosen TOGAF since

[START_REF] Minoli | Enterprise Architecture A to Z. Frameworks, Business Process Modeling, SOA, and Infrastructure Technology[END_REF]

:

• Is supported by an open strong committee • Is a proven method and result of long term practice • Uses a standard taxonomy for business, information, and technology modeling. • Has a business focus in the architecture development • Is supported by many tools.

Table 4 Impact of BCCE on TOGAF

 4

	TOGAF Part	Comments	Impact of BCCE
	Part I Introduction
	Part II Architecture	Describes a process for deriving	Additions to the method
	Development Model	an organization-specific enterprise	steps to include BC concepts
	(ADM)	architecture that addresses
		business requirements
	Part III ADM Guidelines	Supports ADM	• Added the principle
	& Techniques		"Componentization of
			Business"
			• Added Architectural
			Artifacts
	Part IV Architecture	Provides a detailed model of	Changes to the core meta-
	Content Framework	architectural work products,	model entities
		including deliverables, artifacts
		within deliverables
	Part V Enterprise	A model for structuring a virtual
	Continuum	repository and provides methods
		for classifying architecture and
		solution artifacts.

Table 6

 6 BCCE Diagrams and Matrices Description

	Entity	Description

Table 7

 7 BCCE Changes to TOGAF meta-model description.

	Entity	Description	Change	Notes
			Type
	Business		New
	Component
	Capability A capability is the "power or the ability to do	Modified Each capability can
		something". It is an idealized conceptual		be associated to one
		structure that describes what a BC can do to		and only one BC
		creates value for customers. It is accessible
		through business services and identifies what is
		required to accomplish a business objective.
	Business	A business service is an interface through	Modified BCs can exchange
	Service	which other components requires or provides a		value only trough
		capability. It is standardized and hides its		business services.
		implementation from other components.
	Activity	An activity is an atomic operation performed	Modified Each Activity can
		within a BC and belongs exclusively to a single		be associated to one
		component. It represents an operation		and only one BC
		performed to provide low-level capability.

A business component encompasses a coherent set of activities, supported by assets including people, processes and technology. It interacts with other business components through business services.

Table 8

 8 Resource Provisioning BC capabilities decomposition.


Marco Ramilli
email: marco.ramilli@unibo.it

Marco Prandini
email: marco.prandini@unibo.it

An integrated application of security testing methodologies to e-voting systems

Keywords: eVoting, security, testing methodologies

Various technical bodies have devised methodologies to guide testers to the selection, design, and implementation of the most appropriate security testing procedures for various contexts. Their general applicability is obviously regarded as a necessary and positive feature, but its consequence is the need for a complex adaptation phase to the specific systems under test. In this work, we aim to devise a simplified, yet effective methodology tailored to suit the peculiar needs related to the security testing of e-voting systems. We pursue our goal by selecting, for each peculiar aspect of these systems, the best-fitting procedures found in the most widely adopted security testing methodologies, at the same time taking into account the specific constraints stemming from the evoting context to prune the excess of generality that comes with them.

Introduction

Testing is important to ascertain the adherence of an implemented system to its specification, but even more to prove that it exhibits sensible reactions to unexpected stimuli. Even the best design process cannot capture the latter property, since no explicit requisite can represent it; thus, testing contributes in an unique way to the development cycle of secure systems [START_REF] Arkin | Software penetration testing[END_REF][START_REF] Bonver | Developing and retaining a security testing mindset[END_REF][START_REF] Potter | Software security testing[END_REF], notwithstanding the impossibility of guaranteeing the absence of any problem through it [START_REF] Thompson | Why security testing is hard[END_REF]. The scientific and technical communities have made various attempts at defining detailed procedures for security testing. Clearly, the goal pursued in these efforts was to devise generally-applicable guidelines, while at the same time providing as much detail as possible regarding the proper way of performing each step. Two limitations affect the proposals found in the literature. First, their application could result quite cumbersome, requiring a non-negligible effort in the preliminary phase of mapping the suggested procedures to the specificities of the system to be tested. Second, the "perfect" proposal does not exist, each one exhibiting areas of excellence and more neglected sections.

We aim at a twofold result for the mitigation of the aforementioned problems. The paper is structured as follows. In sections 2 and 3 we briefly outline the most widely adopted testing methodologies. We proceed (section 4) to synthetically review the commonly adopted e-voting architectures and to summarize their common characteristics. By combining the elements of this preliminary exploration, we choose from the different methodologies the testing procedures that better suit the specific needs related to testing the components of e-voting systems. Taking into account the constraints that define the class of e-voting systems, as opposed to generic ones, we simplify those procedures by safely removing the unneeded details and more precisely driving the testing process.

Related work

We deem useful to recall a few concepts related to the different approaches to security testing, to e-voting, and to the relation between the two worlds that emerges from the most significant experiences to date.

Security testing approaches

There are significant differences between the many papers, from the academic as well as the technical world, that deal with the subject of security testing. A possible classification organizes the various proposals into three broad categories:

Toolkits implement in a convenient package a set of testing techniques, usually aimed at discovering specific classes of security problems. Toolkits represent the operating side of security testing. They are valuable companions to guidelines and methodologies, which in turn provide the strategies to effectively use them. The Open Vulnerability Assessment System [START_REF] Brown | Open vulnerability assessment system[END_REF] and the BackTrack Live CD [START_REF] Moser | [END_REF] are significant examples among countless others. Guidelines organize the process of security testing, by collecting sets of best practices and comprehensively listing items to be tested; they often distill the experiences gathered on the field by the technical community, but usually lack the level of detail that allows to design a precise test plan. Some examples of well-known guidelines come from NIST, namely: the Common Criteria for Information Technology Security Testing [START_REF] Horlick | HB 150-20 Information Technology Security Testing: Common Criteria[END_REF] and the Technical Guide to Information Security Testing and Assessment [START_REF] Scarfone | SP 800-115 Technical Guide to Information Security Testing and Assessment[END_REF]. The Open-ended vulnerability testing (OEVT) [START_REF][END_REF] is being devised starting from the experiences gathered by the Electoral Assistance Commission in the U.S.A on the Voluntary Voting System Guidelines (VVSG) [START_REF]Voluntary Voting System Guidelines[END_REF]. Methodologies represent the most structured approach to security testing. To different extents, every methodology defines: (a) an abstract model for the system, (b) an abstract model for the process of finding its vulnerabilities, and (c) a procedure for realizing a concrete test plan from the models, given the details of the system under test. A detailed discussion of the most widely adopted methodologies is illustrated in section 3.

E-voting systems

The need for technological aids to make the voting process more efficient and accurate predates the availability of sophisticated computer architectures, but usually the adopted solutions (for example, punch-card devices and optical scan machines) perform little more than substituting a supposedly more robust media for the traditional pencil-and-paper. More recently, comprehensive systems have been designed and implemented that exploit computers and networks to take care of every step of the voting process. The foreseen advantages have greatly increased, but the concerns raised by the trustworthiness and security aspects of such complex (and opaque) architectures have grown equally strong. Examples of commonly adopted approaches include:

Direct Recording Electronic Voting System (DRE). The voter chooses by simply touching the name of the candidate directly on screen and the machine casts the vote on its own storage device. At the end of the election, the machine produces an exhaustive report to be sent to the precinct for counting. The systems by leading vendors (Diebold, Election Systems and Software, Sequoia among the others), widely adopted for instance in the U.S.A., are mainly of this kind. However, they have harshly been criticized for the complete lack of independent correctness-checking capabilities, that leaves open the possibility of undetectable mistakes of malicious or accidental nature. Voter Verified Audit Trail (VVAT) Electronic Voting Machine solve this problem by generating a proof which can be audited by the voter to ascertain the correct recording of her will. It can be a paper ballot which can be reviewed by the voter before confirming her intention to cast it, and then collected in a secure storage should a recount be needed, or a mathematical proof that pushes the concept even further, by allowing the voters to check whether their vote was accurately recorded by the electronic system (end-to-end verification), not only in the paper trail [START_REF] Chaum | Scantegrity: End-to-end voter-verifiable optical-scan voting[END_REF][START_REF] Adida | Helios: web-based open-audit voting[END_REF].

E-voting Security Threats

Although security testing is an incomplete test, meaning that it does not ensure the absence of flaws, it is the only process able to prove threats. In sensitive systems like e-voting, the presence of threats might interfere with the correct election outcome compromising the democracy of the hosting country. Examples of the most important areas where security threats might be present are :

1. Secrecy. If the system does not assure secrecy, the system is at least vulnerable to covert channels attacks, where an attacker may buy or sell votes. 2. Integrity. If the system does not assure integrity, an attacker could compromise the election by replacing or modifying the integrity of the ballots or directly the integrity of the final counts. 3. Availability. If the system does not assure availability, the system can not assure the universal suffrage, becoming vulnerable at least to external quorum attacks, in which the attacker can modify the total number of voters denying the minimum voters requirements. 4. Authentication. If the system does not assure authentication controls, it is at least vulnerable to multiple vote attacks, where an attacker could vote multiple times for the preferred candidate.

Depending on the system implementation we may find different entry points where the security threats may appear. For example the integrity of the system might be threatened by malwares, or directly by the vendor introducing incorrect behaviors or backdoors on the voting platform; the authentication control might be threatened by wrong input validation, brute force attacks or buggy sessions. Since the range of the entry points is so large and so strongly platform dependent, the paper does not describe the details of each of them, but synthesizes the general features useful to devise an e-voting system testing methodology.

E-voting systems testing experiences

Oddly enough, to our knowledge, there is no documented application of the most complete testing methodologies to e-voting systems. Certification for official use, where it is mandatory, commonly follows guidelines like the VVSG, that are quite country-and technology-specific. A posteriori security reviews skillfully exploit various toolkits and attack techniques, not adopting structured approaches (but producing interesting results nonetheless). Notable examples of the latter category were the seminal Security Analysis of the Diebold AccuVote-TS Voting Machine [START_REF] Feldman | Security analysis of the diebold accuvote-ts voting machine[END_REF] performed in 2006, the California Top-to-Bottom Review [START_REF] Wagner | Report of the california voting system review[END_REF], performed by various Californian universities [START_REF] Bishop | Risks of e-voting[END_REF][START_REF] Balzarotti | Are your votes really counted?: testing the security of real-world electronic voting systems[END_REF] on all the voting systems used in 2007 for state and local elections, and the similar Evaluation & Validation of Election-Related Equipment, Standards & Testing (EVEREST) program undertaken in Ohio in the same year [START_REF]Evaluation & validation of electionrelated equipment, standards & testing[END_REF].

Existing security testing methodologies

In this section, we give a glimpse of the main security testing methodologies that we exploited to build a tailor-made testing process suited for e-voting systems.

ISSAF

The Information Systems Security Assessment Framework (ISSAF) [START_REF]Open Information Systems Security Group: Information systems security assessment framework[END_REF] is a wellestablished penetration testing methodology, developed by OISS.org. It is designed to evaluate the security of networks, systems and application controls. The methodology outlines three well-defined action areas, and details the nine steps composing the main one, as follows:

-Planning and Preparation. The first phase encompasses the steps needed to set the testing environment up, such as: planning and preparing test tools, contracts and legal protection, definition of the engagement team, deadlines, requirements and structure of the final reports. -Assessment. This phase is the core of the methodology, where the real penetration tests are carried out. -Reporting, Clean-up and Destroy Artifacts. During this phase, at the very end of the active parts of the methodology, testers have to write a complete report and to destroy artifacts built during the Assessment phase.

ISSAF has a clear and very intuitive structure, which guides the tester through the complicated assessment steps.

OSSTMM

The Open Source Security Testing Methodology Manual (OSSTMM) [START_REF]and Open Methodologies: Open source security testing methodology manual[END_REF] is the de-facto standard for security testers. It describes a complete testing methodology, offering fairly good tools to report the result set. In the OSSTMM ontology, the complex made by the target and the logical infrastructure to access it is named scope. The scope of application of OSSTMM encompasses any interaction, with any asset within the whole operating security environment, including the physical components of security measures as well. The methodology mandates that all the threats within the scope must be considered possible, even if not probable. On the access paths side, the scope is organized in three channels: COMSEC (communications security), PHYSSEC (physical security), and SPECSEC (spectrum security). Channels are the means of interacting with assets, where an asset is defined as anything of value to the owner. Fig. 1 represents the scope extension. The three main channels are split into 5 sub-channels: -Human. It comprises all the human elements of communications -Physical. It comprises the tangible elements of security where interaction requires physical effort or an energy transmitter to manipulate.

-Wireless Communication. It comprises all the electronic communications, signals and emanations which take place over the known EM spectrum. -Data Networks. It comprises all the electronic systems and data networks where interactions take place over dedicated cables and wired network lines. -Telecommunication. It comprises all the telecommunication networks, digital or analog, where the interaction takes place over shared network infrastructures, such as telephone lines.

OSSTMM describes 17 modules to analyze each of the sub-channels. Consequently, the tester has to perform 17*5 = 85 analyses before being able to write the final report.

Black Hat

Most attackers follow a sort-of-coded procedure to exploit systems, made of four steps, as described in the following list:

-Bugs Information Discovery. In this step the attacker, using automatic and manual analysis, gathers information about system bugs. -Exploration. In this step the attacker filters the informations obtained in the previous step, obtaining a list of vulnerabilities (i.e. exploitable bugs). -Assessment. The attacker figures out the most profitable vulnerability.

-Exploitation. The attacker, using both known and improvised techniques, begins the exploitation.

While the apparent order of this procedure has led many to call it "the Black Hat Methodology" (BHM), it is not formally defined anywhere, nor general enough to be used for penetration testing. The main difference between attacking a system and performing penetration testing is the final goal: to attack a system the attacker needs only one vulnerability, to protect the system the tester needs to find all the vulnerabilities. The non-cyclic control flow present in the methodology does not help the tester to find each vulnerability, but only the first one.

GNST

The Guideline on Network Security Testing (GNST) [START_REF] Wack | SP 800-42 Guideline on Network Security Testing[END_REF] issued by NIST, notwithstanding the name, is the first methodology to introduce a formal process for reporting and to take advantage of inducted hypotheses. It follows four steps:

-Planning. System analysis finds out the most interesting test targets.

-Discovery. The tester searches the system, looking for vulnerabilities.

-Attack. The tester verifies whether the found vulnerabilities can be exploited.

-Reporting. In the last step, every result is reported.

Each step has an input vector representing known facts and an output vector representing the complete set of results deriving from the performed actions.

GNST introduces an attempt at considering inducted hypotheses, where the output vector from a step can become part of the input vector of another one.

Applying methodologies to e-voting systems

There are many different kind of tests to be performed on voting systems, for which the authors believe that a specific methodology is needed, such as: usability testing, performance testing, and proof of correctness. With an overall perspective, the tester needs to verify the good behavior checking each election requirement. Testing the election requirements mens checking: R. Focusing on the security aspects of e-voting systems testing, we may consider as the common and implicit "testing goal " of the process the overall security of the system. Considering that in security the composability property does not hold ( security(a) ∪ security(b) != security(A ∪ B) ), except in unrealistically simple situations and after an unusually complex design process, the tester must verify every component and the whole system in two separate views. This means that tester has to test at least a fixed object called Voting System and many different objects called Voting Objects.

Testing Voting System and Voting Objects

The voting objects vary according to the analyzed system, but for the sake of clarity some examples include: touch screen monitors, printers, network cables and routers, power supplies, software and so forth. For each defined Voting Object the tester needs to verify that it is not possible to: -Compromise the Hardware, i.e. insert, remove, substitute or damage physical devices. An example of denial of service attack performed through the hardware occurs when an attacker cuts the edges of a resistive touchscreen monitor (RTM). The attack analysis shows that the vulnerability resides in the technology that place the touch sensors on the surface of the screen, and suggests to adopt as a countermeasure the substitution of RTM with capacitive touchscreen monitors, which have glass-hidden sensors. -Compromise the Firmware, i.e. alter drivers, hardware BIOS or embedded code. An example of election hijacking performed through firmware alteration occurs when the attacker modifies a router, choosing it because it is a rarely tested COTS component, substituting its firmware with a custom one which allows to dump or to manage the network communications between machines and the ballot box, thus greatly increasing the chances of compromising the election system. -Compromise the Software, i.e. insert new code, modify the existing code, delete existing code or force an unexpected behavior. For example, an attack vector of this kind on the Unix platform could be an unsecured boot process allowing an attacker to find a privileged login through single-user-mode, or an unsecured terminal where by shutting down the graphic user interface the attacker can operate on the local file system.

Assessing the absence of the afore-listed attack opportunities does not mean that the analyzed system can be considered safe. The best way for a tester to identify all the possible flaws is to consider the most favorable situation for the attacker (the worst situation for the system), assuming a White Open Box point of view, where everyone knows how the system works (through documentation), how the system has been written (through source code) and where the tester can simulate both internal and external attacks. We define the posture of tester as "Voting System Tester Point of View ", which is unique for all the systems. Flaws hypotheses and induction flaws hypotheses may be applied in the same way as most of the methodologies show. Properly documenting the evidence regarding what the tester has found, and reporting every relevant action performed during the test is a common provision of most of the methodologies. Summing up, the new methodology should have three new basic assumptions as follow:

A.1) Testing Goals = the entire security of electronic voting system A.2) Testing Objects = Voting System + Voting Objects A.3) Tester Point Of View = Voting System Tester Point of View = Internal/External Open White Box

Adding assumptions means decreasing the procedure's complexity because the final methodology has three less steps to follow. Fig. 2 shows the transition from the discussed methodologies assumptions to the new ones. On the left of Fig. 2 "testing goals" are defined. ISSAF defines the testing goals in the "Planning and Preparation" section, OSSTMM in the "Scope" section and GNST in the "Planning" section. The meaning of the arrows between left boxes and the central one is that each "testing goal " is an instance of "Security of Voting System" as previously discussed. On the right of Fig. 2 "Testing Objects" are defined. ISSAF define the testing objects in the "Planning and Preparation" section, GNST in the "Planning" section, while OSTMM classifies the testing objects in the three known channels. The meaning of the arrows between the right boxes and the central one is that each "Testing Objects" should be collapsed into "Voting System + Voting Objects". Finally on the bottom of Fig. 2 "Voting System Tester Point of View " is represented. ISSAF defines the Voting System Tester Point of View into the "Assessment" section, OSSTMM in the "Posture" section and GNST in the Discovery section. Again, the meaning of the arrows between the bottom boxes and the center one is that each "Voting System Tester Point of View " should be fixed to "Open White Box" to ensure a safe, worst-case-scenario analysis.

Tailoring the methodologies to the e-voting context

In this section we finally discuss how to choose the most appropriate procedures from the illustrated methodologies, adapting and simplifying them to fit the scenario of e-voting systems testing. The description is necessarily kept at a rather high level of abstraction, because the amount of details involved in the accurate description of each set of procedures could never fit a conference paper.

ISSAF Adaptation

ISSAF can be exploited as follows, taking advantage of the three new assumptions introduced in section 4. Referring to the Fig. 2 the main ISSAF "Planning and Preparation" steps are:

-Identification of contact individuals from both sides.

-Opening meeting to confirm the scope, approach and methodology. -Agreement on specific test cases and escalation paths.

By fixing the assumptions A.1 and A.2, the tester does not really need to perform the first two steps, which are time and money consuming and often require organizational skills that do not belong to the tester. In the presented scenario there is no way to discuss the scope of the security test; it cannot be other than "the entire security of electronic voting system". Similarly, there is only one set of testing objects that must be tested, as shown in point A.2, thus freeing the tester from the need to define agreements of specific tests cases and escalation paths. Fixing assumption A.3 simplifies the process shown in section 3.1, allowing to avoid the following 3 steps out of the proposed 9:

-Information Gathering.

-Gaining The First Access. -Privilege escalation.

Notice that the tester does not need to verify the absence of privilege escalation or of remote/local access to the machine, not because these are irrelevant; on the contrary, the starting assumption means that the tester directly operates on the worst-case scenario assuming the attacker already owns this information.

OSSTMM Adaptation

OSSTMM provides a comprehensive concept of scope, allowing a vast variety of scenarios. For its application to the e-voting domain, it is possible to reduce the space of possible testing procedures by taking into account the assumption A.1 and A.2 as described in section 4.1. These allow to prune the the Scope Definition process, composed by the regulatory phase (cfr. page 25, sec. A.1 and A.2, OSSTMM light edition) and definition phase (page 26, sec. B.4 to B.7, ibid.). Another simplified step regards the information phase (cfr. pages 26-27, sec. C.8 to C.13, ibid.) where the tester should acquire as much information as possible about the system. According to the section 4.1 we reduce the information phase into the assumption A.3, freeing the tester from to the heaviest part of the information gathering task.

GNST Adaptation

GNST does not provide a detailed set of actions to define what it calls "Planning". It suggests to define rules, to acquire management approvals, to find financing and finally to set up the testing goals and testing objects. Although no strong guidelines are presented, each of the aforementioned steps is superfluous in the e-voting domain, where testing is clearly mandated and financed and testing objects have been previously clarified: the entire GNST Planning phase can be substantially collapsed by applying the constraints deriving from A. By assuming a tester point of view according to A.3, the whole "discovery phase" can be taken as an assumption, allowing insider and external security tests. Following the general methodology, if the tester cannot find a way to remote access the system, he skips all the insider attacks. Assuming A.3, even in this case the tester will perform the tests related to threats originating from a potential insider attacker.

Conclusion

Security testing is a fundamental phase in the life cycle of almost any system. Sensitive systems like those used for e-voting undergo particularly severe testing to attain certification of their security properties before usage into a real election. This exacting process should be based on one of the state-of-the-art methodologies described in section 3 of this paper. These exist to manage the planning and execution of testing procedures, taking into account the complex interrelations between the different parts and the huge amount of detail involved, on any kind of system. However, before being usable on peculiar systems, any methodology has to be adapted to the specific context. This paper described the common-denominator aspects, constraints and problems that characterize the whole class of e-voting systems, across their different instantiations (DREs, VVPATs, etc.). With this knowledge, it was possible to identify the procedures of the different methodologies that are most fit to this specific domain, and to provide some guidelines to instantiate them in the most effective way, by removing as many unnecessary steps as possible. A key step in this direction was fixing some unequivocal assumptions, as described in section 4.1. Assumptions work by explicitly stating the context elements that the tester can assume to hold without the need for verifying them, thus removing some degrees of freedom that otherwise leave manifold testing paths open, and eventually allowing to reduce the complexity of the testing phase. The (inital) result should be of help to prospective testers, strongly kick-starting the unavoidable phase of adaptation to the exact system they are dealing with. The ongoing work regards the refinements of practical details and the preparation of a case study to demonstrate the effectiveness of the proposed work on a real system.

Fig. 1 .

 1 Fig. 1. OSSTMM: The Scope Process.

Fig. 2 .

 2 Fig. 2. Transition from old to new assumptions

  1 and part of A.2. GNST's discovery phase has been defined as follow: -Network Scanning. -Domain Name System (DNS) interrogation. -InterNIC (whois) queries. -Search of the target organization's web server(s) for information. -Search of the organization's Directory server(s)for information. -Packet capture (generally only during internal tests). -NetBIOS enumeration (generally only during internal tests). -Network Information System (usually only during internal tests). -Banner grabbing.

  1) Voter Validation. The voter should reach the state where he is authenticated, registered and he has not yet voted. R.2) Ballot Validation. The voter must use the right ballot, and the ballot captures the intent of the voter. R.3) Voter Privacy. The voter cannot be associated with the ballot, not even by the voter herself. R.4) Integrity of Election. Ballots cannot change during the election time and the casted votes are accurately tallied. R.5) Voting Availability. Voters must be able to vote, all enabling materials must be available. R.6) Voting Reliability. Every voting mechanisms must work. R.7) Election Transparency. It must be possible to audit the election process. R.8) Election Manageability. The voting process must be usable by those involved. R.9) System State Requirements. The systems must meet the State certification requirements. R.10) State Certifications. The voting system must have the certification of the State where the election takes place (whether it considers the afore-listed requirements or a different set).