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).

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.

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).

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.

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 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.

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.

Read more in the D1.1 Description of Scenarios and their Requirements.

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.

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.