H Abdo

J.-M Flaus

F Masse

Fuzzy semi-quantitative approach for probability evaluation using Bow-Tie analysis

The International Organization for Standardization (ISO) imposes the evaluation of the probability of accidents during risk analysis with the consideration of uncertainty. However, quantitative probability analysis can be too expensive and lead to unreliable estimation. This is due to imprecision and lack of data where unjustifiable assumptions should be added, while quantitative information is lost by using a qualitative probability analysis. This paper proposes a fuzzy semi-quantitative approach to address data uncertainties as an alternative for losing and adding information. A fuzzy-based approach is used for handling vagueness and imprecision in the input parameter frequencies. The application of this approach is demonstrated using the casestudy of a Toss of Containment Scenario (LOC) in a chemical facility.

INTRODUCTION

Probability analysis may be qualitative or quan titative depending on the circumstances [START_REF] Leitch | Iso 31000: 2009 the new international standard on risk management[END_REF]. Data for performing a probability analysis is either from historical incident data or expert elicitations (Abdo & Flaus ). Qualitative probabil ity analysis uses a scale of qualitative expressions (low, medium, high, etc.) to describe an event's probability or frequency. The advantage of the qualitative methodology is its simplicity of apply ing and understanding by the relevant personnel. Expert judgments represent an important source of data to apply this methodology which are sub jective (verbal expression) in nature. This subjec tivity represents a disadvantage when quantitative or more precise information is available. However, the quantitative approach uses a numerical scale with real values to describe the event frequencies. A disadvantage of the quantitative approach is that the imprecision and lack of such data can affect the quality of the analysis [START_REF] Abdo | A mixed fuzzy probabilis tic approach for risk assessment of dynamic systems[END_REF]. The quantitative methodology is too expen sive and complex to be performed in terms of time and cost since statistical and empirical data are needed. It can lead to probability underestima tion if uncertainty is not taken into consideration (Abdo & Flaus 2016). For these disadvantages, a semi-quantitative approach represents a better alternative based on the available information.

INERIS (the French National Institute for Industrial Environment and Risks) has developed an interval semi-quantitative Bow-Tie analysis to quantify the probability of risk based on the available information [START_REF] Dianous | Prise en compte de la probabilité dans les études de dangers[END_REF]. This approach is mainly based onthe INERIS expertise and the results of the European project ARAMIS [START_REF] Hourtolou | Aramis project: devel opment of an integrated accidental risk assessment methology for industries in the framework of seveso ii directive[END_REF]; [START_REF] Hourtolou | Aramis project: Achieve ment of the integrated methodology and discussion about its usability from the case studies carried out on real test seveso ii sites[END_REF]). It uses historical accident data or expert elicita tions if the former is not available. It is easy to use, effective and implicitly takes uncertainty into consideration.

This study highlights the limits presented in the interval semi-quantitative approach at first. Then it handles these limits by introducing the concept of fuzzy numbers instead of intervals. Fuzzy num bers are used to represent subjectivity in expert judgments and consider the quantitative data if it exists. The rest of this section provides an intro duction to Bow-Tie analysis and the interval semiquantitative approach as a preface to the proposed approach.

Bow-Tie analysis

Bow-Tie analysis is a very prominent method to identify and analyze the probability of risk [START_REF] Ferdous | Handling and updating uncertain information in bow-tie analysis[END_REF]. It presents a combination between Fault Tree Analy sis (FTA) and Event Tree Analysis (ETA). FTA and ETA respectively describe the relationship between the undesirable event, its causes and its consequences for a systematic representation of hazard ( [START_REF] Sadiq | Predict ing risk of water quality failures in distribution net works under uncertainties using fault-tree analysis[END_REF]; [START_REF] Ferdous | Handling data uncertainties in event tree anal ysis[END_REF]). Figure 1 presents a schematic diagram of the Bow-Tie analysis, the definition of each term is detailed in Table 1.

Evaluating probability of an accident using Bow-Tie analysis is performed by: (i) characteriz ing input data, (ii) propagating these characteriza tions through the Bow-Tie analysis. Characterizing (RISK FACTORS;______________________________ _____________________________ RISK IMPACTS input data aims to qualitatively, quantitatively or semi-quantitatively represent the information pro vided either by experts or derived from historical data with the consideration of uncertainty. Propa gating the characterizations through the Bow-Tie aims to calculate the probability of ERC, PhDs and AMs. This is done by solving the AND and OR gates, considering the existence of risk barri ers and the occurrence of secondary events. The next section presents a brief details on the semiquantitative approach used by INERIS to perform a probability analysis. Before starting, it should be noted that there is a difference between probability and frequency. But in a simplified manner, these two notions of probability and frequency coincide when frequen cies are low (less than 1 time every 10 years). The semi-quantitative scale used by INERIS to char acterize the frequency of basic events is presented in Table 2. A class of frequency in terms of an interval is given to each basic event as input. This class is derived from experts, or by translating the quantitative data into a class (e.g. an event with a frequency equals 4 x 10 4 is of class F3). This trans lation is performed based on Equation 1 below:

Class(f) = -E n t(io g if)) -1 . ( 1
)
where, Ent is the integer part, log is the logarithm base 10 a n d /is the frequency value of the event.

The propagation rules are defined and detailed in (INERIS 2015), and will be presented with addi tions to suit the fuzzy approach in section 3.4.

The second part of the paper highlights the limi tations in the interval semi-quantitative approach. The third part examines the proposed methodolo gies to deal with the limitations of this approach. Section four presents a case study and compares the fuzzy with the interval semi-quantitative approach and the traditional quantitative approach. Finally, a number of conclusions are drawn in Section 5.

Damages caused by

the effects of an PhD on people, We shall now introduce the limitations presented in the interval semi-quantitative approach and dis cuss the methodology behind the proposed solu tion. These limitations are presented by converting the statistical data into classes:

• The discreteness of the frequency classes makes the conditions on the border between two inter vals not well defined. Vagueness on the extent of half the range of the interval to which category it belongs is presented. The same class is given to different frequencies even if the difference between them is too remarkable (see Figure 2(a), the same class F -1 is given to events El and E2 where their frequencies are 11 and 99 per year respectively); Figure 2(c) shows an example of an OR gate with two input events E ll and EI2. The occur rence frequencies of the both input events are equal to 9 times/year. Suppose we have an error factor due to the lack of information or a meas urement error, and the frequencies can be higher by a factor of 2 times/year (e.g. 11 times/year). This deviation changes the class of events El and E2 from F -l to F -2 . The output of the OR gate is affected by this error where its class is changed. Thus, a small deviation can lead to a great change in the output.

However, a fuzzy-based approach is proposed in order to address the issues highlighted in this section. x -a a<x<b In this section, we present the added improvements on the INERIS approach. The characterization of input data in terms of fuzzy numbers and the propagation rules to calculate the occurrence prob abilities of ERC and outcomes are discussed in the rest of this section. ( 3)

O = deviation F -l i : ^ • o E ll W ith o u t d e v ia tio n F -1 r -L ; F -2 i ; F -l | -) o r )-- E 0 El F -l ! F ~2 \ Frequency --------------------- E | 2 W ith d e v ia
Fuzzy set was introduced by the pioneer Zadeh in 1965 as a tool to characterize imprecise variables as well as to represent experts' knowledge in a mathematical tool [START_REF] Zadeh | Fuzzy sets[END_REF]. Fuzzy variable is associated with a possibility distribution or mem bership function in the same manner as random variable is associated with a probability distribu tion. Consider a fuzzy subset F of the universal set X, thus the membership function is //, : X -

> [0,1].
Where, for a given x e X , the membership degree //rY(x) represents the degree of compatibility of the value x with the concept expressed by F. Trian gular fuzzy number is the most popular which can be expressed as a triplet [a , h, c], see (Abdo & Flaus 2016) for more details.

Define event frequency using fiz z y numbers

Fuzzy numbers are used to express the linguis tic frequencies as shown in Figure 3. Since the frequency classes follow a logarithmic scale, the grades FX, J e N are not triangular fuzzy num bers. FX is divided in three parts (see Figure 4) and derived with its membership function using Equa tions 2 and 3, respectively.

