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.

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.

The SecureChange security engineering process is revolutionary in the respect that it is fully change driven. The view of existing security engineering processes as sequences of actions (e.g. risk analysis and requirements elicitation) performed on the whole system has been replaced by the view of change events causing change propagation and state changes in the security engineering artefacts. This change of paradigm provides for the first time a systematic way of handling changes based on dependencies between artefacts. Beyond that the SecureChange process incorporates concepts for the collaboration of different stakeholders in security engineering, ranging from the IT manager and requirements engineer to the security architect and system administrator. The goal of this collaborative approach is to support continuous security management and to achieve an adequate level of security at any time in the software lifecycle.

Read more in the D2.1 - An architectural blueprint and a software development process for security-critical lifelong systems deliverable.