Project topics and materials
Get Complete Project Material File(s) Now! »
Security Requirement Engineering Methodology
The goal of this section is to define security requirement engineering methodology, describe typical security engineering development lifecycle, security classes used and produced security metadata (i.e. the knowledge produced by each security class) in each activity, their dependencies and interrelationships. Based on the discussions, we define a unified methodology for the use of ontological concepts in security requirement engineering process. More precisely, we aim at building SRE methodology that is guided not only by a process but also knowledge about the each activity within the process is also developed and shared among other activities. We start from defining security requirement engineering as an application context for ontologies, and proceed to defining a methodology that identified places in SREP where ontologies can contribute to improve current state of security requirement engineering. In this context, we take the view these state of the art approaches are primarily based on the same (small number of) artifacts. Our main intention is to identify the core artifacts of the security requirement and harmonize them together. In this context, we extracted the essence of the state of the art SRE models (cf. Literature review presented in Section 2.2), the core artifacts, and then aligned them semantically by defining ontology to construct a unified security requirement engineering model. The essential artifacts that we identify as common to SRE models are: goals, security attacks, system models (behavioral and structural), and use case oriented models. We order these artifacts under the form of security classes where each class is represented by ontology. We consequently have organized the structure of these security classes in such a way that the security metadata produced by these security classes, in different phases of SRE process, can be easily shared and reused among different activities of the process. For example, security goal related metadata could be used for identifying the system assets as well as this metadata could be used for analyzing the security attacks and vulnerabilities. Figure 2.7, resumes the ontologydriven security requirement engineering methodology.
Knowledge-Centric SRE Process
In this section, we first introduce the knowledge driven security requirement engineering process (SREP) whose focus seeks to identify SR from the early design phases of the system conceptualization. Instead of following the general approaches like waterfall style [20], we build our SREP on the definition of iterative an in cremental construction of the security requirement specification. Then, we define security ontologies for each security class used during the SREP. The SREP is articulated into seven activities, which are iteratively performed throughout the system conceptualization, although with different focus depending on where the iteration is situated within the system development lifecycle. These activities are as follow:
1. Agree on Definitions: The first activity in the SREP is to define and to agree upon a common set of security terms and definitions. It helps to build a common knowledge base for the experts (i.e., system engineer, risk experts, security experts, verification and testing teams, etc.) involved at different stages of system development life cycle. The introduction of, as well as the agreement on some general terms and principles of IT security within a given RE process has proven to be very beneficial for all system wide activities: analysis, design, implementation, and validation/testing [62]. We may use the security terms and definitions mainly defined in security standards (i.e., ISO/IEC 15408, ISO/IEC 17799:2005, or ISO/IEC 27002:2005, etc.) to build a common knowledge base in order to bridge a potential miscommunication gap across different SRE phases. Appendix A, presents how some of the security terms are generally defined and understood in this thesis.
2. Identify Security Goals: The purpose of this activity is for the stakeholders to formally agrees on a set of concise and abstract statements of the intended solution (goals) to the problem defined by the security problem definition [20]. More precisely, goal captures stable information (correct behavior) and provides means to distinguish between stable and unstable (malicious behavior
or anti-goals) information. Goals are usually identified by analyzing the key operational capabilities of the system specified by the stakeholders, determined from the security policy of the organization, or analyzing the problems and deficiencies in the system-as-is, as well as from legal requirements and other functional constraints [151, 25]. For example, the high-level goal « avoid updating firmware when vehicle is moving » is specified by having an interaction between the security requirements engineering team and the stakeholders. Once security goals are defined, they can be formally specified in the form of a goal document. Typically, this document corresponds to functional and nonfunctional aspects and range from high-level security goals to low-level ones [151, 150]. To facilitate efficient collaboration and coordination of goals with other SRE activities, we have defined the security goal ontology (cf. Section 2.4.2.1) in order to store, share, reuse, and manage goal knowledge base.
System Modeling Language – SysML
SysML, The Systems Modeling Language, specification is defined and promoted by the Object Management Group (OMG). The goal of the OMG is to provide a « standard modeling language, SysML, for systems engineering to analyze, specify, design, and verify complex systems quality, improve the ability to exchange systems engineering information amongst tools, and help bridge the semantic gap between systems, software, and other engineering disciplines » [107]. SysML aims at unifying the various types of modeling languages currently used in system engineering in a similar manner to how UML combined diverse modeling languages used in software engineering. SysML allows system engineers to model and follow system wide development concepts including system requirements, system behavior and system structure. SysML is often interpreted as being a new system engineering modeling language, but there have been several languages that have been used in the past such as block and internal block diagrams of UML are used to model the parametric constraints. In fact, SysML is based on UML and cannot be considered an entirely new language – more a large set of useful additions (extensions/modifications) to the existing core UML modeling concepts and diagrams. However, SysML, notably the object diagram, the deployment diagram, the component diagram, the communication diagram, the timing diagram, and the interaction overview diagram, does not require some diagrams of UML. In contrast, SysML includes some new diagrams and constructs not found in UML: the parametric diagram, the requirement diagram and flow ports, and the flow specifications and item flows. In addition, SysML also includes an allocation relationship to represent various types of allocation, including allocation of functions to components, logical to physical components, and software to hardware [107]. SysML classifies these different diagrams into four categories: behavior, structure, system requirements, and parametric relationships. These are known as the four pillars of SysML as illustrated in Figure 3.1.
Table of contents :
Acknowledgements
Abstract
Contents
List of Figures
List of Tables
List of Publications
1 Introduction
1.1 Context
1.2 Thesis Contributions and Outline
I A Knowledge-Centric Approach to Security Requirements En- gineering
2 Overview of Security Requirements Engineering Methodology
2.1 Introduction
2.2 The State of the Art SRE Approaches
2.2.1 Goal Oriented Approaches
2.2.2 Model Oriented Approaches
2.2.3 Problem Oriented Approaches
2.2.4 Process Oriented Approaches
2.2.5 Conclusion
2.3 The Role of Ontologies in RE
2.4 Security Requirement Engineering Methodology
2.4.1 Knowledge-Centric SRE Process
2.4.2 Security Ontologies
2.5 Conclusions
3 System Modeling Language for Security – SysMLSec
3.1 Introduction
3.2 System Modeling Language – SysML
3.3 SysML for Modeling Security Aspects
3.3.1 Structural Modeling
3.3.2 Behavior Modeling
3.3.3 Security Requirement Modeling
3.3.4 Attack Modeling
3.4 Integration of Ontology Reasoning on Security with SysML
3.4.1 Annotating SysML Diagrams with Ontological concepts
3.4.2 Reasoning with SysMLsec Models
3.5 Conclusions
II By Design Security Requirements Engineering
4 Running Example: The Firmware Flashing Process
4.1 Introduction
4.2 Firmware Flashing Use Case Specification
4.3 Security Goals
4.4 System Architecture Design
4.4.1 Behavioral Models
4.4.2 Structural Models
4.5 Conclusion
5 Security Analysis and Knowledge-Based Attack Trees
5.1 Introduction
5.2 Security Analysis Process
5.3 Attacks on the Firmware Flashing Process
5.4 Multilayer Security Analysis
5.5 Conclusions
6 Security Requirement Engineering
6.1 Introduction
6.2 Security Requirements Elicitation
6.2.1 Security Requirement Modeling
6.3 Security Requirements Refinement
6.3.1 What a SR Refinement is not
6.3.2 SR Refinement Process
6.4 Security Requirements Traceability
6.5 Where we Stand
6.6 Conclusions
III Security Requirements Enforcement
7 Constructing Security Specification of Cryptographic Protocol Design
7.1 Introduction
7.2 Ontology for Cryptographic Protocols
7.3 Firmware Flashing Cryptographic Protocol
7.3.1 Security Primitives
7.3.2 Assumptions and Constraints
7.3.3 Cryptographic Protocol Specification
7.4 The State of the Art: Firmware Update
7.5 Conclusion
8 Towards the Enforcement of Access Control Security Requirements
8.1 Introduction
8.2 Security Policy Enforcement Architecture
8.2.1 Policy Enforcement Points
8.2.2 Handling Policy Decisions
8.3 Security Policy Expression
8.4 Security Policy Configuration
8.5 Performance Analysis
8.5.1 Performance Analysis: Technical Approach
8.5.2 Experimental Setup and Results
8.5.3 The State of the Art: Automotive Access Control Architecture
8.6 Conclusion
9 Conclusions and Future Perspectives
Bibliography
