Security for automation systems using risk analysis techniques

Linking, open standards, interfaces and PC based technologies are constantly increasing in industrial automation. The threat potential of attacks and malware - such as Stuxnet and many others - is increasing at the same time, making security very important in both office IT and industrial networks. Risk analyses, writes Franz Köbinger, help you decide which protection is sufficient at which cost without limiting availability and manageability.

EXPERIENCED SECURITY experts are stressing the fact that security is not a single feature but a complete process. This means that individual security measures, security functions or devices do not offer comprehensive protection but several components usually have to act in unison. These components have to be amended and supported by organisational and possibly physical protection measures, such as access controls. Even comprehensive security measures have to be evaluated and adjusted from time to time to adapt to the changing threat.

The same applies to network security and that includes all networks, regardless of whether they are office, automation or infrastructure, such as the energy industry.

Because the threats and risks are different in each system and network because of their different designs, tasks and operating conditions, there are differences in the type and priority of protection targets, and in the protection measures chosen as a result.

To make a sound decision about which security measures will be implemented, it is first necessary to analyse those existing risks that cannot be tolerated. It is then necessary to derive protection targets, and from these, the concrete measures that can and should be implemented. If risk analysis and determination of the protection targets are neglected or not carried out, there is a great risk that inappropriate, overpriced and ineffective measures are taken, while weak points are not detected and remedied.

Fig. 1. Plant security acceptable risk v unacceptable risk: This shows a decision matrix for the evaluation of risks following a plant-specific risk analysis.

Risk analysis

The typical contents of a risk analysis (see Figure 1) include:

• Identification of threatened objects

• Analysis of value and damage potential

• Threat and weak point analysis

• Identification of existing security measures

• Risk evaluation

Identified and unacceptable risks must be excluded and reduced using suitable measures. Which remaining risks are finally acceptable must be determined individually for each application, because there is no absolute security without risk. The goal must be to minimise the risks in an appropriate and affordable way.

Security and automation

The special requirements of automation systems must be taken into consideration when designing security measures. Typically, the 'Security Policies' of commercial IT environments cannot easily be implemented into the automation arena because there are significant differences between office and industrial environments.

Availability is usually the first security goal in an automation environment. Confidentiality is usually less important, because plant standstill or downtime generally have far more serious consequences than the possible loss of data. For the same reason, the timely patching of automation computers is often problematic. A patch must be tested for compatibility, which is time-consuming. Even then, the patch cannot necessarily be uploaded when needed, or when the plant is operating.

Another example of the differences is the fact that the life cycles of production plants are much longer than those of classical IT. Automation life cycles can be 10, 15 or even 30 years, so updates and the removal of security gaps and the necessary support of manufacturers for these devices is often no longer available and weak points can no longer be removed. This clearly calls for other external protection measures to be established in production plants, which means that the requirements regarding availability and performance limit the use or acceptance of security policies from classical IT networks - and to some extent even requires new or partially modified concepts.

Industrial security concepts

A number of threats exist for automation networks: viruses, worms, trojans, so-called malware, access violations to networks and devices by (internal and external) unauthorised personnel, espionage and manipulation of data during transmission or in devices. Each of these threats requires special countermeasures.

Virus protection. Virus scanners are usually deployed against malware, but they cannot guarantee complete protection because no virus scanner can detect all viruses. In addition, where new viruses are concerned - especially in connection with zero-day exploits, which take advantage of a security vulnerability - it always takes time for the corresponding updates to be made available for virus scanners. Then there is the problem that automation computers cannot be updated at just any time, for example, during ongoing operation, and that compatibility with used applications must be ensured, which usually results in further delays. Depending on the maintenance cycle, it may be months before an update can be uploaded.

Because of such virus scanner limitations, whitelisting systems represent an alternative. Whitelisting means that only specific, approved applications and services may run on a computer. Even if a virus enters a computer unnoticed, any action of the virus is blocked because its actions are not listed as permitted (whitelisted) operations. This approach offers protection even against unknown viruses. Computers in an automation environment are not updated with new applications as frequently as in a classic IT environment, which means it is even easier to update whitelisting systems.

