OPerational Trustworthiness Enabling Technologies

(1)

OP

erational

T

rustworthiness

E

nabling

T

echnologies

D6.4.2 – Measurement and Management tools

(2

nd

release)

Document Number D6.4.2

Document Title Measurement and Management tools (2nd release)

Version 2.0

Status Final

Work Package WP6

Deliverable Type Prototype

Contractual Date of Delivery 30/7/2015 Actual Date of Delivery 19/8/2015

Responsible Unit IBM

Contributors Micha Moffie (IBM), Abigail Goldsteen (IBM), Natalia Razinkov (IBM), David Hadas (IBM), Willis Chen (UoS), Panos Melas (UoS), Bassem I. Nasser (UoS), Costas Kalogiros (AUEB), Kostas Sdrolias (AUEB), Torsten Bandyszak (UDE), Mohamed Bishr (UDE), Christian Heinz (UDE), Sandro Hartenstein (FHB), Gabriele Barni (TNL)

Keyword List Trust, Trustworthiness, Trustworthiness Attributes (TWA), Socio-Technical Systems (STS), Trust Attributes (TrA), Actions, Trust Maintenance,

Trustworthiness Maintenance

(2)

OPTET – 317631 | FP7-ICT-2011-8 Version 1.0 Page 2 of 120

Change History

(3)

Document Review

Review Date Ver. Reviewers Comments

Outline 28/4/2015 0.9 Dimitris Spiliotopoulos, Antonino Sabetta

Provided by email

Draft 26/6/2015 0.28 Dimitris Spiliotopoulos, Antonino Sabetta

Provided by email

Final 15/8/2015 0.59 Dimitris Spiliotopoulos, Antonino Sabetta

Provided by email

QA 18/08/2015 Sebastien Keller Provided by email

PTC

Glossary, acronyms & abbreviations

Item Description

AAL

_{Ambient Assisted Living}

AB

_{Advisory Board}

BSD

_See