F X = [a,b,c,d,e] = l 0 -( X +2 ) + 1 0 -( X +l)
10-(V + 1); lO-U'+D + lO--;io-10-* + 10-'

(2) Each value on this scale has its own possibility degrees to which classes it belongs. In the next sec tion, we will define how to represent each type of input data based on the fuzzy semi-quantitative approach.

Representation (fuzzification) o f input data

Statistical accident data and expert elicitations are both used in this approach. Thus, precise values and verbal expressions represent the input of the analysis. These inputs are fuzzified and represented as follows:

• The crisp or precise values derived from statisti cal data are mapped on the universe of discourse. This fuzzification process gives two membership degrees to each crisp value. Figure 3 shows an example of event A that belongs to classes F3 and F2 with membership degrees equal 0.6 and 0.4 respectively. It should be noted that uncer tainties attached to statistical values are consid ered to be covered by the fuzzy classes. • Experts are asked to give a verbal expression in terms of a frequency class to such an event if statistical data is not provided. This class is taken to be the input for the event.

Propagating fuzzy frequencies through the Bow-Tie

This section aims to set the fuzzy rules for propa gating the input frequencies through the Bow-Tie analysis. Propagating inputs is achieved by solv ing the gates between the events, and aggregating the frequencies of risk barriers and the secondary events. The Fuzzy semi-quantitative rules are pre sented as follows:

• Treatment of OR and AND gates (section 3.4.1 and 3.4.2 respectively); • Treatment of secondary events (section 3.4.3); • Treatment of security barriers (section 3.4.4).

Treatment o f OR gate

OR gate signifies that the output event occurs if either of the input events has occurred. Figure 5(a) The output event E occurs after the occurrence of A or B. Based on the fuzzy approach, each one of A and B may be attached to one or two frequency classes depending on the type of input data (expert or statistical data). The frequency of the OR gate is calculated using the Cartesian product where the Class and the possibility degreeof the table cases are calculated based on the two equations below:

Class(E) = min[Class(EIl ), CAass(EL )] (4) Degree(Class(E)) = Degree(min[Class( E f ), Class(EI2 )]) (5)
For example, let A and B belong to [F3, F2] and [F4, F3] with possibility degrees equal [0.4, 0.6] and [0.5, 0.5] respectively. The Cartesian product for the output is presented in Table 5(b). The out put frequency is [F3, F2] with possibility degrees of [0.5, 0.6],

Treatment o f AND gate

AND gate signifies that the output event E occurs if the input events occur simultaneously. The classes and membership degrees of the output event are determined based on Eq. 6 and Eq. 7 respectively. An example is presented in Figure 8(a). 6)

