Méthodologie d’ingénierie des exigences de sécurité réseau

Méthodologie d’ingénierie des exigences de sécurité réseau

Evaluation of SRE Approaches 

This section describes the final step 3 of our SRE evaluation methodology. It concerns the evaluation of SRE approaches i.e., goal-oriented, agent-oriented and problem frames oriented with the help of the elicited evaluation criteria in step2. Our evaluation is a qualitative assessment that is performed in collaboration with the security experts at AIRBUS. This task has taken us to organize two meeting sessions (i.e., precisely 3 hrs brainstorming and discussions for each of the meeting) with a time gap of around 2 months. We performed the evaluation in two iterations. In the first iteration, we authors acted as stakeholders (i.e., SRE analysts) and tested the three SRE approaches i.e., STS, Secure KAOS and SEPP using an example scenario. In this regard, first, a description of the system-to-be is presented to three different persons (playing the roles of RE analysts) from our research group whose initial knowledge fits the aforementioned methodologies the best. Then, each one of them has been asked to elaborate the systemto-be using the methodology that the person is familiar with. During this process, the persons (acting SRE analysts) were not allowed to communicate with each other during the scenario analysis phase. Each of them has come up with a different list of security requirements for the system-to-be with respect to the. The resulting SRE models have been presented during a meeting that involved the security experts. Their feedback is recorded as our initial evaluation results, which enabled us to identify and select the SRE approach the found interesting to the experts at first instance. In the second iteration, the AIRBUS SRE experts are directly asked to test the SRE approach that found interesting to them during the first iteration. The feedback of this second iteration enabled us to finalize the evaluation results. In each iteration, a different use case scenario is employed in order to ensure the credibility of the capture of evaluation experience. In below we provide the details of the evaluation performed in two iterations. 

 Evaluation Iteration 1 – Use case Scenario 1 

We first present the use case scenario used in this iteration. The scenario concerns a task related to the aircraft maintenance process ensuring the compliance with safety regulations such as Airworthiness directives. The objective of this task is to anticipate the health of the on-board aircraft system by verifying specific parameters (e.g., fuel indicator) in order to ensure the readiness of the aircraft prior to taking the next trip. The Onboard aircraft system constitutes of two applications i.e., aircraft control application and monitoring application (see Figure 32). These two applications are connected to each other via an internal avionic bus network (represented as double arrow line in red colour in Figure 32). The aircraft control application captures the observed parameters from various sensors and indicators of the aircraft system, and transmits them to the monitoring application. Every time the aircraft has  landed, the responsible person (i.e., maintainer) must connect his/her laptop to the monitoring application in order to fetch the monitored parameters. However, there is no direct access to the monitoring application. The connection is permitted only in the secured network connection within the secured premises of the aircraft. The maintainer must carry the laptop to the airport ground in order to access the network. In this process, the maintainer is assumed to be trusted, while the laptop is assumed as untrusted.

Scenario implementation using Secure KAOS 

For the implementation, we used the KAOS tool known as Objectiver [Respect-IT]. The experimentation was conducted using the free trial version which was valid for three months (refers to the criterion R M2.1.2). Figure 33 depicts a sample goal model specified in our example scenario context (refer section 1.4.1.1 for the details on KAOS modelling notation). It required some effort to get acquainted with the tool and its terminology through the help of guidelines and cited references (refers to the criterion R M2.1.1 and R M2.1.3). In particular, the security experts expressed some concerns regarding the goal patterns based on formal temporal logic. KAOS drives RE analyst to define agents later in the RE process. As consequence, it does not help in expressing the relation between the agents and their interaction dependencies. For instance, while defining network agents (e.g., firewalls) in our scenario analysis, we encountered issues when we had to add a new device in the network. In this regard, a conceptual diagram of the network would have been more concise and clear. For example, it is not clear on how to express firewall configurations that restrict access to aircraft to only maintenance people? As consequence, we had difficulty in specifying network security requirements on network agents, particularly relative to security zoning (R M3.1). Furthermore, KAOS modelling perspective the abstractions is expressed using the four modelling activities (i.e., goal, responsibility, object /operation) (refer section 1.4.1.1). However, this abstraction perspective does not facilitate to explicitly differentiate goals/agents of the abstraction levels in network security engineering process (R M3.2). Otherwise, KAOS modelling notation provides good support to achieve traceability (R M4.1)