_{http://www.linfo.org/bsdlicense.html}

CA

_{Consortium Agreement}

DOW

_{Description of Work}

EC

_{European Commission}

EU

_{European Union}

IPR

_{Intellectual Property Rights}

OPTET

_{OPerational Trustworthiness Enabling Technologies}

PC

_{Project Coordinator}

PCC

_{Project Coordination Committee}

PM

_{Project Management}

PO

_{Project Officer}

STL

_{Scientific and Technical Leader}

TB

_{Technology Board}

TBD

_{To Be Defined}

TL

_{Task Leader}

WP

_{Work Package}

(4)

Executive Summary

In this document we present the 2nd release of the measurement and management tools. We focus

on the progress made since the 1st_{release and describe the advancements made to maintain and} optimize both user trust and system trustworthiness. The different GEs/tools have been enhanced according to identified limitations of the 1st_{version, and integrated to cover all relevant aspects of} trust and trustworthiness maintenance. The main advancements include the following:

Full coverage of the trust-related aspects of runtime maintenance, including user behaviour monitoring, estimation of users’ perception of system trustworthiness, evaluation of trust related events and suggestion of mitigating controls.

Advanced support for selecting optimal controls for restoring trust and in a cost-effective manner.

Design and implementation of a user interface (i.e., the Maintenance Portal) supporting monitoring and exploration of a system’s trust and trustworthiness status.

Develop specialized sensors able to extract information from legacy mobile applications. Extend and apply the OPTET approach, techniques and tools to the cyber physical domain. We evaluate the different capabilities of our system and show how we coordinate multiple technologies and research prototypes into a coherent system able to maintain trust and trustworthiness. Our evaluation approach includes:

Application of the tool to the implemented DADV system

Verification of the correct functioning of the tools using three scenarios, based on the secure web chat use case, each aimed at exercising and demonstrating a certain capability of the tool.

(5)

Table of Figures

Figure 1 - Maintenance tools design ... 18

Figure 2 - UI Structure ... 19

Figure 3 - Level 1, with alert table ... 22

Figure 4 - Level 1 with notification tray open ... 23

Figure 5 - Level 1 with mitigation action window open ... 23

Figure 6 - Level 2.a, Interactions view, with alert table for Interaction 1 ... 24

Figure 7 - Level 3.a, interaction view with the trust values from the relative users... 25

Figure 8 - Level 2.b, user view with alert table of the user 2... 26

Figure 9 - Level 3.b.1 & 3.b.2, user view with details about trust levels for the user 2 ... 27

Figure 10 - Level 2.a, TW attributes view, with the relative alert table ... 28

Figure 11 - Level 3.a, TW attributes view, with the TW metrics for a selected attribute ... 28

Figure 12 - Level 2.b, assets view, with the relative alert table ... 29

Figure 13 - Level 3.b, assets view, with the TW attributes of a selected asset ... 29

Figure 14 - UBM model ... 36

Figure 15 - Trust Evaluation model ... 39

Figure 16 - Evaluation use cases ... 42

Figure 17 - SWC model using the WP2 trustworthiness model editor ... 53

Figure 18 - The overall contingency plan for the scenario produced by OCS ... 57

Figure 19 - Real world scenario model using WP2 trustworthiness editor ... 58

Figure 20 - Semantics vs. Performance tradeoff ... 65

Figure 21 - Android stack ... 67

Figure 22 - Instrumentation process ... 72

Figure 23 - Instrumentation screen shot ... 75

Figure 24 - Geo-distributed management and control ... 79

Figure 25 - In 2013, Manufacturing is at the top of the cyber incidents list ... 82

Figure 26 - Creating a universal DSM log source screenshot ... 88

Figure 27 - Configuring QRadar to accept log sources ... 90

Figure 28 - QRadar scada event ... 92

Figure 29 - Example IEC Raw Data (PCAP)... 95

Figure 30 - CSV result of preprocessing ... 95

(8)

Figure 32 - Register id=1 over time ... 97

Figure 33 - Signals on two different stable intervals ... 97

Figure 34 - Period of change vs. Stable periods in signal id=1 across transformers ... 98

Figure 35 - Close up to a period of change - periodical process is observed. ... 98

Figure 36 - Cyclic periods of change in signal id=1 ... 99

Figure 37 - Cyclic periods of change in signal id=3 ... 99

Figure 38 - IBM QRadar ... 114

Table of Tables

Table 1 - List of requirements [1]... 14

Table 2 - Tracing components to requirements ... 15

Table 3 - UI portal stakeholders list ... 16

Table 4 - UI portal requirements list ... 17

Table 5 - DADV evaluation scenario flow... 44

Table 6 - Overview of evaluation scenarios based on SWC ... 46

Table 7 - Trustworthiness Evaluation Scenarios ... 54

Table 8 - QRadar offence/event types ... 59

Table 9 - TWE Expected threats ... 60

Table 10 - Instances in the deployment model ... 61

Table 11 - Instrumentation framework comparison ... 70

(9)

1. Introduction

In this document we provide a description of our deliverable, the 2nd_{release of the measurement} and management tools. We present the different tools that have been integrated into the maintenance system, and demonstrate their ability to maintain system trustworthiness and user trust at runtime. The 1st_{release of the tools provided a solid foundation for analysing gaps (e.g., in} the integration of the different components) as well as planning and realising this 2nd_{release. The} future steps described in D6.4.1 have been thoroughly considered, to systematically enhance the tool’s functionality, quality, and applicability. Another important advancement is the user interface that serves as a central access point for administrators or service providers to get an overview of trust and trustworthiness evolution during runtime of the system. To this end, some more detailed requirements and concepts had to be defined and realised. Furthermore, the evaluation of the first prototype was only focused on mimicking the AAL system, which was at that time not yet implemented. Hence, applying the tools to the other two OPTET use case scenarios is also addressed in this deliverable. The updated version of the maintenance tools are also used in WP8 to perform an additional evaluation based on the implemented AAL and CCM use cases. Furthermore, to sustain the generality of the evaluation, we proceeded in applying it to a real-world system.

Section 2 presents the updated tool design, and shows how the requirements described in D6.3 [1] were addressed in this second release of the tools. We also provide an additional set of requirements developed specifically for the UI. In the following subsections we delve into the details of each of the major components, including the maintenance portal (UI), Monitor, Management and Mitigation. We describe in detail the algorithms implemented and clarify the advancements made since the 1st_{release in D6.4.1 [2].}

Next, in Section 3, different evaluation methods are described, which we used to evaluate the maintenance tools. The goal of the evaluation is to demonstrate that the tools are capable of supporting the whole trust and trustworthiness maintenance lifecycle. In particular, we present three evaluation scenarios based on the Secure Web Chat use case, aimed at showcasing the tool’s ability to maintain Trust, Trustworthiness and optimize service provider cost. Using these evaluation scenarios we also lay down the basis for showcasing the UI’s ability to display and support the maintainer in exploration and supervising the evolution and balance of trust and trustworthiness over time. We summarize the intermediate evaluation preformed during the second year based on the DADV use case. In addition we show how our Trustworthiness evaluator is able to cope with real world events from a real world system.

Finally, we present two works that broaden the scope of the Maintenance tools. In Appendix I we show how sensors can be used to extract and provide data from existing mobile applications to the Monitor. This work exemplifies how maintenance tools could be adapted to monitor legacy applications (i.e., applications that were developed without the OPTET life cycle). In Appendix II we show how the maintenance tools can be adapted to cyber-physical systems, and describe how the OPTET approach, techniques and tools can be utilized to monitor and analyse cyber-physical events.

(10)

1.1. Related work

This section aims at further discussing the OPTET T/TW Maintenance tools w.r.t. existing solutions for monitoring and maintaining trust and trustworthiness at runtime. Based on the SOTA analysis performed at an earlier stage of the project, we elaborate on existing commercial or free tools that are related to the approach and tools developed in WP6. In particular, this section provides an overview of related tools, and distinguishes them from our approach. Thereby, we enhance the SOTA from a practical perspective in order to complement the initial SOTA, which was mainly focused on the academic perspective.

Deliverable 6.2 [3] provided a comprehensive analysis of the state of the art related to overall trust/TW maintenance. In particular, the SOTA of run-time trust measurement, trustworthiness measurement, trust management, and trustworthiness management have been discussed separately. Based on the results of this analysis business processes for these four aspects in scope of the OPTET run-time trustworthiness maintenance have been proposed, which were later implemented in the actual tool. Hence, the fundamental concepts and techniques were in the focus of the SOTA analysis performed at this stage.

The following list provides a very brief summary of the SOTA presented in D6.2. For the detailed analysis results please refer to D6.2 [3].

Trustworthiness measurement: The trustworthiness of a system at runtime can be monitored online by logging its interactions [4] [5]. Comparing the system’s performance with TSLAs, which also define penalties for contract breaches, provides a base for runtime management. In a service provider/consumer architecture, online monitoring can be performed by trusted third parties on the communication network, as well as on the service provider side, or the service consumer side. In contrast, offline monitoring involves gathering trustworthiness information by conducting interviews to get feedback from the trustors. Both approaches can be combined, e.g., in [6].

Trustworthiness management: Approaches towards trustworthiness management at runtime, such as [7], focus on making decisions to control the system composition at runtime. This may involve, e.g., deactivating or replacing a component in case of a failure. Another issue of runtime trustworthiness management is supporting these control decisions (cf., e.g. [8]).

Trust measurement: To measure a user’s trust at runtime, surveys can be performed using different questions and scales for evaluating trust. For instance, questions could yield values of the perceived quality characteristics of the systems, and user’s confidence when using the system [9]. Another promising and challenging approach is to monitor and measure the user’s trust-related behaviour [10], e.g., in terms of mouse clicks. Furthermore, studies such as, e.g., [11] [12], indicate that there is a relation between the quality of experience (QoE) of the user and the perceived quality of the service (QoS), e.g. measured in response time.

Trust management: Literature on managing trust based on the measured QoS focuses on determining acceptable QoE levels (cf. e.g. [13] [14], and managing the system’s trustworthiness according to these thresholds by e.g. increasing resources (cf. e.g. [15]). The SOTA investigation summarized above was done during the design phase of the OPTET Maintenance tool, before implementing it. At the current stage, we provide a more technical view

(11)

on the SOTA by focusing on tools related to the current OPTET Maintenance system and its components.

Alhamazani et al. [16] analysed ten commercial monitoring tools that are applicable in the domain of cloud computing. Monitoring and managing the QoS, and agreeing on SLAs are relevant issues for providers offering resources and services in a cloud environment. Hence, the tools analysed in [16] are related to the OPTET trustworthiness maintenance tools. The following ten monitoring tools are covered:

Monitis [17] RevealCloud [18] LogicMonitor [19]

Nimsoft (now called “CA Unified Infrastructure Management”) [20] Nagios [21] SPAE by SHALB [22] CloudWatch [23] OpenNebula [24] CloudHarmony [25] Windows Azure FC [26]

These tools are related to the trustworthiness measurement and management. Regarding QoS monitoring, seven of these ten tools support monitoring composite QoS parameters, in addition to single parameters such as CPU utilization [16]. Similarly, the OPTET monitor allows computing complex metrics that use different system trustworthiness characteristics as input parameters. The CEP, i.e. the monitoring component responsible for trustworthiness monitoring, can be configured with complex event processing rules that aggregate these atomic values. The comparison presented by Alhamazani et al. [16] does not elaborate on trust measurement and management. The tools analysed are focused on resources and services deployed in cloud infrastructures, without considering, e.g., the perception by the user, or his/her behaviour of using the system that is to be monitored. The area of QoS monitoring provides the major part of available tools that are related to our approach regarding the monitoring and measurement of trustworthiness at runtime. Risk-management approaches to runtime management are rare, and to the best of our knowledge no tool support is available.

Regarding trust measurement, there are several tools available to design and perform surveys and questionnaires as user interviews. In WP2 (cf. [27]), interviews were used to gather trust attributes of the users (in WP2), and to classify users according to trust segments. In WP6, an experiment on measuring the user’s trust in fictional online banking services has been conducted (see [3]), in which interviews were performed to complement and validate the measures gathered from logging the user behaviour. However, the focus of the actual runtime trust maintenance tool is on the user behaviour, and the perceived trustworthiness. Hence, interviews are not employed as a monitoring tool implemented in WP6. Measuring and monitoring the user behaviour is facing increasing importance for the development of mobile apps. For instance, Appsee [28] allows developers to record the actions taken by the users of mobile apps. However, the intention is not to react on abnormal behaviour in real time, but rather to analyse the behaviour w.r.t. improving the apps in subsequent releases. Blindspotter [29] is a user behaviour monitor focusing on security

(12)

by identifying abnormal user activities such as hijacked account used by automated scripts, or a misuse of user privileges. However, to the best of our knowledge, there are no free or commercial tools that allow user behaviour monitoring for a broader range of usage characteristics. The field of QoE monitoring and management also provides some related tools that can specifically be used in by video streaming or video conference providers to measure the quality of their services perceived by the user. For instance, freely available tools such as QoE Monitor [30] and EvalVid [31] allow for calculating metrics determining the quality of video transmission from the user’s end. There are also commercial tools for monitoring video transmission quality, e.g. [32].

To summarize, the enhanced analysis of the SOTA w.r.t. available tools for monitoring and managing trust and trustworthiness reveals a lack of tools that combine trust and trustworthiness monitoring and maintenance. Furthermore, especially regarding the monitoring and management of trust at runtime, the SOTA does not provide solutions that integrate multiple views on the user’s trust. The OPTET approach of considering a multitude of different trustworthiness attributes is also difficult to realise using existing tools, since most of them support a pre-defined set of common operating system metrics (e.g., CPU utilisation). In contrast, a versatile and extensible set of metrics as well as related atomic events should be supported on the application level, i.e., in OPTET many different trustworthiness properties can be reported by different types of events if the system to be monitored is designed accordingly (following the WP3 guidelines for designing and implementing respective monitoring interfaces). Regarding the measurement of the user behaviour, there is also insufficient tool support that enables a flexible monitoring covering a multitude of different events tailored for the characteristics of specific STS. Furthermore, e.g. the lack of risk-based management approaches and tools constitutes a challenge imposed by insufficient flexibility of the existing QoS and QoE monitoring tools. Automatic management capabilities were also rarely found when analysing related tools.

(13)

2. Maintenance Tool

In this section we describe the maintenance tools in detail. First, we elaborate the requirements for designing and developing the tools, including a detailed presentation of the user interface requirements. Next, we present the final architecture and design of the second release of the maintenance tools. The subsequent subsections are structured according to the four main components/recipes (i.e., the Maintenance Portal, Monitor, Management, and Mitigation), and describe the different tools that are part of these components in detail.

2.1. Requirements

This section discusses the requirements for the trust and trustworthiness maintenance tools. To this end, we revisit the initial requirements specified in D6.3 [1], and elaborate on their final realisation in this second release of the tools. Furthermore, we present specific requirements for the user interface, i.e., the Maintenance Portal.

Requirements Traceability

2.1.1.

In Deliverable D6.3 [1] we identified key stakeholders of the Maintenance tool, their concerns, vision, and system requirements related to the concerns issued by the stakeholders. We also presented a first version of the tool’s architecture and design in D6.3. This initial design was refined in D6.4.1 [2], and has been implemented in the Maintenance tool.

The set of system requirements described in D6.3 was the basis for establishing the initial tool design. These requirements described the Maintenance tool in terms of solution-neutral, high-level functionality it should offer according to its stakeholder’s concerns. During the course of the project, the concrete design to be realised evolved (see D6.4.1 [2]) as the result of the various technical discussions about the tools and their interfaces.

In this section, we lay out how the requirements have been finally addressed in the realisation of the tool. To this end, we trace the revised architecture of components back to the requirements presented in D6.3, see Table 1. For more detailed view on the elicitation of these requirements (including reflected stakeholder intentions and concerns) please refer to D6.3 [1].

Requirement Specification

(1) Monitor STS T/TW by measuring properties and collecting relevant events

Measure properties and events from different resources: sub components, products and environment.

(2) Compute and Assess T/TW attributes

Relate measurements to sources and specialize metrics and T/TW attribute to each resource.

(3) Identify T/TW threats Identify threats to T/TW, Identify threat origin or resource

that may be impacted

(4) Mitigate T/TW threats Mitigate threats to T/TW. Utilize specific capabilities,

(14)

well as concrete system model

(5) Report on system T/TW state Report T/TW state, threats identified and mitigation actions taken. Specify T/TW for each resource. Include system configuration (events collected etc.) provide listing as to monitor data collected and steps taken.

Provide run time T/TW feedback for each resource.

(6) Read and parse certification Utilize information available in certifications to configure the system with properties, metrics and T/TW attributes

Compare run time values to T/TW attributes defined in the certificate

Table 1 - List of requirements [1]

To be precise, we focused on downward traceability between later development stages and the requirements. In contrast, the forward traceability of the requirements to its sources (i.e., stakeholder intentions and concerns) are already described in Deliverable D6.3. Table 2 relates the low-level components and GEs to the requirements (1) – (6) from D6.3. Please note that we focus on the core components, and do not elaborate on composite recipes and adapters.

Component

/GE Addressed requirement(s) Explanation (How does the component/GE address the requirement?) CEP (1) The CEP is responsible for monitoring trustworthiness-related events. Hence, it is configured to be able to accept and process the relevant events.

(2) Certain simple metrics are computed in the CEP as part of pre-processing the events coming from the STS, in order to represent them in aggregated form (i.e., as TW misbehaviours) to the TW Evaluation.

TW Metric

Tool (2) The Metric Tool allows calculating complex metrics as measures for TW attributes. (5) In addition, some metrics may not be used to identify misbehaviours (depending, for instance, the selected relevant TW attributes), but need to be calculated for informative reasons, i.e., to display graphs showing the evolution of certain measures over time to the maintenance operator. TME (2), (3) The TME calculates user-specific trust levels based on the TW

characteristics of the system (i.e., on the incoming raw events indicating the TW of the system).

(15)

computes and assesses the user-specific trust in terms of potentially suspect user behaviour, which allows for identifying trust misbehaviours.

Trust

Evaluation (3) Any potential threat that pertains to trust is identified by the TE component, which updates a trust model based on reported by the TME and the UBM.

TW

Evaluation (3) The TW Evaluation is responsible for identifying threats related to trustworthiness based on calculating threat likelihood for the involved assets.

(4) In addition to identifying threats, the TW Evaluation also issues control strategies and objectives so as to suggest potential (abstract) solutions to counteract the threats.

Report

Generator (5) The Report Generator prepares the information (i.e., the evolution of certain metric values over time) that shall be displayed in graphical form in the UI.

Control Identificati

on and

Selection

(4) The Control Identification and Selection selects the most suitable control that is adequate to mitigate the identified threats. It takes both the trustworthiness as well as the cost of the controls into account.

(6) In order to select a suitable control which is available on the Marketplace, its certificate has to be read. Taking cost information into account also requires querying the price of a control, respectively.

Maintenanc

e Portal (5) The Maintenance portal displays all trust and trustworthiness-related information and thus provides reports about the current state of the STS. This includes notifying the maintenance operator about the status of identified threats and related controls.

(3), (4) Additionally, displaying all relevant information (i.e., in addition to issuing automatically identified alerts and notifications of control deployments) allows the maintenance operator to supervise and identify threats or hazardous situations that could not be detected automatically.

Mitigation (4) The Mitigation component actually enforces a selected control strategy by performing the required control operations on the STS.

(16)

User Interface Requirements

2.1.2.

In this section we present the requirements of the Maintenance Portal UI. We begin by motivating the need for the UI. Next, we identify the main stakeholder of the portal and elaborate on his key activities. Lastly, based on the identified activities we draw a list of requirements which are the basis for the portal design.

The main goal of the maintenance portal user interface is to support the activities of maintaining trust and trustworthiness. The UI should assist the maintainer to comprehend the T and TW state of the system over time and attract her attention when necessary. The UI should clear and concise and present all information in real time.

Stakeholders

Table 3 lists the relevant stakeholder together with their key activities.

Stakeholder Key activities (related to maintenance) and stake

Trust and Trustworthiness

maintainer The maintainer has to keep constantly under control all the OPTET relevant parameters either of trust and trustworthiness. Considering the CCM use case evaluation, where the secure web chat application will be used (D8.1 [33], D8.6 [34]), the main stakeholder will be the SuperAdmin, the team leader of the incident response team (IRT – the team of experts in charge to handle an incident). He will thus monitor the ongoing conversations and the relative participants, in relation with the implemented parameters, making decision about possible mitigation actions, in case of T/TW threshold violations.

Key

activities Monitor the current and past state of either trust and trustworthiness; Detects any Trust and Trustworthiness violation;

Understand the root cause of the violation;

Guide the maintenance tool to choose the most appropriate mitigation action Table 3 - UI portal stakeholders list

(17)

Requirement

The requirements listed in Table 4 were used as input to the design and implementation of the UI portal.

Requirement Specification

(1) Display T and TW values Display all the necessary graphs to reproduce the trends, with respect to the time (current and past), of all the implemented T and TW parameters.

(2) Support the exploration Provide the user with the possibility of reaching a high level of detail, starting from a general view of the overall T and TW behaviours.

(3) Provide relevant information about the

system Visualize detailed information about the raised alerts, and the detected threats, following any T and TW violation.

(4) Notification feature Provide a notification system that makes the users anytime, no matter which page is actually displayed, aware of any relevant event about the status of the system (e.g. alerts and threats). (5) Propose mitigation actions Propose a list of applicable mitigation actions

after a set of threats have been detected.

(6) Select the mitigation action Given the proposed list of applicable mitigation actions, select and apply, one of them.

Table 4 - UI portal requirements list

2.2. Tool Architecture & Design

Figure 1 shows the final design of the maintenance tools. Compared to D6.4.1 - there are only very few changes. Those changes were made to the flow of data between components addressing the changes made to the API’s during development and integration. Overall, all the updates and modification made are consistent with the design made in D6.4.1.

In the next sections we summarize the changes made to existing components and provide details on new components.

(18)

(19)

2.3. Maintenance Portal

To support the stakeholder and the fulfil requirements listed in section Table 2 - Tracing components to requirements

User Interface Requirements0 (namely requirements (1), (2) and (3)), the UI has been designed with a hierarchical structure distributed among several pages: each of them displays different information about trust and/or trustworthiness with a different level of granularity.

Thus, considering the SWC use case, the interface will take into consideration the active conversations (i.e. chat room, interactions) and the relative users, together with all the trust and trustworthiness implemented attributes. Figure 2 below gives an overview of the entire structure. Particularly, starting from the top level (Level 1) that displays in a single graph two lines, one for the overall trust and one for the overall trustworthiness trends, the user can dig into different levels of details of trust and trustworthiness.

(20)

Trust

The active interactions and the relative users are used for defining further levels of details related to trust. These levels allow for digging into the available data, with level 1 showing the overall trust (as described above), and level 2 and level 3 showing specific trust information related to the interactions and the users. These are listed as follows:

Level 2.a: Displays a graph for every active chat conversation, containing the trust values for every user active into it, one line for each. The graph contains alerts on misbehaviours.

o Level 3.a: Displays a histogram for every user in the interaction (from level 2.a):

this contains the trust values for each trust sensor. In case of misbehaviours, alerts are reported.

Level 2.b: Displays one graph for every user active within the whole STS, each containing two lines; the overall trust value output evaluated by the UBM (considering every interaction the user participates) and the overall trust value calculated by the TME (considering every trust metric). The graph contains alerts on misbehaviours.

o Level 3b.1: Displays two graphs for a single user (from level 2.b): the first one contains all the individual trust metric values (from the TME output), and the other all the trust sensors bars evaluated across all the interactions the user participates (from the UBM output). In case of misbehaviours, alerts are reported next to the graph.

o Level 3.b.2: Displays a graph with the overall trust values for every conversation

(each is a line) the user (from level 2.b) participates. These can be filtered to show a subset of them. In case of misbehaviours, alerts are reported.

Trustworthiness

The relevant trustworthiness parameters are used for defining further levels of details related to trustworthiness. Like for trust, these levels allow for digging into the available data, with level 1 showing the overall trustworthiness (as described above) and level 2 and level 3 showing specific trustworthiness information related to the assets, TW attributes and TW metrics. These are listed as follows:

Level 2.a: Displays a graph with all the TW attributes (one line per each) for the whole STS with misbehaviours (alerts). Attributes can be filtered to show a subset of them.

o Level 3.a: Displays a graph with all the TW metrics (one line per each) for a

specific TW attribute from the Level 2.a, together with misbehaviours (alerts). Metrics can be filtered to show a subset of them.

Level 2.b: Displays a graph with all the assets (one line for each) for the whole STS with misbehaviours (alerts). Assets can be filtered to show a subset of them.

o Level 3.b: Displays a graph with all the TW attributes (one line per each) for a

specific asset from the Level 2.b, together with misbehaviours (alerts). Attributes can be filtered to show a subset of them.

To allow for exploration of past event (requirement (1)) we have designed and implemented DB tables storing the relevant events in both the Monitor and Management recipes. API was developed to allow the retrieval of select information in different time spans. For example, as detailed into D6.5 [35], the User Behaviour Monitor estimator provides the method getTimeSpanOverallTrust, that that, given a certain time frame, gets the overall trust value from the UBM evaluated across all the interactions and all the users.

(21)

In addition we developed a notification mechanism (to address requirement (4)) which allows the user to always be aware (regardless of the level he is currently exploring) of the relevant information about the monitored system status (i.e. T and TW alerts and threats).

Lastly, we introduced a mechanism able to query the user on the proposed mitigation actions (addressing requirements (5) and (6)). To this aim we have developed a set of API that, following the threat detection, provides the user with a list of possible mitigation actions (i.e. control strategy) to choose from.

Semi-automatic mitigation

2.3.1.

The Maintenance portal supports semi-automatic mitigation enabling the maintainer to select between several proposed controls. This approach is applicable for many situations including the experiment defined by WP8 in D8.6 [34]. Specifically, the interface provides a way for the superadmin, who is part of the Incident Response Team, to apply one of the controls proposed by the implemented GEs following a trust or trustworthiness violation has been detected.

Particularly, in the context of the trust experiments, the possible mitigation actions are:

Automated message back to the specific user with a predefined text, where this text could either be a positive or a negative notification;

Create a chat room where only the SuperAdmin and the specific user can communicate; Revoke the user access.

Implementation details

1

2.3.2.

The user interface is developed as a web application using HTML5 and CSS3 for the structure and presentation of the content, while JQuery for retrieving and displaying the data to be presented. It exposes also a REST method for receiving notifications about trust and trustworthiness alert, threats and controls from the Monitor and the Management recipes.

1_{At the time of submission of this document the UI portal was developed and in the process of integration.}

(22)

As described into section 2.3, the UI portal provides an hierarchical structure, composed of several different levels, each showing different kind on information related to the status of the system being monitored. Next, we present a walk-through the screen shot and the expected usage of the UI.

We begin with Figure 3, which shows the Portal’s ‘home page’ – the overall system Trust and Trustworthiness levels. This screen also shows the alerts handled by the system. To avoid frequent pop-ups, the user is notified of new alerts using an icon on the top right (bell icon) and only when the user clicks it, the complete alert information will be displayed (see Figure 4). The notification table enables the user to immediately take action2_{by pressing the ‘Take Action’ button. If the user} decides the situation requires mitigation, several controls are displayed for the user to select the most appropriate one (see Figure 5).

Figure 3 - Level 1, with alert table

2_{Note, based on configuration, the system may take select mitigation actions automatically or query the}

(23)

Figure 4 - Level 1 with notification tray open

(24)

Before a mitigation action is selected and deployed, the user may want to better understand the cause of the alert and pinpoint the precise TW or T issue. To this aim, the UI support the user in the process of exploration. For example, Figure 6 displays a separate graph containing Trust information for each chat. Each graph shows overall trust values for each user participating in that chat. Additional information is displayed in Figure 7 where the trust values of each trust sensor are shown for each user. This functionality supports pinpointing a specific user with low/high trust and allows to determine the reason(s) for this trust level (based on the sensors).

(25)

Figure 7 - Level 3.a, interaction view with the trust values from the relative users The starting point of Figure 6 and Figure 7 was a specific chat (interaction) supporting the exploration of T issues that are confined to a select chat (e.g. several users in a select chat display low trust). However, there may be cases where users are participating in multiple chats or cases in which system wide events impact user trust - and thus a different type of view is needed. This issue is addressed by Figure 8 and Figure 9 - which support a user centric view. Figure 8 shows user trust (computed separately by UBM and TME) for every user in the system. Figure 9 provides further details for a selected user. Specifically, it details trust metric values (from TME) and trust sensor values (from UBM) to pinpoint the root problem of the trust issue.

(26)

(27)

Figure 9 - Level 3.b.1 & 3.b.2, user view with details about trust levels for the user 2

The UI also supports the examination of TW related events on system trustworthiness. Figure 10 shows TW attribute values for the whole system while Figure 11 details the trustworthiness metrics values for each specific TW attribute. Figure 12 and Figure 13 support asset centric views and the examination of assets specific behaviour and TW. Figure 12 shows the overall TW behaviour of each asset while Figure 13 details the TW attribute for each asset.

(28)

Figure 10 - Level 2.a, TW attributes view, with the relative alert table

(29)

Figure 12 - Level 2.b, assets view, with the relative alert table

Figure 13 - Level 3.b, assets view, with the TW attributes of a selected asset For a detailed list and description of the API, you can refer to D6.5 [35]. For a detailed set of screen shots of the UI, you can refer to Appendix IV.

(30)

2.4. Monitor

This section describes the main updates made to the Monitor recipe and sub-components since D6.4.1 [2].

The trust flow and integration with the Trust Metric Estimator (TME) and User Behaviour Monitor (UBM) have been slightly updated to better support trust related scenarios. In the current implementation, raw (atomic) events from the STS are forwarded to both the TME and the UBM, and both of these can generate trust related alerts (misbehaviours). These alerts are then forwarded to the Management component to be processed by the Trust Evaluator.

In addition, several new APIs have been added to support integration with the Maintenance Portal. These APIs enable querying TW metric and attribute values for the whole system or for a specific asset, as well as an overall TW value for the system. These APIs are detailed in D6.5 [35] and are implemented as follows:

TW metric values for a specific asset are computed directly from the raw events received

from that asset and saved in the Optet_Maintenance_MeasurementDB database. Each metric

requires a specific type of raw event to be retrieved from the DB and the computation of the

metric value is performed by the Metric Tool.

TW attribute values for a specific asset are computed by taking the minimal value of all TW

metrics that are part of the attribute.

TW metric/attribute values for the whole system are computed by taking the average of the

values of all assets in the system.

The overall TW value for the system is computed by taking the average of all relevant TW

attributes.

Another possibility is to integrate the Maintenance tools with the End-to-end TW Evaluation tool (from WP3) to correctly compute the TW metric and attribute values for the overall system based on the system deployment model and system workflows (see D3.4 [36] for more details), as well as enable the user to determine weights for each TW attribute in the calculation of the overall TW value for the system.

Complex Event Processing

2.4.1.

The Complex Event Processing component (CEP) is the part of the Monitor recipe, which is responsible for processes the raw events related to Trustworthiness maintenance. Respective events are forwarded to the CEP by the Monitor Adapter. The CEP is responsible for performing a first analysis and aggregation of these raw events in order to identify misbehaviours. These misbehaviours are then reported to the Management for further analysis. For more information on the CEP’s functionality and interfaces, please refer to D6.4.1 [2].

As described in D6.4.1, we use the CEP Engine Proton, which is available on the FI-WARE catalogue [37]. There was no need to adapt or enhance Proton’s functionality compared to the previous version since Proton is a powerful event processing tool that can be configured to support a variety of potential applications. In particular, the following configurations have been implemented to support the evaluation scenarios (see Section 3), and the application in WP8:

Y3 demo scenario (DADV use case)

: The CEP configuration supporting the DADV use case

comprises Event Processing Agents (EPAs) that aggregate the input from different Sensors

or honeypots supervising a corporate network (see Section 3.1). The EPAs evaluate the

resource utilization of the sensor, and create misbehaviour events to report high resource

(31)

usage to the TW Evaluation, in case a certain threshold level is exceeded. Another EPA

monitors the number of outgoing connections, which are also reported by each sensor. If an

outgoing connection is detected, a “compromised sensor” misbehaviour is issued.

TW evaluation scenario (Secure Web Chat use case)

: For the SWC use case, the

trustworthiness monitoring focuses on the availability and flexibility/robustness of the chat

service. Hence, the CEP configuration is designed to detect misbehaviours in terms of a

mean availability metric that is computed by EPAs aggregating the periodic events that

indicate the current availability of the SWC. Furthermore, the ratio of exceptions that could

be automatically recovered by the SWC over the number of all exceptions that occurred

during runtime is calculated, and respective misbehaviours are reported when a certain

threshold is reached. For more details on the TW evaluation scenario see Section 3.2.2.

Metric tool

2.4.2.

The metric tool, as described in D6.4.1 has been updated. The following updates are relevant to the monitor:

Improved stability as a result of changing the technical provider

Improved speed as a result of code optimizations

Extension of the metricsdata

Extension of the api

Extension of the computation model

The API is fully described in

deliverable

D3.3 [38]section 7.1.2.3.

2.4.2.1 Extension of metricsdata

Additional information is required for the correct calculation of attributes, which are addressed by several metrics. Also, an additional field is necessary for the interpretation of the metric values. The metrics have gotten an update on properties:

Compositiontyp – specify aggregation type for the metric (e.g. avg. min, max)

Higherdesirable – specify whether higher of lower values are desirable

2.4.2.2 Extension of api

The metrictoolapi provides a restful stateless webservice. . The API has been extended to provide combined information quickly. The new path is “metrictoolapi/attributesmetrics”. It shows the trustworthiness attributes and their assigned metrics.

2.4.2.3 Extension of the computation model The computing engine is now available via restful api: URI: metrictoolapi/instant

(32)

{

"formula": "X=A+B+C", "param": "9.2,10,4" }

To further support the consuming component two new calculations has been implemented:

AVG – provides the average value from a set of inputs

K Min / k Max – provides a k – position of a max / min - sorted list of inputs

Trust Metric Estimator

2.4.3.

The Trust Metric Estimator is a Bayesian computational model that aims to estimate a user's trust level in a system over time for a number of metrics; for instance trust with respect to reliability, confidentiality, etc. Those trust levels depend on the personality attributes of each trustor and the system outcomes (raw/atomic events) observed. Whenever the current trust level of any user in the system exceeds the minimum or higher threshold set by the administrator a trust-related alert is generated and forwarded to the Management component for further processing. Furthermore, the evolution of trust levels are persistently stored and provided to other maintenance tools such as the Maintenance portal and the Optimal Control Selector. More specifically, the portal can retrieve the historic trust levels at several aggregation levels (going from the most fine-grained values up to the more aggregated ones):

trust

values

for

a

particular

user

and

metric

using

the

method

getTimespanTMETrustMetricValue (userName, metricName, timeBegin, timeEnd) with the

following output format

,

[{

"trustValue": “0.74560422”, "time": "25/02/2014-09:15:00" }]

average trust level for a particular user (across all metrics) using the method

getTimespanOverallTrustUserInteraction(username,

timeBegin,

timeEnd)

with

the

following output format,

[{

"trustValue": “0.708864245”, "time": "25/02/2014-09:15:00" }]

average trust level for all users in system or service instance (such as conversation/

chatroom) using the method getTimespanOverallTrustAllUsersInteraction(convName,

timeBegin, timeEnd) with the following output format

(33)

OPTET – 317631 | FP7-ICT-2011-8 Version 1.0 Page 33 of 120 [{ "userName": "user1", "trustValue": 0.776174571, "time": "25/02/2014-09:15:00" }, { "userName": "user2", "trustValue": 0.826174571, "time": "25/02/2014-09:15:00" }]

In order to calculate personalised trust metric values, users are grouped into segments based on their responses to a set of questions prepared by WP2. Thus for each user of the system we need the segment she belongs to, namely “High Trust”, “Highly Active Trust Seeking (HATS)”, “Medium Active Trust Seeking (MATS)” or “Ambivalent (A)”. This information, together with details about the system and the metrics is currently hard-coded and is part of the initialization procedure that is performed by invoking the String init() method.

For any segment the following information is kept:

, which is a measure of that segment’s trustors’ confidence that the system will fulfil its

objectives

as a measure of that segment’s trustors’ belief that the system will not meet its

expectations

is the effect of each system’s success on the trust level of the average trustor in that

segment

is the effect of each system’s failure on the trust level of the average trustor in that

segment

the initial trust level for each user belonging to segment, which is given by the following

formula

. Thus, whenever a user is registered its initial trust level for all

metrics will have been computed (and their values will be equal).

The values , , and for all segments are set using the method updateSegment (event) while other components (such as the Optimal Control Selector, see below) can retrieve those using the method String getAllBetaParameters(segmentName, MetricId). Furthermore, the method String getServiceInstances() can be used for retrieving the number of users per segment in every active service instance. Similarly, the method String getConversationStatus(conversationId,

(34)

metricId) when invoked returns the service instance’s status with regard to number of transactions that have taken place so far and the number of successes.

Furthermore, for each metric the administrator must define3_:

1. a threshold

that denotes the criterion for characterizing a particular atomic event as

successful, or not (e.g., it could be standardised or based on best practices). In the case or

response time, for example, this threshold would suggest the maximum waiting time for

receiving a response

before marking a transaction as unsuccessful. Remember that

after a successful transaction the user’s trust level is increased, otherwise is decreased. Both

updates take place using rates that are carefully selected to mirror user’s personality.

2. a threshold

on users’ trust level that if exceeded a "low trust" alert is triggered

3. a threshold

users’ trust level that if exceeded a "high trust" alert is triggered

Thus after receiving an atomic event for a particular metric, the TME performs the following steps:

1. characterizes the transaction as successful or not.

2. update the trust level of all users involved in that transaction. This is done using the formula

where the exact values for

,

, and depend on the

segment that the user belongs to.

3. TME checks whether any alert should be sent to Trust Evaluator (TE) GE. More

specifically, if

then a “low trust” alert for metric is sent,

while a “high trust” alert is sent if

. This is done for all

users whose trust level was updated at the previous step.

The alert contains the following information

{

"idNotification": "00000001", "GEsource": "TME",

"time": "25/02/2014-09:15:00" }

while other components that want to retrieve more details can use the method getTrustMetricAlertInfo(idNotification), whose output has the following format

3_{Note that although} _, _and _{are system-specific, the users’ trust level can differ. Even}

though is system-specific, customers usually interact individually, as well as, at different frequency rates, and assuming that failures are not correlated we can expect that their trust level will differ. Even if customers interact synchronously (or transaction outcomes are broadcasted like in the case of chat rooms) then customers belonging to different segments are assumed to react differently on observed transactions and this is enough to differentiate the trust levels of users across segments.

(35)

OPTET – 317631 | FP7-ICT-2011-8 Version 1.0 Page 35 of 120 { time: "2015-06-19 15:04:10.0", convName: 1, typeAlert: "LowTrust", trustValue: 0.46, userName: 9, trustMetric: 1 }

User Behaviour Monitor

2.4.4.

The User Behaviour Monitor (UBM) component is part of the Monitor recipe. Its purpose is to measure trust-related behaviours of individuals through so-called ‘sensors’, while using any type of socio-technical system. The UBM continuously monitors these behaviours and relates them to trust disposition of the user and to a model of trust in the system. If trust is decreasing, an alert will be provided either to the user, the system administrator, or, to the system itself. Mitigation will then need to take place to restore trust in the use of that particular service.

The UBM component is responsible for collecting trust-related atomic events from different sources, storing these in a persistent database, and performing initial processing of these events to aggregate them and computing trust metrics. When a certain measurement reaches its predefined threshold, an alert will be generated and sent to the Management recipe to decide on a course of action. The UBM is responsible for monitoring the behaviour of a user interacting with a target system (e.g. Secure Web Chat) in order to make an estimation of their trust level, and send alerts to the Management GEs.

The actual monitoring operations are accomplished by the usage of a number of sensors, each responsible for monitoring a different specific user activity. Every sensor is composed of three fundamentals parameters:

LowThreshold

: used to raise alerts in case the trust level estimated by the relative sensor

drops under this limit, possibly indicating a low trust perceived by the user;

HighThreshold

: used for raising alerts in case the trust level goes above this limit,

suggesting that the system is over performing, and the proper mitigation actions should be

carried out;

Weight

: used to evaluate the overall trust level of a user.

The UBM consists of three main entities:

Generic (User) Trust Model

: A model composed of a list of sensors (specific for the

application). For each sensor, the correspondent weight, for the evaluation of the overall

trust, and thresholds, for sending alerts, are set;

Trust Estimator

: Takes inputs from sensors and process them, and consecutively (at a later

stage of development) sends alerts to the management and mitigation GEs in the case a

user’s trust level violates one of the predefined thresholds;

(36)

Figure 14 - UBM model

The UBM provides a set of interfaces, thus offering the following features:

Sensors configuration for the running services

: setting the relevant parameters

(thresholds and weight) and update technique (depending on the application, takes the input

from the user events and use them to update the relative perceived trust level);

Information extraction

: getting information about the users behaviour and the interactions

in which they are involved (relative trust levels and alert information);

Alert generation

: raise an alert in case the user’s trust level violates one of the predefined

thresholds.

The Generic Trust Model and the Trust Estimator provide the most important interface to achieve these purposes.

Plugging to a new service

In order to be adapted for working with different services, the UBM requires some preliminary configuration steps with the purpose of configuring the Trust Model and the Trust Estimator. These can be summarized as follows:

Sensor configuration

: this includes setting the relative

thresholds

(either low- and

upper-trust boundaries) and the

weight

for each required sensor;

Consuming new raw event data

: given a new raw event data from the running application

(e.g. information from a chat message) configure the way the relevant information are

extracted and then used for the trust computations;

Sensor update technique

: based on the inputs from the system, define the way each sensor

updates its relative trust level;

Sensor plugging

: configure the sensors in order to acquire the required raw event data from

the running service;

(37)

Starting trust value

: setting the initial trust level for each sensor configured.

2.4.4.1 UBM Configuration

Integration of the UBM has been performed within the secure web chat application, that will be used in the context of the CCM use case [33]. This application allows the exchange of messages and other multimedia content in a secure way, thanks to the encryption and decryption of the content sent and received. The UBM monitors the messages exchanged within the conversation topic, thus retrieving a set of properties to use as inputs to the implemented sensors, and providing a value for the trust (for each sensor) with a range of [0–1] per user.

Sensors implemented

The initial trust behaviours for the implemented sensors were taken from [39]. These parameters were then used to conduct a generic, online experiment, as described in [3], where a set of users was asked to perform a number of different tasks in a banking application service. This service also included a chat application for user support, to explore behavioural patterns.

The results from the experiment (described in [40]) provided important guidelines addressing the choice and configuration of the sensors within the context of the secure web chat, although the two applications are intended to be used in two slightly different contexts: for the banking application the interactions are between the users and experts, while in the secure web chat these are between users (described in [34]).

Particularly, the results showed that the most promising set of behaviours for trust were the time spent on a service and initiated type of messages. Although not any sort of statistical analyses were carried out to substantiate the outcomes of the experiment thus confirming, or negating, that these can be applied into another context than the banking application, these might be good predictors of a user’s trust level in a generic system, where for example more time spent on a service, and/or an increase in the number of chat messages initiated, might indicate a low level of trust.Hence, we employed these sets of behaviours in the context of the secure web chat. In particular, for the ’time spent on a service’, the reasoning is that a user spends more time on a service because s/he needs to better understand the usage and the features of the system. In contrast, for the ’number of chat messages’, the user has difficulty understanding the topic of the discussion (e.g. a chat conversation), or does not trust the other users s/he is interacting with, e.g. the other users participating in the chat conversation. Note that the generated alerts should be analyzed and validated by an operator, who is monitoring the users, e.g. an administrator who analyses a trust alert by comparing it to the chat contents of a certain user, and so decide about the successive mitigation actions. On the basis of the above-mentioned sets of behaviours, four sensors were derived and are listed below:

Response Time

: time spent by a user to answer a question;

Message Load

: number of messages sent by the user;

Message Length

: length of the messages sent;

Question Load

: number of questions messages sent by a user.

These sensors are assumed to make it possible to estimate the trust level of a user in relation to one or more users involved in an online discussion.

With minor alteration to the Generic Trust Model and the Trust Estimator, this component can be re-used for other use cases within Optet (e.g., AAL).

OPerational Trustworthiness Enabling Technologies

OP

erational

T

rustworthiness

E

nabling

T

echnologies

D6.4.2 – Measurement and Management tools

(2

release)

Change History

Document Review

Glossary, acronyms & abbreviations

Ambient Assisted Living

Advisory Board

See

http://www.linfo.org/bsdlicense.html

Consortium Agreement

Description of Work

European Commission

European Union

Intellectual Property Rights

OPerational Trustworthiness Enabling Technologies

Project Coordinator

Project Coordination Committee

Project Management

Project Officer

Scientific and Technical Leader

Technology Board

To Be Defined

Task Leader

Work Package

Executive Summary

Table of Contents

Table of Figures

Table of Tables

1. Introduction

1.1.

Related work

2.

Maintenance Tool

2.1.

Requirements

Requirements Traceability

2.1.1.

User Interface Requirements

2.1.2.

2.2.

Tool Architecture & Design

2.3.

Maintenance Portal

Semi-automatic mitigation

2.3.1.

Implementation details

2.3.2.

2.4.

Monitor

TW metric values for a specific asset are computed directly from the raw events received

from that asset and saved in the Optet_Maintenance_MeasurementDB database. Each metric

requires a specific type of raw event to be retrieved from the DB and the computation of the

metric value is performed by the Metric Tool.

TW attribute values for a specific asset are computed by taking the minimal value of all TW

metrics that are part of the attribute.

TW metric/attribute values for the whole system are computed by taking the average of the

values of all assets in the system.

The overall TW value for the system is computed by taking the average of all relevant TW

attributes.

Complex Event Processing

2.4.1.

Y3 demo scenario (DADV use case)

: The CEP configuration supporting the DADV use case

comprises Event Processing Agents (EPAs) that aggregate the input from different Sensors

or honeypots supervising a corporate network (see Section 3.1). The EPAs evaluate the

resource utilization of the sensor, and create misbehaviour events to report high resource

usage to the TW Evaluation, in case a certain threshold level is exceeded. Another EPA

monitors the number of outgoing connections, which are also reported by each sensor. If an

outgoing connection is detected, a “compromised sensor” misbehaviour is issued.

TW evaluation scenario (Secure Web Chat use case)

_{Ambient Assisted Living}

_{Advisory Board}

_See

_{http://www.linfo.org/bsdlicense.html}

_{Consortium Agreement}

_{Description of Work}

_{European Commission}

_{European Union}

_{Intellectual Property Rights}

_{OPerational Trustworthiness Enabling Technologies}

_{Project Coordinator}

_{Project Coordination Committee}

_{Project Management}

_{Project Officer}

_{Scientific and Technical Leader}

_{Technology Board}

_{To Be Defined}

_{Task Leader}

_{Work Package}