## 5 Reactive Protection Concept for Industrial Automation Systems
### Security Policies, Operational Policies and Reactive Actions in Real-Life Automation Systems
#### 5.3.1 Security Policies  
The following classes of security policies have been identified based on four different components that constitute a system: communication, computer resources, users and sessions, as well as services. A fifth class has been integrated in order to represent well-known events that require immediate attention. These policies have been selected, as they are relevant for IAS and provide opportunities for reactive actions that may be integrated into the reactive protection concept presented in this work. * **Communication Management (S1):** These policies define constraints related to allowed or disallowed communication among system components. These policies often consider communication-specific attributes such as source and destination addresses (i.e., IP addresses, MAC addresses), logical port numbers, etc. This class allows for providing security solely based on characteristics from the communication without considering more detailed information such as user- or service-specific information. * **Computational Resource Management (S2):** These policies define constraints related to computational resources found in the automation system. These policies often consider resources that can be measured on a system-, multi-device- or device-specific level. Examples of these resources are the following: network load, RAM, ROM and CPU usage, etc. * **User Access Control and Session Management (S3):** These policies are related to the identification and authentication of users, devices or other entities that possess an identity, as well as the sessions and other events resulting from such authentication. Specific policies of this category may include but are not limited to constraints related to identity, authentication and session information (e.g., number of failed authentication attempts, authentication and session status and other detailed information). * **Service Management (S4)**: These policies define allowed or disallowed services or protocols, as well as their configurations. They do not consider user-specific information regarding the use of such services. * **Incidents (S5)**: These policies represent well-known conditions that require immediate action. Some of these are the following: malware detection and vulnerability detection. The aforementioned classification allows for defining simple and straightforward policies. Although multiple security policy languages and standards exist [48], the presented concept does not consider one specifically. This is done in order to provide ambiguity that may allow in the future to adapt this concept for any desired language or standard. Hence, in this concept, policies are considered as abstract rules. This is possible as policies often contain information that address the following questions [49]: _what, who, when_ and _where_. Furthermore, most policy languages are based on two different paradigms [48]: _Event-Condition-Action_ or _Condition-Action_ paradigms. From these two paradigms, the most suitable for the reactive protection concept presented in this work is the _Event-Condition-Action_ paradigm, as it requires an _Event_ element that triggers the execution of the _Action_. In the presented concept, an _Event_ is any security event received by the Reactive Protection System from third-party components. A _Condition_ is comprised of the security constraints that must be met (e.g., service A must not be running). Finally, an _Action_ may be any reactive action that helps meet the identified _Condition_ or that helps counteract the effects of an intrusion. In addition, this simple policy classification allows for further building more complex policies that may merge two or more classes. This is done, as it may be possible that the information regarding the security event provided to the Reactive Protection System comes from simple or more complex security solutions. Examples of this case are the following: simple security event information may be received from a simple Syslog [50] client located on a device.