Serenity Project :: Motivations & Objectives

The SERENITY approach will be evaluated by exposing it to a set of industrial case studies emerging from a number of reference scenario domains. These scenarios have been chosen for the characteristics and complexity of the communication and information infrastructures the SERENITY framework is expected to manage. The scenario domains and their respective case studies are each provided by a particular industrial partner and carefully selected. They are all provided and driven by the major industrial partners and address their current products, solutions, and services in the AmI, service orientation, and mobility and ubiquity area. The SERENITY framework is intended to be used to provide security solutions in these products, solutions, and services, and thus guarantee the feasibility and exploitation of the approach.

Communications scenario
Future communication networks and infrastructure will accommodate many competing and complementing wireless access technologies based on licensed and unlicensed radio bands. They have to support nomadic user scenarios, ad hoc connectivity and high mobility with dynamic QoS and payment models. End-to-end connectivity will be reached either through operator or private networks or local connectivity or any dynamic combination of these. This will also form the basis for direct peer-to-peer communication modes. The heterogeneity, dynamicity, and flexibility of these networks raise major challenges with respect to identification and authentication of peers and the provision of trust and privacy.

Scenario : game application
Security challenges :

To avoid playing with unwanted identities
To avoid any interference from application to device, and vice & versa
To protect the exchanged data

SERENITY answers :

At design time : Interoperability with other vendors is a must, so the usage of the SERENITY framework in the development of the security mechanisms eases the job. The framework offers the languages, components and tools necessary, and for each device description or network connection the framework may suggest several different patterns to choose from. For protecting the communication channel, it might suggest using an integrity-preserving communication protocol or applying a digital signature to the messages that are communicated. For identification purpose the framework may suggest one time password or biometrics authentication. In order to provide a firewall between the platform and the application a combination of sandboxing and signing of the application and/or platform together with a form of TCB can be used. Patterns also indicate dependencies (for instance, a resource analysis pattern may require a specific ontology to be implemented).
At runtime, the framework can monitor the effectiveness of the deployed security mechanisms. In case of a standard password use, it can monitor threats such as password theft by checking rules that express normal temporal patterns of password usage and treating deviations from such patterns as potential identity thefts. It can also monitor for the possibility of scripting vulnerabilities such as the inclusion of scripts in messages sent by applications to the device that can harm and/or disclose sensitive device data. The SERENITY framework can also react to changes of environments with the provision of new patterns better suited to the new updated scenario. For instance, if the framework receives the signal that the mobile device has moved from a corporate Intranet connection (considered inherently secure by the current application) to an open Internet one.
During the beta testing, before the devices hit the market, the SERENITY framework monitors the behaviour of the application against the requirements stated in the design phase and specified in the chosen security pattern. If a violation occurs the SERENITY framework will discover it and ease the task to evaluate the cause of such violation. For Mobile Industry time-to-market is the overriding goal that has to be balanced with the potential security risks and loopholes.

Smart items
Dynamic and flexible networks of a large number of smart items that can be easily attached to physical entities and are able to monitor a number of conditions (e.g., environmental), to store information, and to communicate with IT systems by attaching to them in an ad-hoc manner pave the way for advanced business solutions involving planning, monitoring, and real-time reaction. This is particularly the case if the objects managed by the business systems are complex, physically distributed, not easily accessible (from the businesses location), and moving, like in maintenance, transport, and logistics scenarios. However, these networks are subject to increased risk and probability of attack, since their components (i.e., the sensors) may be exposed to the public, e.g., when attached to vehicles of containers, may be easily manipulated, e.g., because of cost and performance restrictions, or removed or destroyed. To be most useful, sensor networks and systems building on top of them should show a certain level of redundancy and fault tolerance, be able to deal with uncertain or less reliable information, and adapt flexibly to changing environment, e.g., the network structure.
In this application domain, potential case studies address the maintenance of moving objects like vehicles, and container security.

e-business
Modern enterprise information infrastructures are characterised by evolving from stand-alone systems supporting a well-defined and static set of business processes and interacting in a controlled way to open system landscapes providing and integrating services that can be flexibly composed to adapt to rapidly changing business needs. The infrastructure is driven by the evolving business processes and tightly integrates a set of services tailored to the situation at hand.
Such an Enterprise Service Architecture integrates services and components from different owners, is open to new services, and optimises investment needs by being able to integrate legacy services as well. In such settings, the owner of the business has to rely on the functionality and properties of components that are not completely under his control.

Scenario : enterprise software application
According to the application scenario, we envision the development of an enterprise software application through orchestration of a set of services that are made available through a service architecture. The service architecture is spanning over several organisations (companies), thus the set of services is not centrally controlled. A typical example is a supply chain application, consisting, from a simplified point of view, of tasks quotation (including subtasks request for quote, submit-quote, place-order etc.), order processing (including subtasks check-order, schedule-manufacturing, purchase-components etc.), and order fulfilment (including subtasks manufacturing, shipping, invoicing etc.). Each of the subtasks is provided by a service, potentially owned by different entities. Distributed ownership occurs, for instance, if subtasks are offered by specialist providers (e.g., invoicing or procurement is outsourced by a company).