Class(E) = max[CIass( E f ), Class( EE )] (
Degree(Class(E)) = Degree(max[Class(Ef ), Class(EI2 )]) (7)
It should be noted that, if the same class Fj has different possibility degrees, then the maximum degree between them is selected for the Fr As it is the case for class F3 in the example, where 0.6 is taken as the output possibility degree.

Treatment o f secondary events

PhDl occurs if ERC occurs and ES occurs con ditionally after ERC. PhD2 occurs after the occurrence of ERC and no occurrence of ES. The input data here are the frequency classes of the ERC and conditional probability of ES (noted p ). Output frequencies and degrees are calculated using the equations below:

Class(PhDV) = max[Class(ERC) - Ent(log( 1 -p )-0.5)];see (INERIS 2015) W Degree(Class(PhD\)) = Degree([Class(ERC)]) (9)
Class(PhDl) = max[Class(ERC) -Ent(log{p) -0.5)] ( 10)

Degree(Class(PhD2)) = Degree{[Class{ER C )] ) ( 11)
Figure 7 presents an example.

Treatment o f safety barriers

A security barrier operates after the occur rence of the event that this barrier is attached to. The output event E occurs if the input event El occurs and the attached security barrier does not operate. In the other case (if the security barriers operate), another event E may occur.

The data needed for the treatment are the fuzzy frequencies of the event El and the confidence level of the security barrier. The fuzzy classes of the output events E and E are calculated using the equations below:

Class(E ) = Class(EI) + NC = F(x + NC); (INERIS 2015) (\T )
where x is the class of EL

Degree(Class(E)) = Degree([Class( E l )]) (13)
Class(E) = Class(EI) ( 14) HANDLES THE EXISTED LIMITS However, Figure 9 presents how the proposed methodology deals with the limitations presented in the interval semi-quantitative approach. For the discreteness issue, now the events El and E2 are now belong to different classes with different degrees (see Figure 9(a)). Figure 9(b) presents how the fuzzy approach solves the probability underes timation problem. Finally, A deviation due to error in the determination of input frequencies will not affect the result nor the decision. The same example taken in Section 2 is depicted in Figure 10. A small change in the possibility degrees is generated due to the deviation where the classes are the same.

Degree( Class{ E)) = Degree([Class( El)]) (15) 0.1 ES 0.4 in F2 0.6 in F3 ERC P h D l 0.4 in F3 0.6 in F4 NO PhD2 0.4 in F2 0.6 in F3
Here the effectiveness of fuzzy theory in handling uncertainty lies in. This methodology will be illustrated in the next section and applied to a loss of containment scenario.

ILLUSTRATION OF THE PROPOSED APPROACH

In this section, a Bow-Tie analysis for a LOC scenario is utilized to prove the utility and effec tiveness of the proposed methodology, shown in Figure 11. The proposed methodology is applied (b) Conservative estimation of output proba bilities In addition to the proposed approach, quanti tative and interval semi-quantitative analyses were also performed for the Bow-Tie of LOC scenario. In order to compare these approaches, the outputs are presented in Table 3. The output frequencies of the quantitative approach are translated into classes for comparison purposes. The quantita tive approach is the most precise but it does not consider uncertainty in the analysis. As there is no consideration of uncertainty, this may lead to risk underestimation in some cases. However, the fuzzy approach presents more accuracy than the interval approach where the output fuzzy classes cover the class obtained using the quantitative approach. Fuzzy approach is more conservative than the quantitative approach as uncertainty is considered (fuzzy numbers are used instead of crisp values). Again the exact result from the quan titative approach lies within the result obtained by the proposed approach, which makes the later more conservative. 6 CONCLUSION Probability analysis of dangerous phenomena has become a necessary step in risk analysis. Qualita tive or quantitative probability analysis can be per formed depending on the type of data available. This data is derived from different sources (his torical accident data or expert judgments in terms of numerical values or linguistic variables, respec tively). Quantitative information for a quantitative analysis is not always provided. Qualitative analysis is subjective and may lead to loss of quantitative information if it exists. In addition, the accuracy of the analysis based on these approaches still a major issue since uncertainty is not taken into consideration.

That is why this paper proposes a fuzzy-semi quantitative approach relying on the available information from historical data or experts if the former is not available. Fuzzy theory is introduced to handle uncertainty due to imprecision and vagueness in defining the frequency scale. Fuzzy rules are set to propagate the fuzzy input classes through the Bow-Tie analysis. BT analysis is used to model a risk scenario as it gives an exhaus tive visual summary of risk by displaying the risk events and the control measures and as a tool for likelihood evaluation.

This methodology is applied to a Bow-Tie case study for a LOC scenario. A comparison with the quantitative and the interval semi-quantitative approaches is discussed. The results show that the proposed methodology provides more simplicity and accuracy in the quantification, in addition to the consideration of uncertainty.

In the future, this work will be extended by using multiple sources of data in probability analysis. Different data bases or experts may provide dif ferent probabilities regarding the same parameter. Thus, rating and aggregating the data from differ ent sources will lead to a more robust probability quantification approach for Bow-Tie analysis.

Figure 1 .

 1 Figure 1. Elements of a "Bow-Tie" diagram.

  n t it a t iv e a p p r o a c h ^ Class F 0 (b) Deviation due to imprecision

Figure 2 .

 2 Figure 2. Limitations presented in the traditional semi-quantitative approach.

Figure 3 .

 3 Figure 3. Mapping event frequencies on fuzzy scale.

Figure 4 .Figure

 4 Figure 4. Fuzzy frequency class FX.

  Figure 7. Consideration of a ES within the fuzzy semi quantitative approach.

Figure 9 .Figure 11 .

 911 Figure 9. How the fuzzy semi-quantitative approach deals with the limitations mentioned in Section 2.

Table 1 .

 1 Abbreviations, significations and definitions of elements listed in the Bow-Tie diagram.

			1.2 Interval semi-quantitative approach
	Abbreviation Signification	Definition
	El	Basic event	Direct cause of a loss
			of containment or
			physical integrity
		Event	Physical integrity
			caused by the
			occurrence basic
			events
	ERC	Undesirable	The unwanted event
		event	such as a loss of
			containment, etc.
	ES	Secondary	Characterize the
		event	source term of an
			accident, such as
			ignition
	PhD	Dangerous	Physical phenomena
		phenomenon	that can cause
			major accidents,
			explosion,
			dispersion, fire
	AM	Major
		accident
		Risk barrier
	AND, OR gates

Table 2 .

 2 Determining the frequency classes based on the semi-quantitative approach.

	environment or goods Measures taken place to reduce the probability of undesirable event and the effects of	F-2 F-l FO	10*l/year < frequency < 10+2/y ear 10°iyear < frequency < 10 + 1/year 10~'iyear < frequency < 10 °/year	10 to 100 times/year 1 to 10 times/year 1 time every 1 to 10 years
	accidents	FI	10~2/year < frequency	1 time every 10 to
	Describe the		< \Çrliyear	100 years
	relationships	FX	10"| Y +1)/year < frequency
	between events		< \Q xiyear

Table 3 .

 3 Estimated results obtained using quantitative, interval semi-quantitative and fuzzy semi quantitative approaches.

			Interval semi-	Fuzzy semi
		Quantitative	quantitative	quantitative
	Outcomes	approach	approach	approach
	Spreading 2.1 x 10 ' : F2 F3	1.0 in F3
	solvents			0.55 in F2
	in a large
	quantity
	Explosion 2.1 x 10-4 : F3 F4	1.0 in F4
	UVCE			0.55 in F3
	Formation 2.1 x 10 ! : F2 F3	1.0 in F3
	of toxic			0.55 in F2
	gas
	Pool fire	2.1 x 10-4 : F3 F4	1.0 in F4
				0.55 in F3

ACKNOWLEDGMENTS

This work is based on research supported and funded by the French National Institute for Indus trial Environment and Risks (INERIS).


H A Bdo

M K Aouk

J.-M Flaus

F M Asse

Towards a better industrial risk analysis: A new approach that combines cyber security within safety

The introduction of digital technology in industries creates new security threats that can lead to undesirable safety accidents. Thus, analyzing these threats during safety analysis becomes an important part for effective risk evaluation. However, nowadays, safety and security are assessed sepa rately where they should not be. This is because a security threat can lead to the same dangerous phe nomena as a safety accidental cause. In this paper, a new method that considers safety and security for probability evaluation during industrial risk analysis is proposed. This approach combines Bow-Tie Anal ysis (BTA), commonly used for safety analysis and the Attack Tree Analysis (ATA), recently introduced for security analysis of computer control systems.The combined use of BT and AT provides an exhaustive qualitative investigation of security and safety scenarios, and a qualitative evaluation of the likelihood of these scenarios. The definition of BT and AT combined, and the mathematical formulas for likelihood quantification are presented. The application of this approach is demonstrated using the case study of a risk scenario in a chemical facility.

INTRODUCTION

Analyzing risks of industrial and complex systems such as those found in nuclear plants, chemical fac tories, etc., is of crucial importance given the haz ards linked to these systems (explosion, dispersion, etc.) (Abdo & Flaus 2016). Quantifying andanalyzing these risks contributes to better decision making and ensures that risks are presented according to defined acceptance criteria [START_REF] Arunraj | Risk-based maintenancetechniques and applications[END_REF]. A systematic safety risk analysis process is made up of three steps: (i) identification of risk scenarios, (ii) likelihood analysis and (iii) effect analysis ( [START_REF] Purdy | Iso 31000: 2009setting a new standard for risk management[END_REF]; [START_REF] Kaplan | On the quantitative definition of risk[END_REF]). Based on these steps, a level of risk will be given to each scenario to see if it is acceptable or not. If not, safety meas ures should be added to reduce the level of risk to an acceptable level by diminishing the likelihood or the effects. This work considers the first two steps. Identifying a risk scenario aims to explore how an undesirable hazard can be developed starting from causes and ending with the consequences. Likeli hood analysis aims to estimate the likelihood of risk scenarios. This estimate can be qualitative or quantitative depending on the available data.

However, traditional industries were based on mechanical devices and closed systems [START_REF] Kriaa | A survey of approaches combining safety and security for industrial control systems[END_REF].

Today, industries are influenced by the develop ment of digital technology related to instrumen tation and control systems (SCADA: Supervisory Control And Data Acquisition). The shift from analog equipment towards technologies has a number of benefits concerning production, but it also presents challenges [START_REF] Shin | Cyber security risk evaluation of a nuclear i&c system using bayesian networks and event trees[END_REF]. This introduction of technology increases the degree of complexity and communication amongsystems. The use of internet for remote controlling and supervising systems and facilities has gener ated a new type of risk related to security. These systems and facilities have became more vulner able to external cyber attacks. These new security threats can affect the safety of systems and their surrounding environments in terms of people, property, etc. ( [START_REF] Johnson | Cybersafety: on the interactions between cybersecurity and the software engineering of safety-critical systems[END_REF]; [START_REF] Kornecki | Safety and secu rity in industrial control[END_REF]).

The differences and similarities between safety and security are studied by many authors ( [START_REF] Kriaa | A survey of approaches combining safety and security for industrial control systems[END_REF]; [START_REF] Firesmith | Common concepts underlying safety security and survivability engineer ing[END_REF]). In general, safety is associated with accidental risks caused by component fail ures, human errors or any non-deliberate source of hazard, while security is related to deliberate mali cious risks originating from attacks, which can be accomplished physically or by cyber means. In this study, physical attacks are excluded.

Until today, safety risk analysis does not take into consideration the security related risks that can affect the safety of the system. In recent years, there has been an increase number of cyber attacks that targeted critical facilities (e.g., Stuxnet in2010 and Flame in 2012). According to Dells annual threat report [START_REF] Dell | Dell Security Annual Threat Report[END_REF], cyber attacks against SCADA systems doubled in 2014. Dell SonicWALL saw global SCADA attacks increase against its customer base from 91,676 in Janu ary 2012 to 163,228 in January 2013, and 675,186 in January 2014. Many authors have studied the potential impact of security related threats on the safety of critical facilities [START_REF] Kornecki | Safety and secu rity in industrial control[END_REF] . Thus, concerns about approaches for risk analysis that considers safety andsecurity together are a primary need.

In this study, we propose a methodology that combines BT and AT for an exhaustive likelihood evaluation (see Figure 1). It aims to examine cyber security attacks during likelihood analysis process. BT analysis is one of the most popular methodolo gies used in probabilistic safety assessment (Abdo & Flaus). AT is widely used to represent and analyze risk scenarios related to cyber security. However, combining BT and AT analyses can be effectively used for an integrated safety/security assessment of complex systems. This methodology identifies and considers all safety and security threats that can lead to the same undesirable phenomenon. The likeli hood of a security related risk is analyzed based on the same process used in safety risk analysis (27005 2011) . The proposed approach will provide a deep, exhaustive analysis on safety and security for a spe cific risk scenario in a given facility.

In this proposed approach, different likelihood scales, one for safety and another for security are defined to characterize the likelihood of input events. This differentiation helps in identifying the sequences of events (minimal cut sets) that are purely related to safety, security or to both. The resulting output of different types of cut sets offers richer information for decision making. In the rest of this paper we are going to prove that purely security risk sequences should be treated firstly.

The second part of this paper introduces the concept of BT and AT analyses, and the mathe matical rules to perform a likelihood analysis using these approaches. The third part presents how BT and AT can be used together for a safety/security analysis. Section four presents a case study where the proposed approach is applied for a hazard scenario in a chemical facility. Finally, section five draws a number of conclusions.

PRELIMINARY

In this section, we introduce the concepts of SCADA system, BT and AT analyses. Section 2.1 presents the role and architecture of the SCADA system. Steps and structures to analyze risks using BT and AT are highlighted in Sections 2.2 and 2.3, respectively.

SCADA: Supervisory Control & Data Acquisitions

SCADA system refers to an industrial compu ter system that monitors and controls a process. The principal function of SCADA is acquiring the data from devices such as valves, pumps, etc. and providing control of all these devices using a host software platform (Schneider Electric 2012).

The system monitoring is provided using a remote method of capturing data and alarm events, where instruments can be regulated and turned on and off at the right time. SCADA system also provides more functions such as graphical display, alarm ing, tending and historical storage of data.

Figure 2 presents the structure of a SCADA system. There are four distinct levels within the SCADA system structure. These levels are pre sented as follows:

• Field instruments: refers to sensors, pumps, actuators, etc. that are directly connected to the plant or equipment. They generate the data that will be used by the other levels to supervise and control the process; • PLC (Programmable Logic Controller): PLC is an adapted industrial digital computer that controls the manufacturing processes. It is linked to the field instruments, and to the SCADA host software using a communication network; • Communication network: the link that relays data from PLCs to the SCADA host software and the filed instruments; • SCADA host software: provides graphical dis plays in order to monitor, maintain and engineer processes and SCADA elements;

Bow-Tie analysis

Bow-Tie analysis is a very prominent method to identify and analyze the likelihood of risk (Ferdous, Khan, Sadiq, Amyotte, & Veitch 2012). It presents a combination between fault tree analy sis (FTA) and event tree analysis (ETA). FTA and ETA respectively describe the relationships between the undesirable event, its causes and its consequences for a systematic representation of hazard. These relationships between trees' nodes are represented using the logical AND/OR gates. BT uses different types of nodes to model a risk scenario. The definition of each is detailed in Table 1. Likelihood evaluation using BT is based on two main steps: (i) determining likelihood of occur rences of input events (BEs and SEs) and the like lihood of failures of risk barriers, (ii) propagating the likelihood through the BT in order to calculate the likelihood of outcomes. These two steps will be detailed in Section 3.

S h a p e S i g n i f i c a t i o n D e f i n i t i o n

Attack Tree

Attack tree is a graph that describes the sequence of steps in order to perform an attack [START_REF] Fovino | Integrat ing cyber attacks within fault trees[END_REF]. It represents an attack against a system in a tree structure. The root (top event) of the tree is the goal of an attack. This root is connected to intermediate and starting events (leaf nodes) in order to represent the different ways to achieve the attack (Schneier 1998).

In this study, we will adopt the extended ver sion of attack tree proposed by [START_REF] Fovino | Through the descrip tion of attacks: A multidimensional view[END_REF], but with modifications where the concept of the intermediate event is added. This intermedi ate event aims to differentiate between the input events and the event generated by these inputs. This extended version allows the consideration of significant information such as attacker resources, motivations, etc. As in BT, different types of events and AND/OR gates are used to model an attack scenario. The term, shape and definition of each event are presented in Table 2.

An Operation node can have an input that presents a special structure regarding the other input events. However, for likelihood treatment, the Operation event and its input will be treated as an AND gate. The treatment of AND/OR gate will be presented in Section 3.

METHODOLOGY

In this section we present how ATs can be inte grated within BTA for richer representations and precise evaluations of risks (see Section 3.1). Then, the different steps for conducting a qualita tive likelihood evaluation will be presented. This evaluation is made up of three main steps: (i) determining the minimal cut sets, (ii) character izing input data and (iii) propagating input data as highlighted in Sections 3.2, 3.3 and 3.4 respec tively. Figure 3 shows the framework to apply the proposed approach.

Combining ATs with B T

Integrating ATs within BT analysis can help in understanding how attackers can take advantage of controlling systems' components in order to cause damages. This combination aims to enrich the analysis by considering security risks modeled by attack trees that can lead to the same safety events modeled using BT. The top event of an AT tree coincides with an event contained in the BT. This means that an event in BT can occur due to accidental (safety) or deliberate (security) sequence of events.

Determining minimal cut sets

Finding out the minimal cut sets represents the first step of likelihood evaluation in our approach. A MC is the smallest combination of input events which causes the occurrence of the undesirable event. Determining the MCs is very useful to dis cover the weak point in our system and the differ ent ways in which the top event can occur. In this study, the MCs are obtained using rules of boolean algebra [START_REF] Yuanhui | Safety system engineering[END_REF].

This step aims to separate between three types of minimal cuts:

• purely related to security: all events of the MC are due to deliberate attacks;

• purely related to safety: the MC does not con tain any security related event; • related to a mixture of both security and safety: accidental and deliberate causes exist in the MC.

The importance of this differentiation between types of MCs is to discover the system's weak nesses where a pure security MC represents a weak point due to the high likelihood of occurrence of security causes. This reasoning will be detailed and demonstrated in the rest of this paper.

Characterizing likelihoods o f input events

Likelihood analysis can be qualitative or quantita tive depending on the type of available data. This data is either quantitative derived from historical incident or qualitative based on experts' elicitations. Because of the difficulties in estimating quantita tive likelihood of occurrence of an attack or an accidental cause, a qualitative scale is used. The advantage of the qualitative methodology is its sim plicity of applying and understanding by the rel evant personnel. Two different scales L" : security and Lf : safety of respectively five and six levels are proposed. The first level of each scale represents an undefined value (likelihood equals null) in order to specify if an event is purely related to safety or security. Thus, each input event is characterized by couples (Ls,Lf ). Based on this likelihood represen tation in terms of couples, we can differ between three different types of events presented as follows:

• events (basic events) related to safety with likeli hood (0,Lf) for each event; • events (basic events) related to cyber-security with likelihood (Ls,N S ) for each event; • events (intermediate events) related to both safety and security with likelihood (Ls,Lf ) for each event.

Tables 3 and4 present the scales proposed for safety and security respectively. The same scale used by INERIS for safety analysis is used in this study [START_REF] Ineris | Agrégation semi-quantitative des probabilits dans les études de dangers des installations classées -omega probabilit[END_REF]. Different criteria are used to determine the likelihood of the cause of an attack (assertions, operations, vulnerabilities) based on the proposed scale (see (ANSSI 2014) for more details). These criteria are presented as follow: Strong: is almost certain to occur, system is an easy target

Propagating input frequencies through AT-BT combined

The propagation process aims to calculate the frequencies of the undesirable central event and its consequences. Propagating input frequencies through the AT-BT is achieved by setting the rules to solve the logical gates. Since qualitative scales are used for safety and security frequency charac terization, the min-max rules are used to solve the gates [START_REF] Ineris | Agrégation semi-quantitative des probabilits dans les études de dangers des installations classées -omega probabilit[END_REF]. The output frequencies for OR/AND gates with n input events (El,...,En) are determined based on Eqs 1/2 respectively.

F(ORout) = max[F(E\),...,F(En)\ (1) F(ANDout) = min(F(E\),...,F(En)\ (2)
This approach will be illustrated in the next sec tion and applied on an over-pressure scenario in a chemical reactor.

CASE STUDY

This case study illustrates the implementation of the proposed approach, which can be applied in any industrial context. The case study concerns an industrial site of a propylene oxide polymerisation reactor [START_REF] Abdo | A mixed fuzzy probabilis tic approach for risk assessment of dynamic systems[END_REF]. The reactor runs a high exothermic chemical reaction at high pressure. Risks associated with the operation of the reactor are of high consequence. In a systematic represen tation of the reactor, a production system, a cool ing system and a power supply are interacting in order to perform the operation under normal con ditions (regulated temperature and pressure). Com ponents of these systems (valves, pumps, etc.) are controlled by PLCs and supervised by a SCADA system. The information collected by the SCADA system is accessible by all the site managers from their offices using wireless remote control. The manager of the utility can control the facility using its tablet or smart phone via internet. Controlling the process via internet would allow the manager to handle the situation from where he/she is before it is too late, rather than waking up at midnight racing to the plant to handle the situation. Figure 4 shows the architecture of the system under study.

In this case, the most likely undesirable scenario with the highest consequences due to overheating/ over-pressure is considered. This scenario is derived from an abnormal response of the cooling system after deliberate or accidental errors. The differ ent steps of the proposed approach are applied to identify causes, consequences and the occur rence likelihood of this scenario. 5 presents the identified MCs with their estimated likelihoods.

As shown in Table 5, the MCs ranked high (FI) are purely due to cybersecurity. This reveals the importance of considering security risks during safety risk analysis. However, the presence of a safety event in an MC will lead to less likelihood of occurrence. We can clearly see that between MC-1 and MC-16 where their attached likelihoods are equal to H and L respectively, MC-16 is of less like lihood because it contains the accidental event BE9.

For more details, a burst disk is added which represents a mechanical component (no security breaches are related). This burst disk will open for pressure relief in the event of excessive pres sure build-up. The re-determining of MCs shows that there is noMC that is related to pure security. A-l, V-l, 0-1, V-4, V-5

(3 , NS) H

16

A-l, V-l, 0-1, BE9

(3 ,D ) L

2

A-2, V-4, V-5

(1/NS) L

17

A-2, BE9

(1 ,D ) L

3

A-3, 0-2, V-4, V-5

(3 , NS) H

18

A-3, 0-2, BE9

(4 ,D ) L

4

V-2, V-3, V-4, V-5

(1/NS) L

19

V-2, V-3, BE9

( C D ) L

5

A-4, V-4, V-5

(3 , NS) H

20

A-4, BE9

(3 ,D ) L

6

A-5, A-6, 0-3, V-4, V-5

(2 , NS) M

21

A-5, A-6, 0-3, BE9

(2 ,D ) L

7

A-7, V-4, V-5

(2 , NS) M

22

A-7, BE9

(2 ,D ) L 8 0-4, V-4, V-5 Table 6 shows the re-determined MCs with their re-estimated likelihoods. The introduced improve ment diminishes the likelihoods into the lowest level. Thus, the presence of a mechanical failure (safety event) in a cut set will insure the prevention of malicious attacks. For these reason, safety and security being treated together will lead to a better risk analysis and effective decision making.

(3 , NS) H 23 0-4, BE9 (3 ,
A-l, V-l, 0-1, V-4, V-5, BE10 (3 ,

CONCLUSION

The use of technology in critical facilities exposes systems' safety to security related threats. These threats are due the use of internet, standardized protocols and electronic components for connec tivity and remote controls.

Nowadays, existing approaches for risk analysis ignore cybersecurity. In light of security threats, there is an urgent need for complete and effective safety risk analysis. That is why this paper proposes an approach that integrates ATs with BT analysis for a combined safety and security risk analysis. Bow-Tie analysis is used for analyzing safety accidents. Attack Trees are introduced to consider potential malicious attacks that can affect the system's safety. The concepts of BT and AT are presented and the process for likelihood evaluation is explained.

Due to the complexity of quantifying likeli hoods of attacks, and the no consistency in like lihood of occurrence between deliberate and accidental causes of risk. Two different qualitative scales are used for representing the likelihood of basic events related to safety and security. A differ ent likelihood scales provides three different types of events sequences. Qualitative mathematical rules are used to propagate the input probabilities through the BT-AT combined.

The outputs of the approach show important results in terms of representation of risk scenarios as well as in likelihood evaluation. MCs due to purely safety, security or both can be separately extracted. This separation between MCs helps understand the origins of risk and provide the right control measures.

The application of the proposed approach on an undesirable scenario in a chemical reactor shows that the highly likelihood MCs are purely related to security. The added improvement diminishes the unacceptable likelihood to an acceptable level. The resultsshow that the moves from purely security MCs to mix safety/security MCs is the safest risk treatment.

In the future, this work will be extended by pro posing a more robust likelihood evaluation tech nique. Quantitative data, if available, will be used for more accurate analysis. In addition, uncer tainty due to imprecision, vagueness and the lack of consensus (if multiple sources of data are used) will be considered.

Figure 1 .

 1 Figure 1. Definition of risk.

Figure 2 .

 2 Figure 2. SCADA architecture.

  sic a l in te g rity c a u s e d b y t h e o c c u rre n c e o f b a s ic e v e n ts O U n d e s ira b le e v e n t T h e u n w a n te d e v e n t s u c h a s a lo s s o f c o n ta in m e n t, e t c . □ S e c o n d a ry e v e n t C h a ra c te riz e t h e s o u rc e te r m o f a n a c c id e n t , s u c h a s ig n itio n i ■ D a n g e ro u s p h e n o m e n o n P h y s ic a l p h e n o m e n a t h a t c a n c a u s e m a jo r a c c id e n ts , e x p lo s io n , d is p e rs io n , fir e i R isk b a rrie r M e a s u re s ta k e n p la c e t o r e d u c e t h e lik e lih o o d o f u n d e s ira b le e v e n t a n d t h e e ffe c ts o f a c c id e n ts g > -Lo g ica l g a te s D e s c rib e t h e re la tio n s h ip s b e tw e e n e v e n ts

  In p u t e ve n tsOperation A n y step re p re se n tin g an operation m ad e b y th e attacker in o rd e r to p erform th e attack Vulnerability A n y step d escrib in g a vuln e rab ility re qu ire d in o rd e r to realize the attack O Assertion A n y ste p re p re se n tin g a ssu m p tio n s, results, o r re q u ire m e n ts characterizin g th e attack p roce ss ____ i Intermediate/top event A se c u rity b reach c aused b y the occu rre nce o f in p u t e ven ts

Figure 3 .

 3 Figure 3. Framework to combine BT and AT for safety/ security risk analysis.

  S ig n ific a n t: e v e n t is p u rely re la te d to se c u rity , u n lik e ly : e v e n t th a t is p ra c tic a lly im p o ssib le , v e ry lo w ch a n c e o f h ap p en in g e ly : Lo w c h a n c e o f o c c u rre n c e e v e n if w e c o n sid e r se v e ra l sy ste m s o f th e s a m e ty p e , b u t h as to be c o n sid e re d a s a p o ssib ility e ra te : m a y o ccu r d u rin g to ta l o p e ra tio n a l life if co n sid erin g se v e ra l sy ste m s o f th e sa m e typ e ~\ 10 C > L ik e ly e v e n t: m ay o ccu r d u rin g to ta l o p e ra tio n a lik e ly e v e n t: can fre q u e n tly o c c u r (se v e ra l tim e s) d u rin g o p e ra tio n a l life A

Figure 4 .

 4 Figure 4. The chemical reactor with its SCADA system structure.

Figure 5 .

 5 Figure 5. Combined AT-BT of the scenario under study.

Table 1 .

 1 Abbreviations, significations and definitions of elements listed in the Bow-Tie diagram.

Table 2 .

 2 Description of events used for representing an attack scenario.

Table 3 .

 3 Qualitative scale to characterize the frequency of input safety events.

Table 4 .

 4 Qualitative scale to characterize the frequency of input security events.

	Qualitative scale	Security Level	Designation
		0	Not Sign ificant: event is purely related to safety, not security
	"O	1	V e r y Low :

high unlikely to occur, never happened O before even on a similar system o

2 Lo w : possibility to occur, but existed security CL) measures reduce the likelihood of occurrence 3 M o d erate: somewhat

is likely to occur, but -J system is not an attack target 4

Table 5 .

 5 The identified MCs for the scenario under study.

	M CS	L ik e lih o o d	L ev el	M CS	L ik e lih o o d	L ev el
	1

Table 6 .

 6 The re-identified MCs after the added improvement.

	M CS	L ik e lih o o d	L ev el	M CS	L ik e lih o o d	L ev el
	1

ACKNOWLEDGMENTS

This work is based on research supported and funded by the French National Institute for Indus trial Environment and Risks (INERIS).


Narjes Jomaa

Samuel Hym

David Nowak

La conception d'un noyau orientée par sa preuve d'isolation mémoire *

Keywords: preuve formelle, co-design, isolation mémoire, Pip

La vérification des logiciels critiques tels que les noyaux des systèmes d'exploitation est une activité longue et complexe. Celle-ci nécessite une attention particulière dès les premières phases de conception. Le choix des fonctionnalités, la stratégie d'implémentation, le modèle du matériel à gérer, les propriétés à vérifier et l'approche de vérification sont tous à prendre en compte pendant le développement du noyau. Ce papier discute de la stratégie de co-design d'un noyau de système d'exploitation et de sa preuve. L'objectif visé est d'adapter le design du noyau pour réduire la complexité de la production de sa preuve tout en préservant son utilisabilité. La propriété étudiée dans ce papier est une propriété de sécurité, exprimée en terme d'isolation mémoire. L'étude présentée met notamment en évidence l'importance de l'interface d'accès au matériel. In fine c'est cette interface qui est axiomatisée pour construire la preuve du noyau.

Introduction

La sécurité des logiciels critiques est aujourd'hui un enjeu majeur dans le monde informatique. De nouvelles attaques confirment chaque jour la nécessité d'investir plus dans les outils et les techniques qui permettent de réduire la vulnérabilité de nos systèmes. Le plus souvent il suffit d'exploiter des failles dans le système d'exploitation pour compromettre la sécurité globale d'un système. Il existe plusieurs travaux autour de la vérification formelle des systèmes d'exploitation. Cette technique est fondée sur des notations mathématiques permettant de raisonner rigoureusement sur les programmes. Une grande majorité de ces travaux consiste à prouver des propriétés sur des systèmes de taille importante ce qui rend l'étape de la maîtrise de tous les détails de ce logiciel critique assez longue et donc la vérification devient plus compliquée à établir. Prenons l'exemple du noyau seL4 [START_REF] Klein | Comprehensive formal verification of an OS microkernel[END_REF] qui est aujourd'hui considéré comme étant le micro-noyau qui a les résultats les plus satisfaisants au niveau des preuves. L'objectif principal est de vérifier le bon fonctionnement du système ainsi que quelques propriétés de sécurité. seL4 contient environ 8700 lignes de C et 600 lignes d'assembleur impliquant environ 480 000 lignes de preuve en Isabelle/HOL [START_REF] Nipkow | Isabelle/HOL : A Proof Assistant for Higher-order Logic[END_REF]. L'hyperviseur HyperV [START_REF] Leinenbach | Verifying the Microsoft Hyper-V hypervisor with VCC[END_REF] contient environ 100 Kloc de C et 5 Kloc d'assembleur dont seulement 20% a été vérifié [START_REF] Moskal | VCC : A practical system for verifying concurrent C[END_REF]. Le noyau µC/OS-II [START_REF] Xu | A practical verification framework for preemptive OS kernels[END_REF], dont le bon fonctionnement de certains modules a été formellement vérifié, contient environ 6400 de lignes de C et d'assembleur. CertiKOS [START_REF] Gu | CertiKOS : An extensible architecture for building certified concurrent OS kernels[END_REF] est un autre noyau tel que le mécanisme de concurrence a été vérifié. Il contient 6500 lignes de C et d'assembleur ainsi que 450 lignes pour spécifier le modèle abstrait du noyau. Dans ce papier nous discutons nos choix de conception et de vérification du proto-noyau Pip [START_REF] Jomaa | Proof-oriented design of a separation kernel with minimal trusted computing base[END_REF][START_REF]The Pip Development Team[END_REF] qui ont favorisé la réduction de la taille du code du noyau ainsi que le coût de la production de sa preuve. En effet, la sécurité assurée par ce noyau est fondée sur le principe de partitionnement de la mémoire et les services fournis sont écrits en Gallina, le langage de spécification de Coq [START_REF]The Coq Development Team[END_REF], et traduit automatiquement vers C en utilisant Digger [START_REF] Hym | [END_REF].

Que cherche-t-on à garantir ?

Le choix des propriétés à vérifier dépend fortement du contexte dans lequel le système sera utilisé. Il est possible par exemple de prouver que les programmes se comportent correctement. Autrement dit établir une preuve mathématique sur le comportement fonctionnel du système. En revanche, même un système qui fonctionne correctement est susceptible de contenir des bugs de sécurité ce qui rend les programmes facilement attaquables. Dans le contexte des logiciels critiques tels que les noyaux des systèmes d'exploitation, il est prioritaire de prouver des propriétés de sécurité plutôt que de se concentrer sur le bon fonctionnement. Le choix des propriétés fonctionnelles dépend fortement des détails d'implémentation du système. Donc si le système est très complexe il est nécessaire de définir et vérifier de nombreuses propriétés pour prendre en compte tous les comportements possibles prévus par ce système, ce qui risque de faire apparaître un nombre important des propriétés. En effet, la sécurité n'est pas une propriété fonctionnelle et donc elle n'est pas liée à une fonctionnalité en particulier. Ainsi, sa preuve consiste à définir formellement ce qu'est cette propriété de sécurité puis prouver qu'elle est préservée par chaque étape de l'exécution du système. La sécurité, également, est un terme assez général. Dans le contexte d'un système d'exploitation la sécurité, telle que identifiée par Rushby [START_REF] Rushby | A trusted computing base for embedded systems[END_REF][START_REF] Rushby | The design and verification of secure systems[END_REF], consiste principalement à assurer la séparation entre les entités ainsi que contrôler les communications entre elles. Une première étape dans ce processus de vérification nécessite donc de définir clairement les propriétés de sécurité visées par la preuve et d'identifier les différents composants matériels ou logiciels sur lesquels reposent ces propriétés. Dans ce contexte nous nous intéressons à la propriété d'isolation mémoire. Cette propriété permet d'assurer qu'un programme ne peut pas accéder à la mémoire d'un autre programme. Nous considérons que c'est la propriété de sécurité la plus fondamentale car elle permet de prouver d'autres propriétés telles que celles qui consistent à assurer la sécurité de la communication entre les processus. Il est important de noter que d'après notre expérience, la vérification des propriétés de sécurité nous amène également à prouver certaines propriétés sur le bon fonctionnement. Elles sont formalisées soit sous la forme de propriétés de cohérence [START_REF] Jomaa | Formal proof of dynamic memory isolation based on MMU[END_REF] ou encore définies comme propriétés sur l'évolution de l'état au sein des services noyau. En revanche nous nous sommes limités à celles qui sont nécessaires pour prouver les propriétés de sécurité. Cela permet d'identifier les propriétés fonctionnelles les plus pertinentes tout en assurant la vérification des propriétés fondamentales de sécurité.

Méthodologie de développement et choix de conception de Pip

Une méthodologie traditionnelle de développement d'un noyau et sa vérification consiste à suivre d'une manière séquentielle les étapes suivantes : Conception, implémentation et preuve. En revanche, le co-design de noyau avec sa preuve nous amène à adapter cette approche en autorisant des feedbacks entre ces étapes. Autrement dit, influencer le développement d'une étape par une autre pour réduire le coût de la preuve et assurer l'utilisabilité du système. En effet, pour faciliter à la fois la preuve et la traduction du code, l'implémentation de Pip se décompose principalement en deux couches. API de Pip La première couche est la partie du code convertible de Gallina vers C. Elle comprend l'implémentation des différents services fournis par Pip. Ces services gèrent principalement la mémoire virtuelle des partitions et les interruptions, et assurent l'isolation mémoire. Il s'agit de dix appels systèmes [START_REF] Jomaa | Proof-oriented design of a separation kernel with minimal trusted computing base[END_REF] choisis minutieusement pendant la phase de conception afin d'assurer à la fois la faisabilité de la preuve et l'utilisabilité du système. Ce choix de minimisation du TCB (Trusted Computing Base) est principalement motivé par la réduction du coût de la preuve. Cependant, la réduction de la taille du TCB n'est pas un concept inconnu. Il a été adopté par la famille des micro-noyaux [START_REF] Liedtke | On micro-kernel construction[END_REF]. Il a été montré qu'il est possible de réduire le code exécuté en mode noyau à la gestion de la mémoire virtuelle, l'ordonnancement, la communication entre les processus, le multiplexage et le changement de contexte. Le reste des modules tels que la gestions des fichiers et les périphériques peuvent s'exécuter au même niveau que les applications utilisateur sans avoir d'impact sur la sécurité. Les exonoyaux [START_REF] Engler | Exokernel : An operating system architecture for application-level resource management[END_REF] sont conçus en suivant le même principe. En effet, ces travaux ont montré qu'il est possible de réduire encore plus le nombre de fonctionnalités exécutées en mode noyau. Leur modèle de sécurité exige d'implémenter la gestion de la mémoire virtuelle, le changement de contexte et le multiplexage en mode privilégié. De façon similaire, le co-design du proto-noyau Pip avec sa preuve (i.e. influencer la conception pour faciliter la preuve) nous a menés à réduire le TCB au strict minimum en exportant tous les modules qui ne sont pas nécessaires pour la sécurité en mode utilisateur, y compris le multiplexage. La gestion de la mémoire assurée par Pip est fondée sur le modèle de partitionnement hiérarchique [START_REF] Rushby | Partitioning in avionics architectures : Requirements, mechanisms, and assurance. -Rapport technique[END_REF]. Au démarrage du système, toute la mémoire physique disponible est mappée dans la partition racine. Cette dernière, comme n'importe quelle nouvelle partition, est autorisée à créer des partitions enfants en utilisant uniquement sa propre mémoire pour construire un modèle arborescent. Chaque nouvelle partition est configurée de sorte que toutes les pages associées à cette partition sont mappées dans la partition parent (ce qu'on appelle le partage vertical). Cette structure arborescente nécessite des structures supplémentaires en plus des pages du MMU dans chaque partition afin de garder des informations sur chaque page associée à une partition. Le choix de ces structures est également motivé par la réduction du coût de la preuve et l'utilisabilité du système. En effet, une première structure que nous avons appelée shadow1 reprend la structure arborescente des pages de configuration du MMU pour y stocker d'autres informations. Cette structure est nécessaire pour assurer l'isolation mémoire. Les données stockées dans cette structure permettent au noyau de savoir si une page mappée dans une partition parent a été partagée avec une partition fille ou non. Cela évite de mapper la même page dans plusieurs enfants différents car dans ce cas l'isolation mémoire ne serait plus garantie. Deux autres structures shadow2 (qui a également la même structure arborescente du MMU) et linkedList (une liste de paires d'adresses virtuelles et physiques) ont été mises en place pour faciliter la remise des pages à la partition parent après leur récupération dans le fils. Contrairement au shadow1 ces deux dernières structures ne sont pas nécessaires pour la sécurité mais elles sont utiles pour améliorer la performance de l'exécution des appels système fournis par le noyau. À cet égard Pip gère uniquement la mémoire des partitions (y compris la configuration du MMU et les structures internes des partitions) et le changement de contexte (qui se résume simplement à un basculement du flot d'exécution soit vers la partition racine, soit vers le père de la partition qui est en train de s'exécuter ou bien vers l'un de ses fils). Tous les services du noyau sont écrits dans un style impératif grâce à une monade d'état [START_REF] Wadler | Comprehending monads[END_REF] qui permet d'introduire et gérer facilement toute sorte d'effet de bord tels que la modification de l'état du système. L'une des particularités de notre stratégie d'implémentation est qu'aucun objet de la librairie standard de Coq tels que les listes ou les arbres n'ont été utilisés dans l'implémentation des services. En effet, de point de vue preuve il est plus simple de raisonner Compas'2018 : Parallélisme/ Architecture / Système Toulouse, France, du 03 au 06 juillet 2018 sur ce type de structures abstraites, en outre, cela peut complexifier la preuve du traducteur de Gallina vers C. Ainsi, comme réponse à ce problème, toutes les structures maintenues par le noyau (listes et arbres) sont codées explicitement dans la mémoire physique. Cela exige uniquement des primitives assurant la lecture et l'écriture dans la mémoire à des adresses physiques bien définies. Cet ensemble constitue le HAL. HAL La deuxième couche contient quelques dizaines de primitives assez simples et auxquelles nous faisons confiance. Elles sont écrites directement en C et en assembleur et uniquement utilisées par le noyau pour accéder à l'état du matériel. Pour chacune de ces primitives nous avons défini une fonction en Gallina modélisant le comportement de celle-ci. Par exemple, une des primitives en HAL est simplement un accès en lecture ou en écriture à la mémoire physique. Autrement dit, c'est la partie du code qui ne peut pas être exprimée en Gallina. Concrètement, la mémoire physique est modélisée par une liste d'associations en Gallina, telle que la clé est une adresse physique et la valeur est la donnée sauvegardée à cette adresse. L'accès matériel permettant la modification de la mémoire physique en C est modélisé par la modification de la liste d'associations. L'exemple suivant correspond à une fonction interne de Pip (getFstShadow), écrite en Gallina et sa traduction mot à mot en C. Cette fonction permet de récupérer une référence vers une structure de configuration d'une partition. Elle consiste en une séquence de trois primitives HAL : getSh1idx, succ et readPhysical et retourne la référence en question. Le code Gallina (à gauche) sera ainsi automatiquement traduit dans le code C (à droite) :

Quelle approche de vérification ?

Pour prouver des propriétés sur leurs systèmes, la majorité des travaux [START_REF] Klein | -seL4 : Formal verification of an OS kernel[END_REF][START_REF] Gu | CertiKOS : An extensible architecture for building certified concurrent OS kernels[END_REF][START_REF] Richards | Modeling and security analysis of a commercial real-time operating system kernel[END_REF][START_REF] Dam | Formal verification of information flow security for a simple ARM-based separation kernel[END_REF][START_REF] Sanán | Separation kernel verification : The xtratum case study[END_REF] utilise une approche par raffinement [START_REF] Abadi | The existence of refinement mappings[END_REF]. Cette approche consiste à développer et prouver des systèmes de manière incrémentale. Il s'agit de définir un modèle abstrait du système désiré, puis à partir de ce dernier définir graduellement son implémentation en introduisant à chaque niveau plus de détails sur les objets manipulés par ce système tels que les structures de données et les variables. La preuve de la propriété de sécurité se fait uniquement au niveau du modèle abstrait. Chaque niveau inférieur est considéré comme un raffinement des niveaux précédents et une preuve est nécessaire pour prouver la validité de chaque niveau de raffinement. Cette approche est avérée la moins coûteuse en supposant que sa preuve est plus rapide à établir en la comparant avec l'établissement de la preuve des propriétés directement sur le code. Mais cela a aussi un coût. En effet, la définition d'un modèle abstrait de ce qu'on vise à implémenter repose généralement sur une intuition de ce que fait le système [START_REF] Parnas | A rational design process : How and why to fake it[END_REF]. Donc le risque de définir un comportement abstrait qui n'existe pas au niveau de l'implémentation concrète est tout à fait Compas'2018 : Parallélisme/ Architecture / Système Toulouse, France, du 03 au 06 juillet 2018 possible. Plus précisément, nous pouvons définir des comportements qui n'existeront pas dans le vrai système. Puis pendant l'étape de vérification des raffinements il est possible de détecter cette incohérence dans un niveau plus loin voire seulement au niveau de l'implémentation finale. Dans ce cas il faut modifier toutes les spécifications intermédiaires ainsi que la preuve de la validité du raffinement. Le co-design d'un noyau et de sa preuve nécessite des échanges réguliers entre les deux équipes de développement et de vérification dans le but d'obtenir un compromis entre l'utilisabilité du logiciel conçu et la faisabilité de sa preuve. Mais, le processus de raffinement, en pratique, est généralement dirigé par l'équipe de vérification et rarement maîtrisé par les développeurs, ce qui limite la collaboration entre les deux équipes [24, p.xxiii]. Il est donc possible de faire des choix de design qui ne seront pas validés pendant la dernière phase de conception (c'est-à-dire l'implémentation finale). Le noyau Pip que nous avons développé est plus petit (à dessein) que les noyaux identifiés au début de ce papier, il contient environ 1500 lignes de code et comprend les services nécessaires pour assurer la sécurité et son utilisabilité. La réduction de la taille du code à prouver nous a menés à adapter la méthodologie de vérification. En effet, nous avons appliqué une approche différente qui est la preuve directement sur le code en s'appuyant sur les invariants [START_REF] Jomaa | Formal proof of dynamic memory isolation based on MMU[END_REF]. L'exemple suivant consiste à prouver le triplet de Hoare [START_REF] Hoare | An axiomatic basis for computer programming[END_REF] définissant l'invariant d'un appel système sys_call : {isolation & cohérence} sys_call {isolation & cohérence}. sys_call pourrait être l'un des services fournis par le noyau Pip. Notre processus de vérification consiste à prouver que les propriétés d'isolation et de cohérence sont préservées par tous les services du noyau (la formalisation des propriétés et leurs vérification ne font pas l'objet de ce papier : voir [START_REF] Jomaa | Proof-oriented design of a separation kernel with minimal trusted computing base[END_REF] pour plus de détails) et que la traduction de Gallina vers C est correcte. Il est important de noter que prouver des propriétés directement sur le code donne au prouveur la maîtrise de tous les détails d'implémentation. Suite à notre expérience, cela s'est avéré important pour faciliter le raisonnement sur certaines séquences d'instructions. Bien que, du point de vue concepteur c'est le résultat final de l'exécution d'un service noyau qui compte, l'ordre dans lequel les instructions sont exécutées peut compliquer la preuve. Dans ce contexte nous avons identifié deux règles : rapprocher le calcul d'une valeur de son utilisation et éviter les incohérences temporaires dans les structures de données d'une partition pendant l'exécution d'un service. Par exemple, considérons une fonction qui met à jour une liste chaînée, quand il s'agit d'ajouter d'un élément dans cette liste il est recommandé d'initialiser la nouvelle cellule avec la bonne valeur avant de l'associer à la liste. Cela garantit la cohérence durant l'exécution de la fonction. Ainsi, à plusieurs reprises nous avons décidé de changer l'ordre d'exécution de certaines instructions pour faciliter l'établissement de notre preuve.

Invariants lignes de preuve temps createPartition (≈ 300loc)

≈ 60000 ≈ 10 mois createPartition + addVaddr (≈ 110loc) ≈ 78000 ≈ 2 mois createPartition + addVaddr + mappedInChild (≈ 40loc) ≈ 78300 ≈ 4 heures

1

  Definition readPhysical (paddr : page) (idx : index) : LLI page := 2 perform s := get in ( * Récupère l'état * ) 3 let e := lookup paddr idx s.(memory) beqPage beqIndex in ( * Récupère l'entrée * ) 4 match e with 5 | Some (PP a) ⇒ ret a ( * Retourne la valeur si elle est de type Page * ) 6 | _ ⇒ undefined 5 ( * Sinon signale un comportement indéfini * ) 7 end.

Confiance en HAL Concrètement

  , le comportement du matériel est plus compliqué que notre modèle abstrait de HAL en Gallina. En plus de la mémoire physique, il peut être nécessaire de gérer d'autres composants internes tels que les caches ou le TLB. Nous considérons que le HAL représente une abstraction du comportement du matériel géré par le noyau. C'est une manière de formaliser l'idée que le développeur se fait du comportement du matériel tout en gardant une formalisation indépendante d'une architecture en particulier. Nous partons du principe que la vérification des propriétés de sécurité nécessite dans un premier temps d'identifier clairement le rôle du noyau et celui du matériel dans le contexte de la sécurité. Cela nous permet de découpler l'implémentation du noyau des hypothèses sur lesquelles reposent les propriétés de sécurité. Le but de nos travaux est de vérifier les propriétés du noyau, donc la manière dont le matériel effectue sa tâche devient un problème orthogonal et nécessite Compas'2018 : Parallélisme/ Architecture / Système Toulouse, France, du 03 au 06 juillet 2018 partitions nécessite des opérations d'écriture dans la mémoire physique. Le rôle du matériel ici est d'effectuer la modification, en revanche c'est le noyau qui doit fournir les valeurs. Par conséquence, le but principal de la vérification sera plutôt sur les valeurs fournies par le noyau en fonction desquelles le matériel effectue l'opération. L'exemple suivant permet de comparer l'implémentation en C d'une primitive HAL avec son modèle en Gallina. Cette primitive, readPhysical, retourne l'adresse physique sauvegardée à l'adresse passée en paramètre. Dans le contexte de getFstShadow, la valeur retournée par cette primitive correspond à une valeur dans une page de configuration d'une partition. En C, il s'agit simplement de récupérer la valeur sauvegardée dans table à la position idx. Par contre, son modèle en Coq, qui est une fonction monadique, met en place un test supplémentaire permettant de vérifier que le noyau avait déjà sauvegardé une valeur de type page (i.e. PP) à cette adresse physique sinon c'est considéré comme un comportement indéfini. Ainsi, pour prouver que cette primitive retourne bien un numéro d'une page physique, il suffit de prouver que les arguments fournis par le noyau ont les propriétés nécessaires pour satisfaire le test défini dans le modèle en Coq. Donc concrètement, nous supposons que l'implémentation de readPhysical en C est correcte mais nous prouvons que les valeurs table et idx fournies par le noyau ne produisent pas un comportement indéfini. La primitive readPhysical en C :

	uint32_t readPhysical(uint32_t table, uint32_t idx) {	1
		disable_paging(); / * En mode noyau : nous pouvons désactiver le MMU * /	2
		uint32_t dest = table | (idx * sizeof(uint32_t));	3
		uint32_t val = * (uint32_t * ) dest;	/ * Récupère l'entrée * /	4
		Definition getFstShadow part := enable_paging();	uintptr_t getFstShadow(uintptr_t part) { 5 / * Réactive le MMU * /
		perform idx := getSh1idx in return val & 0xFFFFF000;	const uint32_t idx = getSh1idx(); / * Retourne la valeur * /	6
	}	perform idxSucc := Index.succ idx in readPhysical part idxSucc.	const uint32_t idxSucc = succ(idx); return readPhysical(part, idxSucc); }	7
	Son modèle en Gallina :

Il est important de noter qu'une primitive HAL ne correspond pas à une instruction du CPU. Elle consiste simplement en une opération élémentaire, du point de vue du modèle, permettant d'accéder à la mémoire, effectuer un calcul logique ou alors récupérer la valeur d'un paramètre lié à l'architecture.

4. une preuve complémentaire

[START_REF] Barthe | Cache-leakage resilient OS isolation in an idealized model of virtualization[END_REF][START_REF] Syeda | Reasoning about translation lookaside buffers[END_REF][START_REF] Kocher | Spectre attacks : Exploiting speculative execution[END_REF][START_REF] Lipp | Compas'2018 : Parallélisme/ Architecture / Système[END_REF]

. Par exemple, Pip contrôle l'accès des processus à la mémoire physique à travers le MMU. Donc nous prouvons que la propriété de sécurité est préservée à travers une configuration correcte des tables de MMU. Cette configuration est effectuée par le noyau en s'appuyant sur l'hypothèse que le MMU traduit correctement les adresses virtuelles en adresses physiques. De même, la configuration des structures internes des

TABLE 1 -

 1 L'organisation de la preuve Actuellement une partie importante de l'implémentation du noyau a été vérifiée. Elle concerne les services illustrés par le tableau 1. La vérification de l'appel système createPartition correspond à la preuve à laquelle nous avons consacré le plus d'effort. Cela est justifié d'une part par sa complexité (il consiste en environ 300 lignes de code), et d'autre part parce que c'était le premier service abordé par la vérification. En effet, durant le processus de sa preuve, nous avons défini la majorité des propriétés de cohérence et donc une partie importante des théorèmes sur les structures manipulées par le noyau ont été définis et prouvés.