Network segmentation/cell protection. Only a few automation devices offer sufficient integrated security functions; a fact that will not change any time soon because of their long life cycles. Even though ever more devices are being equipped with security functions by manufacturers, there will always be devices that do not offer any security functions for cost optimisation or other reasons.

Additionally, there may be some cases in which real-time requirements do not allow the use of performance-intense security functions such as encoding or secure authentification. Even so, such devices must also be protected. As early as 2005, the PNO recommended the cell protection concept in its Profinet Security Guideline to meet these requirements.

The idea is simple. Use a security appliance, which is an especially toughened network component that comes equipped with security functions including firewall and VPN. These appliances, also referred to as security modules, protect automation devices by being installed upstream and representing the only access to the protected equipment. The secured area is also referred to as a cell and corresponds to a network segment, usually an independent subnet. This approach segments the network for security reasons.

The firewall can now control access to the cell and users can specify which network participants can communicate with each other, and perhaps even the protocols they use in the process. Such an approach prevents unauthorised access and reduces the network load because not all communication, e.g., broadcasts (messages to all network participants), may take place.

The security modules can also set up secured VPN channels with each other so that communication from and to the cells is encrypted and subject to secure authentification. This approach protects data transmissions against manipulation and espionage.

The advantages are obvious - a security module can protect several other devices, which means that users don't have to install and administer this function in each device. Realtime communication within the cell is not affected by performance-intense security functions and access to the cell is still protected.

The size of a cell or the type of network segmentation depends on the network design or topology, as well as the risks and protection targets. These should be determined using a risk analysis. Bear in mind that the security module cannot control the data traffic within the cell, so local access within the cell must not happen or must only be used by authorised personnel, which means that it must be protected by other means.

Figure 2 shows the protection of automation devices with the through cell protection concept using security modules.

Fig. 2. The protection of automation devices: the through-cell protection concept using security modules

Network access

All access to a network must be checked so that unauthorised people cannot gain entry. In addition to secure remote maintenance access and secure connections to other networks, it is also necessary to take into consideration the ports of switches and routers - these must at least have appropriate access lists that specify which devices, or which MAC or IP addresses, may connect to which ports.

Many switches support the IEEE 802.1x standard in which an authentication server queried by the switch checks the authentication of participants wanting to connect to a port. Depending on the access right(s), the network component can grant access to the authenticated participant - even to a specific VLAN - if necessary, so that the participant does not have access to all devices in the network.

Terminal security. It is not always possible to use the same cell protection concept. This may be because of the network topology or specifically created application-specific access rights. Some devices have to be able to protect themselves for this reason. Communication participants wanting to communicate with the device have to authenticate themselves directly on the device in this case, for example, using a password.

Application-specific access rights can be implemented in the form of several protection levels that can distinguish between read-only and write access, for example, by assigning different passwords for each protection level.

Fig. 3. A model of a multi-level security concept: This creates as many layers as possible between the outside world and the machine/plant to be protected, and combines several security measures

Toughening of products

The measures described above are all 'active', meaning that they correspond to specific security functions. However, even more security can be added by using only toughened products. Toughened here means products that had been checked for possible weak points during development by the manufacturer, with those weak points being subsequently removed so that hackers or malware cannot take advantage of them.

Summary

Several security measures are required to reduce the risks. They are used as supplements, because not every measure works against every threat, and because they set up more hurdles that possible attackers will have to overcome. Such a strategy is referred to as 'defence in depth'. However, all these measure are not going to be very effective if they do not work alongside appropriate organisational measures which control the physical access, for example, or prescribe the use of secure passwords.

Franz Köbinger is system manager for security at Siemens Industrial Communication and head of the Profinet Security working group.

www.automation.siemens.com