SERENITY answers :
The SERENITY framework is used to implement the advanced security requirements : at the time of the design of the application with the help of advanced patterns and integration schemes, and at runtime through the deployment and monitoring support.
- At design time, we assume that the application developer is aware of the functional services he is about to orchestrate into his application, and the basic security mechanisms and properties they offer. This is a valid assumption for common development environments. Note that we do not require the security properties to be specified compliant to the SERENITY framework : requirements imposed by integration schemes may later be discarded informally. However, the approach provides stronger results if the security properties of the functional services can be mapped to SERENITY pattern descriptions, since this provides a stronger evidence for the claimed properties. Such a mapping can be achieved through the usage of the SERENITY framework in the development of the functional services.
First, the application developer specifies the advanced requirements through the SERENITY framework. For each requirement, the framework may suggest several patterns : for integrity protection, it might suggest using an integrity-preserving communication protocol or applying a digital signature to the messages that are communicated. Then, the patterns selected through the framework result in the design of a security architecture (i.e., a set of security services and their properties). Furthermore, the runtime validation mechanisms of SERENITY can monitor a range of security issues dynamically. SERENITY monitors can, for instance, be used to monitor the viability of the assumptions made by specific security patterns about the behaviour of the parties involved in them.

e-government
Union Governments aim to do administration services more citizen-oriented and wish to reply at the citizens’ and businesses’ demands for accessibility, responsiveness, simplicity and transparency of public services. It allows also an increase of public services productivity and efficiency with security, privacy and right of access guaranties, and legal respect.

Scenario : Tax portal
A typical case study from this domain will, e.g., be built on top of the platform realized at the request of the tax portal of French Ministry of Finance, offering numerous on-line services. Taxpayers will be able to make, at home, their declarations of income and fulfil their tax by using the portal. Income taxes, land taxes, business taxes and monthly tax payments will be managed by the portal. Taxpayers should be able to check their past declarations of incomes, from of its handheld device, for example. The tax collector will be able to verify income taxes, to make cross-checks and to ask additional information from taxpayers in a confidential way. Citizens should be able for instance to consult their Social Security refunds from their mobile phones or ask for the renewal of their ID cards, all this by being identified with the same certificate.
The SERENITY framework is used to implement the advanced security requirements : at the time of the design of the e-administration business process with the help of advanced patterns and integration schemes, and at runtime through the deployment and monitoring support.

At design time, the application developers need to decide the level of security the resources of target device are able to sustain (due to different hardware constrains and network connectivity)and which security mechanisms to implement in order to preserve the security properties required by the information processes and the need to know of the actors involved. For identification purposes, the framework may suggest one authentication mechanism based on certificates. Certificates might also be used to sign tax declarations. In order to provide a firewall between the platform and the application on a proxy server, a combination of sandboxing and signing of the application and/or platform together with a form of TCB can be used.
The patterns selected through the framework result in the design of a specific security architecture (i.e., a set of security services and their properties). The example shows that patterns are typically selected for each property in isolation. In order to avoid undesired interference between the patterns, the resulting architecture has to satisfy restrictions imposed by integration schemes. E.g., if we choose a VPN solution for confidentiality and a "signature pattern" for nonrepudiation, an integration scheme requires using different cryptographic keys for the patterns.

At runtime, during the beta testing, the SERENITY framework can be used to monitor the behaviour of the application against the requirements stated in the design phase and specified in the chosen security pattern. If a violation occurs the SERENITY framework will discover it and ease the task to evaluate the cause of such a violation : It could be due to an incorrect integration of several patterns or to an incorrect specification or implementation of the patterns themselves.

Air Traffic Management
The Air Traffic Management (ATM) is a very complex system, whose primary objective is to safely and efficiently accommodate the demand for flight through airspace. It is characterised by the need for a very high level of safety and by severe requirements in terms of security and dependability.

Current systems used in air traffic control have always been characterised by a limited sensitivity to dependability problems and to possible malicious attacks that could impair their integrity. They base their functions on data provided by radars that serve a local community of air traffic controllers, as a consequence these systems are well confined and protected from incorrect interactions with the external world, either non-intentional or malicious.

This case study offers to SERENITY the opportunity to refine and validate security and dependability patterns linked to different basic layers considered in Serenity, and in particular the organisational, workflow and network layers.

Some possible scenarios addressed by SERENITY :

Atmospheric disturbance : During the flight, the presence of an unforeseen atmospheric disturbance, evidenced by the cockpit equipment, obliges the pilot to request a diversion from his planned route, producing a delay on system that affects also other flights.
Re-sectorisation : An excessive workload for the air traffic controller of an ATC unit requires a dynamic re-sectorisation between this unit and an adjacent one.
System Failure with re-sectorisation : A system failure in an ATC unit requires an emergency re-sectorisation in which the responsibility for managing some aircraft is transferred from the unit experiencing the failure to the adjacent one.
Human Error : The controller in service in an ATC unit incurs in an error that is luckily detected by the controller of an adjacent unit. The error is notified to the controller who incurred in it and a procedure is started to return to normal operating conditions.

Scenarios

Scenarios validated through 5 case studies