## 8 Evaluation of Feasibility and Applicability of the Reactive Protection Concept
### Hypotheses  
In order to prove the feasibility of the presented concept, the fulfillment of the requirements presented in Section 3 must be verified. In order to do so, four hypotheses have been derived. In the following, these hypotheses are presented. The discussion regarding their proof is supported by the prototypical implementation presented in Section 7 and the aforementioned use case scenarios. The mapping between hypotheses and the requirements they verify is presented in Table 6.  
**Hypothesis 1. **_Conditions required to meet operational requirements (high performance, availability and real-time capabilities) of an automation system can be defined as operational policies._ \begin{table}
\begin{tabular}{p{113.8 pt} p{113.8 pt} p{113.8 pt}} \hline \hline
**Hypothesis Number** & **Hypothesis** & **Requirement** \\ \hline \multirow{3}{*}{1} & Conditions required to meet operational requirements (High Performance, Availability and Real-time capabilities of an automation system can be defined as operational policies & \multirow{3}{*}{R3} \\ \cline{2-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \cline{1-1} \cline{3-3}  & & \\ \hline \hline \end{tabular}
\end{table} 
Table 6: Mapping between hypotheses and requirements. Policies are often referred to as rules, conditions or constraints that must be maintained [4]. Hence, operational requirements may be also defined as policies. In the presented concept, these operational policies were defined by identifying critical assets that constitute an automation system. From these assets, a classification of operational policies was derived. This derivation was achieved by analyzing cases or conditions related to these critical assets in which the main operational requirements of IAS could be negatively affected (i.e., high performance, availability and real-time capabilities). Each of the classes defined in this classification describes in detail the information that such policies may contain. Additionally, a few examples are provided (Section 5). The applicability of these policies was evaluated through the aforementioned scenario. Furthermore, by deriving these policies from critical assets related to operational requirements in IAS, it is ensured that, by considering these policies, these requirements are met--hence fulfilling \(R3\) defined in Section 3. Hence, the hypothesis that operational requirements of an automation system can be defined as operational policies can be defined as true. **Hypothesis 2**. : _Harmonization between security and operational policies ensure that reactive actions in the presence of intrusions do not affect the correct operation of the underlying automation system._  
In Section 5, security and operational policies applicable for IAS were presented. These security policies were derived from the ISA/IEC 62443 series of Standards, hence fulfilling \(R2\) defined in Section 3. Furthermore, from these security policies, reactive actions that could counteract the effects of intrusions were also identified. Although consideration of both security policies and reactive actions are capable of protecting against intrusions, their implementation in IAS could potentially affect the correct or expected operation of the underlying automation system. Hence, the concept for reactive protection presented in Section 5 not only considers security policies and reactive actions, but also considers operational policies. By doing so, the validation of operational policies ensures that no reactive action that could negatively influence the operation of the automation system is executed. However, in order for this concept to be effective, it is necessary that the defined security and operational policies do reflect the real security and operational requirements.