The requirements placed on 'security' - i.e. ensuring the protection goals of confidentiality, integrity and availability - by the IT and automation worlds differ significantly: while the confidentiality of information has the highest priority in the office environment, the availability and integrity of data is the top priority in the production sector. On the one hand, this is an essential prerequisite for smooth production processes; on the other hand, an attack on the integrity of a safety system can result in serious accidents. For this reason, an addendum was added to chapter 7.4 'Hazard and risk analysis' in Edition 2.0 of the IEC 61508-1 standard. This states that a threat analysis should be carried out if a security threat is considered 'reasonably likely'. This means that manufacturers of safety systems in particular must address the issue of security. However, manufacturers of systems that do not implement safety-related functions should also be concerned with security in order to prevent attacks on production processes.

Lean security in demand

Currently, the security of production systems is often implemented using security components such as firewalls and VPN gateways. Industry 4.0 and IoT will increase the communication relationships between automation components and with external systems. This leads to an increase in the effort required to manage external security solutions. If wireless technologies are used, firewalls also offer only limited protection, as an attack could be carried out directly via the wireless interface and the lower protocol layers. To counteract these problems, security measures must be implemented directly in the systems.

Safety and security have clear parallels in terms of standardization and the approach to the engineering process. When it comes to implementation, many processes and experiences from the safety world can be directly transferred to the security world.

© Mushroom

This is where the term 'security by design' or 'secure by design' comes into play: it describes a development approach in which the security properties of a system are already systematically considered during the design phase. This means that it is not left to chance or the judgment of individual developers to decide whether and to what extent security functions are implemented in a system. Instead, threat modeling is used to determine which threats a system is exposed to. From this, targeted measures can be derived to minimize the security risk.

In a broader sense, 'security by design' can also be understood as an approach in which the security of a product is considered holistically over the entire product life cycle. A frequently cited and well-documented example of this approach is the Security Development Lifecycle (SDL) process developed by Microsoft: at the beginning of the 2000s, negative headlines regarding security problems in Microsoft products became more frequent. This prompted the company to systematically address the issue of security, which led to the development of the SDL. Since then, many other software and device manufacturers have adopted a similar approach.

Security has therefore played a central role in traditional IT for a long time. However, the requirements cannot simply be transferred to automation due to the different priorities with regard to confidentiality and availability.

Starting point standards

IEC 62443 'Industrial communication networks - IT security for networks and systems', on the other hand, is an international series of standards, parts of which have already been adopted and comprehensively cover IT security in automation. The spectrum of topics ranges from risk analysis and best practices to the secure development of products. As a result, IEC 62443 currently offers the best guidance for system operators and device manufacturers to implement security effectively. The standard was originally defined by the ISA99 committee 'Industrial Automation and Control Systems Security' and adopted by the IEC standards committee. The individual parts of the standard are divided into four areas: General, Policies & Procedures, System and Component/Product, whereby the specific requirements are subdivided into groups - so-called 'Practices' (top left image).

Practice 1

Security management - places various requirements on the management of the development process. These include the need to have a general product lifecycle process in place, to appoint responsible persons and to train employees with regard to their role in the process and their security knowledge. Further requirements apply to the security of the development environment and the handling of subcomponents from third-party manufacturers.

Practice 2

Specification of security requirements - describes requirements for the specification of security requirements. For example, 'Product security context' specifies that the system context must be defined from a security perspective for the system to be developed. The context describes, for example, the physical security properties of the environment (e.g. the system must be operated in a closed control cabinet) and the properties of the network environment (e.g. the system must be secured by a firewall). The security context is an important input variable for threat modeling, which is also required by a requirement.

Practice 3

Secure by design - defines requirements for the design of the system. For example, recognized security techniques and design patterns such as 'Security By Design' should be used. These requirements thus implement the first interpretation of the term 'security by design'.

Practice 4

Secure implementation - the requirements here are intended to ensure that no security vulnerabilities arise due to errors in the implementation. This includes adhering to recognized coding guidelines, performing a static code analysis and carrying out a code review.

Practice 5

Security verification and validation testing - defines the type of security tests to be carried out. Requirements are also placed on the independence of the testers.

Practice 6

Management of security-related issues - defines requirements for dealing with security problems in the product. In addition to analyzing problems, this also includes receiving reports (e.g. from customers or security researchers) and notifying users of any security problems found.

Practice 7

Security update management - this sets out requirements for the management of security updates. This includes ensuring that an update actually fixes a vulnerability as intended and does not cause any new problems. It also requires the manufacturer to inform users whether security updates of dependent components (e.g. the operating system on which the product is used) can be installed without retroactive effect.

Practice 8

Security guidelines - defines requirements for the content of the user documentation. For example, it requires that information is provided on the necessary measures for hardening the system and what must be observed when decommissioning the device.