SecureChange

Year 3 Summary

BME — Fri, 23 Mar 2012 14:07:46 +0000

In the course of the first year the project has developed new models, methodologies and processes to guarantee security during software evolution. During the second year the SecureChange partners have consolidated these results into a conceptually integrated process and sharpened the project focus to address specific challenges from the industrial case studies of the project. The third and final year of the project focused on the industrial validation of the project results on the basis of real industrial scenarios in the domains of Air Traffic Management, Smart Cards Software Evolution, and Home Appliances.

Download the Year 3 Summary Report here, or read some quick facts below (after the break).

During the final year of the project, the industrial case studies supported a validation of the SecureChange artefacts. SecureChange results have been evaluated according to the validation criteria identified in previous years. The validation scenarios and exercises involved domain experts and case studies (i.e. ATM, HOMES and POPS). This allowed us to collect feedback drawn from relevant industrial experience, and to assess how SecureChange artefacts would fit current industrial practices. Deliverable D1.3 (Report on the Industrial Validation of SecureChange Solutions) reports and discusses the validation results.

Meanwhile, the technical work packages continued to refine the previously developed methodologies, algorithms and tools. As the industrial validation results were coming in during the year, the focus expanded to addressing the concerns raised in the domain experts' feedback. For detailed results, the project deliverables of Year 3 are now also available on the Deliverables page.

