Results
| Publications |
|
Deliverable D2.1: Documentation of use cases, requirements and success factor indicators In the SecFutur project, a new security engineering process and security solutions in form of building blocks will be developed. In order to facilitate the identification of requirements on languages, tools and techniques for this purpose, and in order to evaluate the results of the project, three different use cases will be developed and implemented as show cases. This document contains the descriptions of these use cases, as well as a definition of success factors. The main purpose of the use case descriptions is to provide an input to the formal specification of the use cases, for which the abstract model for embedded systems being developed in work package 3 “Security building blocks” will be used. The purpose of the definition of success factors is to prepare the final evaluation of the project results.
In each use case description, the high level functionality of the system is presented, as well as a somewhat more elaborated description of the security aspects of the system. Since implementation depends on the results from work packages 3 “Security building blocks” and 4 “Security engineering process”, detailed functional requirements and detailed design are not covered in this document, but will instead be specified when optimal solutions are found, using the results from those work packages Deliverable D2.2: Feedback report and cross-cutting issues The task 2.5 “Providing evidence of improved embedded system development” in the SecFutur project of the work package 2 “Multiple sector use case development and show case” is important to proof that the developed tools and methods are usable and coherent to the global goals of this project. For this reason a preliminary evaluation were executed by all partners who participate in this task. This document contains the evaluation results from all participating SecFutur members. After the given answers from the project members there is a summarization of the results and their consequential conclusions, which will show how well the whole SecFutur process is performed and how well the developed tools and methods are adapted to the development of the show cases. The evaluation might reveal any cross-cutting issues in the current stage of the project. The evaluation results are tremendously depending on the output that the partners participating in the task 2.5 provide. For this reason a success factor chapter can be found in the deliverable D2.1 "Documentation of use cases, requirements and success factor indicators". It defines the evaluation criteria for the evaluation task and also contains examples answers for the evaluation questions. This will help the partners at some partial difficult questions defined in the evaluation criteria. This preliminary evaluation in this document is based on these criteria, but were expanded and modified, for the purpose that the evaluation could be performed by more project partners than only the show case developers. Most of the criteria questions were aimed at the show case developers and were answerable only roughly for the rest of the partners. Through the recent events, it would have meant that only two partners were able to fill out the evaluation. Since nearly all of the SecFutur members gain experiences with the developed tools and methods, it was reasonable to extend and alter the evaluation criteria to all participants in the evidence task 2.5. At the end of project the evaluation will be executed again to see the improvements that were made between these two evaluations. The final results of this second evaluation will be documented in deliverable D2.6 "Documentation on improved quality in embedded systems development" with more precise information to the adaptation of the developed tools and methods. Deliverable 3.1: Abstract model for embedded systems In this deliverable we describe the preliminary version of a model that has emerged as a result of detailed analysis of the case studies presented in WP2 (at the state available in month 6 of the project) and the knowledge from the forthcoming SecFutur engineering process (WP4) as conceived in month 9 of the project. The proposed abstract model is intended to be used for representing reusable security components, referred to as security building blocks, in systems built from embedded devices. It was formed after studying the UML-based approaches to domain specific languages and definition of profiles. In particular, the earlier OMG profiles for real-time and embedded systems (MARTE) and system modelling (SysML) were studied so that the WP3 abstract model fits well in the context of existing scientific work in embedded systems. More precisely, we have chosen to be compatible with MARTE and SysML when aspects that relate to resource-constraints are dealt with in our model. Abstract models of security building blocks have two essential roles: to be used in the process of developing the building blocks, and to represent an existing building block so that a system integrator is able to select and configure them for use in a system. In either case the model should be abstract enough to cover a range of applications in which the building block is appropriate for and detailed enough to enable selection via matching with the intended security requirements stated as specific properties. The abstract model consists of six elements organised into two main components: the Security System Interface (SSI) which defines the conceptual relation of the building block to the system into which it may integrate, and the Security Building Block (SBB) which defines what is needed to either implement or select a building block for integration into a system. The SSI can be seen as a "model interface" for the security building blocks to a system model and designed to play its part in the SecFutur process. It might also be used with existing UML models (e.g. using MARTE) as long as they are enhanced with security requirements. Four of the six elements in the model have been studied in more detail in terms of representation language, and preliminary format for their description is suggested. Two elements, namely required and provided properties, are expected to be fixed in terms of their representation language in the first half of year two of the project. All the six elements have been tried on the three case studies selected in WP2. A deeper study of aspects that relate to consistent use of one of the elements (namely assets to be protected) has been carried out. This has resulted in a detailed classification of data assets towards guidelines for their consistent use in future applications. Deliverable 4.1: SecFutur Development Process V1 and Modelling Framework This document describes the SecFutur engineering model process defined in WP4. This process aims to support the embedded systems developer in integrating the security building blocks into the overall engineering process. In particular, the process will provide means to identify and manage security properties and requirements. The document structure is as follows: first, we will describe the state of the art of the security in systems with embedded components, then we will justify the necessity of a dedicated SecFutur process in order to improve the treatment of security in this type of systems and finally we will present the goals SecFutur aims to achieve. Section 2 focuses in the current design approaches. More precisely, we summarize the state of the art in modeling languages for systems with embedded components; the current general design and modeling tools used; the state of the art in capturing security requirements for embedded systems and finally, the analysis of the weaknesses and strengths of the current approaches. This section acts as an introduction for the modeling languages and tools, in order to facilitate the descriptions and functionality of the next sections. Section 3 describes the SecFutur process. It begins justifying the use of the underlying formalisms (UML) as the base language and the concepts of metamodels as the core tool for developing our own modeling framework. Next, we show a general high-level view of the engineering process for SecFutur including all processes, from the analysis of use cases to the testing of the system of embedded components. Finally, we describe the complete SecFutur process from the specification of the general model to the specification of security properties and requirements and its implementation as building blocks. Section 4 presents and describes the SecFutur Modeling Framework. Here we introduce our four-layer model architecture with an in-depth description of each layer. We then describe the SecFutur UML life cycle, describing the whole process from the definition of domain-model specific metamodels to the use of them by the end-users in their systems. Additionally, we include an in-depth description of each element of the SecFutur Metamodel of Security Aspects and examples of Domain-Specific Metamodels. Finally,Section 5 presents the Deliverable conclusions and future work. In this section we describe the knowledge and experience we have obtained in the development of the SecFutur Model Process and Methodology and the next steps to achieve for the V2. Deliverable 5.1: Design of security evaluation framework This document is the first in the series of Work Package 5 deliverables in the SecFutur project. WP5 targets creating a security evaluation framework capable of performing testing on embedded systems in a semi-automated manner. Some background – i.e. pre-existing work in the consortium – is available, and therefore during the design we focus on creating a framework that can be integrated with, and make use of existing features of SEARCH-LAB’s Flinder software. As a first step we created a preliminary design of the security evaluation framework. This design takes into consideration all constraints that are practical to enforce at this point, while leaving the system as expansible as possible. After an introduction we describe the collected requirements and evaluate some options for architectural design. We only go into detailed design up to a level of detail which is enough for creating the prototype, an initial version that can already be evaluated on the case studies at the end of the second project phase. In upcoming deliverables an iteration of specification, design and implementation will be documented based on feedback from the case studies. The aim of this document is twofold. For one, we report the progress of work in WP5, but we also document to fellow project participants the state of design and prototyping of the evaluation framework. Thus, the targeted audience should have a basic understanding of the aims of SecFutur and embedded system security issues, but to this point no deep knowledge of embedded system design or of the other deliverables is assumed. Scientific publications: Laurent Delosières and Simin Nadjm-Tehrani. BATMAN Store-and-Forward: the Best of the Two Worlds. 2nd International Workshop on Pervasive Networks for Emergency Management, 2012,IEEE Jose Fran. Ruiz, Vasily Desnitsky, Rajesh Harjani, Antonio Mañna, Igor Kotenko and Andrey Chechulin. A Methodology for the Analysis and Modeling of Security Threats and Attacks for Systems of Embedded Components. 20th Euromicro International Conference on Parallel, Distributed, and Network-Based Processing, 2012, IEEE Antonio Maña and Gimena Pujol. Verification of Security Policy of Service Oriented Systems. 16th International Conference on Distributed Multimedia Systems, 2010
Andre Rein. Development and Evaluation of a Trusted Mobile Ad-hoc Network. Master's thesis, April 2012. Jose Fran. Ruiz, Vasily Desnitsky, Igor Kotenko, Antonio Maña and Andrey Chechulin. Design of telecommunication systems with embedded devices. 14th Conference "RusCrypto" on Cryptology, Steganography, Digital Signature and Security Systems, 2012 |

Publications