A stepped approach to securing automation systems
24 February 2015
Professor Dr. Frithjof Klasen, a member of the Managing Board of the PROFIBUS Nutzerorganisation e.V. (PNO), discusses problems surrounding security for automation systems and explains how guidelines from communication technology organisations, such as PROFIBUS & PROFINET International (PI), can be helpful.
Typical security threats in the production environment can include infection by malware, unauthorised use (both intentional and unintentional), manipulation of data, espionage and related know-how loss, and denial of service. The consequences of security breaches can be loss of production, reduced product quality, and can pose a safety threat to both humans and machines.
In order to evaluate threats, the properties and possible weak points of devices and systems must be known. A property that is useful from the automation perspective – for example, the ability for a programming device to access a controller without authentication – can be seen as a possible weak point from the security perspective. It is necessary to distinguish these weak points in order to assess risks, develop security solutions, and take appropriate measures. Areas to focus on include:
• Weak points that arise due to incorrect implementation (for example, faulty device behaviour).
• Conceptually planned and accepted properties. These include all features that can also be exploited for attack purposes. An example here would be an integrated web server in an automation device.
• Weak points that are caused by organisational measures or lack thereof.
Field devices contain communication technologies for transmission of process signals (real-time communication) and also standard IT technologies such as FTP services. In addition, field devices operate as network infrastructure components (switches) and therefore have services and protocols that are needed for network management and diagnostic purposes. Most communication protocols at the field level have no integrated security mechanisms. Devices and data are not authenticated and, consequently, within the scope of a possible attack, systems at the field level can be expanded at will and communications can be imported. Even the transferring of PLC programs often takes place without use of security measures such as user authentication and integrity protection.
Ideally, users want a tool, certification, or system that promises long-term security. The difficulty, however, is that such solutions do not provide lasting security. In order to develop secure systems, users must implement both technical measures and conceptual and organisational measures.
Conceptual and organisational weak points can be more easily overcome when they are described in guideline documents. PI, for example, developed the ‘Security Guideline for PROFINET’ in 2006 and published a revised version of this guideline at the end of 2013. This guideline specifies ideas and concepts on how security solutions can be implemented and which security solutions should be implemented. The subject of risk analysis is covered, for example. This analysis estimates the probability of a damage event and its possible consequences, based on protection goals, weak points, and possible threats. On the basis of an analysis of this type it is possible for economically feasible and appropriate security measures be derived. The guidelines also offer a series of proven best practices, such as the cell protection concept.
Making devices more secure
Another measure concerns device security. Robust devices are the basis for stable processes and systems and are a prerequisite for security in automation. Weak points due to incorrect implementation can only be eliminated through appropriate quality assurance measures and certifications.
In large networks, system availability matters the most. To achieve this, devices must respond reliably to various network load scenarios. In systems with many devices, an unintended elevated broadcast load can occur on the network during commissioning. For example, when the master attempts repeatedly to access all devices even though only a few devices are connected. The available devices need to be able to handle this abnormal load. It is difficult for operators to predict such scenarios since the probability of a high data volume is dependent on the system. The reason is that the data traffic is determined by cyclic and acyclic data exchange as well as the event-driven data volume.
With the help of the Security Level 1 Tester, developed by PI for certification of PROFINET devices, such network load scenarios up to and including denial of service can be simulated in advance. Field devices can be tested under stress conditions to simulate an unpredictable load, therefore helping to reduce device failures. Uniform test specifications have been defined for this, which can be systematically applied by the test tool. In addition, various network load-related scenarios have been developed that take into account various frame types and sizes as well as the repetition period and number of frames per unit of time. The network load-related test is already being required by various end-users in the automotive industry, in particular. This test is already integrated in the device certification testing according to the latest PROFINET 2.3 specification and must therefore be passed in order for a device to be certified.
Only those who know their devices can protect them. However, not all manufacturers provide comprehensive information about the utilised protocols and services and communication properties utilised by their devices. In spite of security, users still need to be able to handle and operate systems. No maintenance technician will want to look for a certification key for a failed device in the middle of the night in order to bring a system back online. Future-oriented concepts therefore need to ensure a good balance between usability and security.
PI has been dealing with the issue of security for some time. One PI Working Group, for example, is concentrating continuously on security concepts, and the PROFINET Security Guideline, was one of the results to come out of this working group. Further development of the Security Level 1 Tester is also being advanced. In so doing, it is important to all participants that the described and recommended procedures are sustainable and practicable and ultimately also accepted by users. Only in this way can protection concepts be truly successful.
Contact Details and Archive...
Most Viewed Articles...