## 6 Reactive Protection System Applicability
### Security Policies and Intrusions  
Following the approach presented in Section 5.3.1 and the extended reference IAS architecture and its components (Figure 4), fifteen security policies have been derived. Table 3 describes each of these policies and to which security policy class each of them belongs. It also presents for each of these policies a corresponding security-related event example. This example provides a source device (i.e., third-party security component that detected the intrusion or collected the security-related event information) and a small description of a security-related event. These policies and event information are represented in natural language in order to provide a simple and clear description of each of them. However, for their technical implementation, it is recommended to use one of the many policy languages and event formats that exist [48; 57]. As it can be observed from Table 3, an Industrial Network IDS can provide information regarding communication, user and service events (i.e., _S1_, _S4_). One example of this is the identification of a new Firmware version being downloaded into a PLC. Once the Reactive Protection System is notified of this event by the Industrial Network IDS, it verifies its network zone security policies. This verification may result in the identification of a security policy that is violated (i.e., _SP9_), which would result in a reactive action (i.e., active response) being necessary. This active response is independent from any other response (i.e., active or passive) that may be supported by the Industrial Network IDS. It is the choice of the system integrators and security experts to decide which responses are appropriate in the presence of which events; hence, this has to be configured and defined before the deployment of the IAS or during maintenance. An advantage of the Reactive Protection System is that it is also capable of complementing other components that do not provide a high degree of sophistication and analysis like an Industrial Network IDS. An example of this is the security policy _SP4_ that validates a RAM usage threshold. Its corresponding security-related event can be received from a Host Device and not a sophisticated security solution. This event may be provided by a simple client application that monitors the RAM usage on the host device or a Host IDS. After discussion of the security policies, their corresponding intrusions are presented in Table 4. These intrusions are comprised of security attacks and other events (e.g., misuses and misconfigurations) in IAS that may threaten the security of the system (i.e., violate the security policies). They have been derived from [34; 58]. It is important to highlight that some of these intrusions may violate more than one security policy. Hence, it is necessary to properly configure both the security policies, and their reactive actions in order to avoid conflicts (e.g., one intrusion generates two security policy violations that executes two conflicting reactive actions). Both DoS and SYN Flood attacks (_I1_ and _I3_) may result in a big amount of simultaneous connections and an overhead in the performance of the targeted device (i.e., violates _SP2_ and _SP4_). In wireless devices, a Jamming attack (_I2_) may be caused by an unauthorized wireless device (i.e., violating _SP15_). A Brute Force Attack (_I4_) and misuse in user authentication by users (_I8_) may exceed the maximum amount of login or connection attempts (i.e., violating _SP6_ and _SP7_). On the other hand, Malware (_I5_) may open undesired logical and physical ports (i.e., violating _SP1_ and _SP3_) providing a backdoor for intruders. It may also consume undesired computational resources of the target device resulting in exceeding predefined thresholds (i.e., violating _SP4_) and download malicious software (i.e., violating _SP9_, _SP10_, _SP12_ and _SP14_).