Implementation of The NOA Concept in Process Technology: Security by Design Is Mandatory
Implementation of The NOA Concept in Process Technology: Security by Design Is Mandatory
Implementation of The NOA Concept in Process Technology: Security by Design Is Mandatory
Every operator wants to be able to use the data from existing systems for new technologies
and benefit from the added value of cloud-based evaluations. The NAMUR NOA concept
explains how this is possible without changing systems completely. A key element is that the
data diode should collect the important data for the cloud applications and continue to ensure
the security of the system. To ensure that this is possible, the devices that map the
functionality of the data diode must be developed in accordance with security directives such
as IEC 62443 (lead image).
Lead Image
However, the described concept is only advantageous to the operator if data can be
accessed safely and without having an impact. The approach must also be able to be
integrated into the Information Safety Management System (ISMS) that is part of ISO 27000
as already stipulated in the IT Security Act for critical infrastructures. Such a system is often
already implemented in non-critical systems to ensure safe operation. NAMUR has worked in
cooperation with the German Electrical and Electronic Manufacturers' Association (ZVEI) to
develop new working groups that focus on IT security and the implementation of data diodes
in actual hardware. When it comes to the automation of systems, there are various directives
and standards in which the current technical standard of IT security is defined on different
levels. The basic IT security stipulated by the German Federal Office for Information Security
(BSI) and standard IEC 62443 "IT Security of Industrial Automation Systems" are specified
as general process models.
The IEC 62443 series of standards covers the general security standard for industrial
automation systems. This series of standards is made up of 13 parts in which the process
security requirements, functional measures, and state-of-the-art are stipulated (Fig. 3).
According to NOA, the main parts are:
IEC 62443 Part 2-1 – Security Management System Requirements for Operators of
Industrial Automation Systems
IEC 62443 Part 2-4 – IT Security Program Requirements for Service Providers of
Industrial Automation Systems
IEC 62443 Part 3-3 – System Requirements for IT Security and Security Level of
Industrial Automation Systems
IEC 62443 Part 4-1 – Life Cycle Requirements for Safe Product Development of
Industrial Automation Systems
IEC 62443 Part 4-2 – Technical IT Security Requirements for Automation System
Components.
When developing a device with data diode functionality it is sensible to implement a security
by design approach for the hardware and software. The necessary security processes and
functional measures for device manufacturers, system integrators, and operators of the
machine and systems can be implemented.
IEC 62443-4-1 describes the product development process for automation devices. The main
element represents a process that can be used to safely determine whether all of the security
requirements have been implemented and checked. This process is completed by other
security implementation features. These, for example, include a threat analysis based on the
security context, i.e. the operational strategy of the product, the "Defence in Depth" concept,
and security vulnerability management, which nowadays is generally implemented by a
Product Security Incident Response Team (PSRIT).
IEC 62443-4-2 defines the technical requirements for industrial automation devices. Based
on the security threat, a security level (SL) of 0 to 4 is determined and adjusted in
accordance with the capabilities of the attacker (Fig. 4). Different functional requirements are
set out for the products based on the attack vector and security level (Fig. 5). However, the
implementation of functional measures must not be considered in isolation. An SL can only
be achieved if the framework conditions stipulated in Part 4-1 regarding a secure
development process have been met. The security level of a device/system can therefore
only be met by combining processes and functional measures.
The functional security requirements regarding the capabilities of automation systems are
detailed in IEC 62443-3-3. Here, an evaluation determines to what extent the components
comply with the operator's functional requirements. This part of the standard also determines
the interface between the system integrator and device manufacturer. On this basis, devices
required for implementing the security level defined by the operator can be selected.
Figure 5 - Definition of the functional measures for the security level as per IEC 62443-4-2
Part 2-4 and 2-1: Requirements for system integrators and operators
IEC 62443-2-4 specifies the requirements on the capabilities in terms of the IT security of
service providers for industrial automation systems. It clarifies the interface between the
operator and system integrator, as well as the core processes during integration,
commissioning, and maintenance. This, for example, includes the architecture and
configuration of the automation solution, the management of user accounts, processing of
events, and patch management including backing up and restoring the automation solution.
IEC 62443-2-1 covers the requirements regarding an IT security program for the operator. A
table specifies the requirements that should basically enable the transition of the ISO 27000
to ISMS. This part of the standard also determines the security level of the system based on
a threat analysis.
Recommendation – Start with available security routers