During the third year of SecureChange, the project partners delivered roughly 50 additional presentations and published more than 70 papers addressing different topics of the project (13 journals articles, 53 conference/workshop publications; 4 books or book chapters and more reports), delivered several tutorials, tool demos and invited talks. Altogether during the entire span of SecureChange, project partners have developed 8 courses and additionally 8 lectures where SecureChange results were integrated. In addition, there are 21 PhD theses which have been completed or close to completion – all of which are centred around research topics of SecureChange. Project partners have been very active in developing research prototype tools to provide feasibility study and practical validation of the scientific results. SecureChange proudly announces that as many as 8 tools have been developed completely within the scope of the project, while an additional pre-existing 9 tools have been continued to be developed. Most project tools - the Move Tool, the SecMer tool (and the underlying engines EMF-IncQuery and OpenArgue), the CARISMA tool, etc. have been made available on the web and there is a significant interest in their usage. The Rinforzando Tool developed by Thales is now in the process of de-risking for direct adoption in production environment. The results on the EvoTest tool by SmartTesting have been ported to the production environment. The promising results of the SecureChange integrated process have contributed to the foundation of a spin-off company: QE LaB Business Services GmbH (http://www.qe-lab.com/).

Read more about the overall progress of the project in the Year 3 Project Summary.

SecureChange involvement in 1st International Workshop on Eternal Systems (EternalS'11)

BME — Fri, 23 Mar 2012 11:11:50 +0000

The EternalS Coordination Action has established three Task Forces (TFs) working on topics that crosscut the interests of the four participating FET projects. Secure Change is strongly represented in Task Force 2 “Time Awareness and Management in EternalS systems”. The TF is led by Michael Hafner and Michael Felderer of UIB. TF members include Riccardo Scandariato and Koen Yskout of KUL and Ruth Breu of UIB.

The First International Workshop on Eternal Systems (EternalS'11) has been held on May 3, 2011 in Budapest. The workshop was affiliated with the European Future Technologies Conference and Exhibition (FET 2011) and sponsored by the European Coordination Action EternalS. EternalS'11 aimed at creating the conditions for mutual awareness and cross-fertilization among broad ICT areas such as Learning Systems, Software Systems, Networked Systems and Secure Systems. The workshop issued a call for high quality contributions in the above-mentioned areas and selected them by means of a peer review process. Out of the fifteen received submissions six full papers and four short papers have been accepted for inclusion in the proceedings published by Springer (CCIS volume 255). SecureChange contributed to the workshop program with two talks, held by Michael Felderer and Riccardo Scandariato respectively.

Read more on the workshop website: https://www.eternals.eu/workshop-2011/

Year 2 Summary

BME — Wed, 25 May 2011 08:52:50 +0000

In the course of the first year the project has developed new models, methodologies and processes to guarantee security during software evolution. Now in the second year the SecureChange partners have consolidated these results into a conceptually integrated process and sharpened the project focus to address specific challenges from the industrial case studies of the project.

Download the Year 2 Summary Report here, or read some quick facts below (after the break).

We have run a number of feasibility studies that have been carried out on each case study of the SecureChange project. The feasibility studies assess the applicability of the artefacts developed in the SecureChange technical WPs to solve the change-related security problems arising within each industry domains. Read more in the D1.2 Report on the Applicability of SecureChange technologies to the Scenarios.

Meanwhile, the technical work packages have commenced to improve their previously proposed models, methodologies and processes. The second year also provided the time frame to design new languages and mechanisms, and finally to develop tool prototypes. For detailed results, the project deliverables of Year 2 are available on the Deliverables page.

The dissemination activities of the second year of the SecureChange project included a presentation of the project at the Project Track of the MODELS 2010 conference in Oslo, Norway to disseminate research questions and first research results to the scientific community. Additional presentation has been done at a number of EU events such as ICT. The project partners delivered roughly 30 additional presentations and published more than 50 papers addressing different parts of the project. In 2010 we had:

44 project meetings and 43 events (workshops, conferences, seminars, exhibitions, etc.) organized or attended by SecureChange partners;
13 journals publications;
35 conferences publications;
4 book chapters and 2 reports.

The SecureChange project collaborated with other FET projects by contributing to dedicated
workshops and meetings coordinated by the EternalS coordination action. Furthermore, the project organized several internal workshops and meetings to strengthen integration within the project. Industrial partners have identified promising and potentially usable results for exploitation.

Read more about the overall progress of the project in the Year 2 Project Summary.

The SecureChange Process

BME — Mon, 12 Apr 2010 07:58:44 +0000

Existing security engineering or change management processes (e.g., SDL, ITIL Change Management) are able to identify the major activities and artefacts of security or change management, and catalogue the vulnerabilities and safeguards of the system. However, process steps have to be performed in a fixed sequence on the whole system and its artefacts, and usually the analysis of change effects is not supported. To overcome these limitations in SecureChange a change-driven security engineering process is developed.

The following figure summarizes the actors and artefacts of the SecureChange process.

The main characteristics of the SecureChange process are the following.

Design activities driven by change and change propagation;
Change propagation based on documented interdependencies between artefacts;
Supporting the collaboration of stakeholders;
Supporting a rigorous model-driven approach.

The responsibilities and benefits when using the SecureChange process for the main actors can be summarized as follows.

Stakeholder

Responsibilities: Identify requirements / practical problems, provide domain knowledge.
Secure Change results: Assessment of solutions in change management with respect to security.

System Architect

Responsibilities: React to change events triggered within or outside the own scope, continuously configure security services.
SecureChange results: Tool-supported change-driven security engineering process, architectural change patterns, highly configurable security architecture.

Requirements Engineer

Responsibilities: Elicitation, Validation, and Verification of Security Requirements.
SecureChange results: Graphical representation of requirements evolution; change management process; tool for change impact analysis.

Security Expert

Responsibilities: Define, operationalize and implement security strategy; introduce security related updates and enforce security of general system patches
SecureChange results: Change driven tool-supported security analysis & engineering approach

Risk analyst

Responsibilities: Risk analysis of changing and evolving systems.
SecureChange results: Methods for systematic identification, analysis, and evaluation of changing and evolving risks in changing and evolving systems.

Verification Expert

Responsibilities: Maintaining security of evolving software (development- and run-time).
SecureChange results: Verifiably safe exception handling and dynamic code loading; on-device information flow verifier for open systems.

Test Engineer

Responsibilities: Test case Creation and Execution, Quality evaluation / Reporting.
SecureChange results: Automatic test suite completion, integration in common process.

A Taxonomy of Change

securechange — Tue, 06 Apr 2010 11:16:10 +0000

In SecureChange a taxonomy was developed to help to “scope” the project activities. The taxonomy had to have enough classification power to distinguish all project activities, show their similarities, and clarify their scope of investigation. The taxonomy has two main sides of classification:

Problems: How things change,
Solutions: How we deal with changes.

The following figure summarizes the taxonomy of change.

The categories of the classification can be defined as follows.

Time

One-Off: Evolution is described by single transition, for example before and after a major overhaul of the customer application. Such change might be the results of many local changes but they are not explicitly described.
Discrete: Evolution is explicitly represented by many steps, for example the interleaving of local changes in the overall system, or sequence of discrete events explicitly captured.
Continuous: The properties of some systems components are described by a continuous function of time.

Nature

Actual: The world has already changed wrt some SecureChange artefact, we need to update the description of the status quo.
Expected: The change has not yet happened but it is going to happen. For example the roll-over of the app.
Potential: This evolution is purely speculative. For example a customer wishing to investigate the risk related to two different architectural solutions.

Behavior

Controllable: The customer can decide whether the evolution takes place or not, for example he can reject a proposed change in the model.
Predictable: Evolution is independent from the designer but he can provide reliable estimates on whether certain changes will take place (this security requirement might be mandatory within 1 or 2 years).
Observable: Evolution cannot be predicted however all changes that take place can be observed, and the system can be notified about it. We might include analysis of adversarial behavior (e.g., trusted and untrusted actor).

Change Attitude

Plan: We analyze the possibilities in order to make decision on what to actually do in practice. For example studying the possible risks of a deployment and proposing countermeasures.
Do: We deploy solutions that tackle the change that the customer is facing. For example by running a system that controls the update of a new application of the customer. Or by implementing a traceability mechanism for requirements and models.
Check: We measure and evaluate the current changes. For example to see if our initial plans and estimates are actually met by the new system resulting from the evolution.
Act: We react to the change on the basis of our checks, possibly restarting the process if we are not happy.

Artefact delivered

Design: The artefact delivered by the SecureChange actor belongs to the design level such as a model of the system.
Deployment: The artefact is used off-line and can only affect the actual run-time behavior of the system under control from the point of roll-over. However the system already exists and cannot be changed by the secure change solution.
Execution: The artefact can modify the behavior of the system during execution, for example forbidding, enabling certain changes in the actual execution.

Using this taxonomy the various methods developed in the SecureChange project can be categorized in the following way.

This categorization helps us to position the different activities of the work packages, and give a clear picture about the relations of the developed methodologies.

Prof. Fabio Massacci, Università di Trento

Presentations of the first review meeting

BME — Tue, 06 Apr 2010 08:59:13 +0000

The first review meeting for SecureChange was organized in March in Brussels. The presentations of the meeting summarize the results of the first year of the project, and point out future directions for the coming years. The slides can be downloaded from the Presentations section of the website.

Description of Scenarios and their Requirements

BME — Wed, 17 Feb 2010 09:28:51 +0000

SecureChange investigates three different case studies from the following domains: home networks, smart cards, and air traffic management. The first project report delivered by the project's industrial partners summarizes selected scenarios from the case studies, and presents their requirements in detail.

Each case study follows the same schema for presenting its contents: a full description of the application domain, motivation scenarios, and involved technologies is provided first, followed by a section stressing the change and evolution related issues to the case study and finished with a compilation of requirements for the scenarios.

Programming model and annotations

BME — Tue, 16 Feb 2010 09:06:58 +0000

One of the objectives of the SecureChange project is the development of verification techniques for evolving systems, with a strong focus on the development time and run time phases of the software lifecycle. This includes the development of programming models that can ensure the absence of classes of vulnerabilities. A programming model consists of a set of programming guidelines designed to avoid a specific class of vulnerabilities. Source code annotations make the programming model explicit, and can support formal verification of compliance with the programming model.

Read on in the D6.1 Programming model and annotations report.

Documentation of forecasts of future evolvement in risk analysis

BME — Tue, 16 Feb 2010 09:02:48 +0000

A risk analysis typically focuses on a particular configuration of the target at a particular point in time, and is valid under the assumptions made in the analysis. However, both the risk analysis target and its environment can change and evolve over time. We therefore need methods and techniques to reflect such changes in the risk analysis. This deliverable is concerned with the development of modelling support for risk analysis of changing and evolving systems; in other words, language support for modelling a changing and evolving risk picture.

Read on in the D5.2 Documentation of forecasts of future evolvement report.

Methodology for Evolutionary Requirements

BME — Tue, 16 Feb 2010 08:50:36 +0000

As a software system evolves, security concerns need to be analyzed to re-evaluate the impact of changes on the system and the assumptions on environmental properties. Traditionally, the security requirements were handled in an ad-hoc way, while requirement models are often embedded in natural language descriptions which lead to inconsistent interpretations with respect to the meaning of the requirements. These made it difficult to analyze for requirements changes. By adopting a model-based engineering methodology, we propose to investigate such changes using a consistent conceptual model of evolving security requirements which incorporates the state-of-art requirement modeling languages such as Tropos and Problem Frames. To address the challenge of evolutionary security requirements, we lay out the conceptual meta-models, and the general methodology to handle changes on security requirements, including how to represent security requirements, how to model the changes of them, how to manage the changes and how to argue that the changes are fit for the purposes.

Read on in the D.3.2 Methodology for Evolutionary Requirements deliverable.