The IEC 62443 family of standards is an old acquaintance to most security managers for industrial systems. For more than ten years, it has literally been considered THE standard for industrial cybersecurity. The standard is considered a so-called "horizontal standard". It thus forms a sector-agnostic baseline for industrial cybersecurity, on which sector-specific requirements are (or can be) added by industry experts.
[Note: The IEC 62443 standard refers to IACS (Industrial Automation and Control Systems) for industrial IT or network control technology. For the sake of simplicity, we use the internationally common term of Operational Technology or OT in this article].
Getting the focus right
For utilities, Chapters 3-1 to 3-3, which deal with the system security of their Critical Infrastructure, are of particular importance:
- 3-1: Security technologies for industrial automation and control systems (IACS)
- 3-2: Security risk assessment and system design
- 3-3: System security requirements and security levels
Chapter 3-1 can be considered sort of outdated, as it was written in 2009. Chapters 3-2 and 3-3, however, remain up to date with their publication in 2020 and 2013, respectively. Both chapters focus more on conceptual requirements which - apart from some detailed wording in the small print - remain technology-neutral.
The two chapters thus form the baseline of an end-to-end OT security strategy that energy utilities should follow to protect their OT networks effectively and reliably against cyberattacks and disruptions.
Fig. 1: After the initial implementation of the standard, both the OT and the threat landscape continue to evolve, creating an outdated level of security over time that must be continuously reviewed and brought up to date.
The decisive factor in applying IEC 62443 is to see its implementation not as a one-off project, but as a continuous process. Cybersecurity has always been a sprint and a marathon at the same time. The one-time implementation of the IEC 62443 standard is not the end goal for OT security. It is the beginning of a continuous reassessment and improvement of the risk situation and system efficiency (Fig. 1). In this respect, OT security according to IEC 62443 follows a classic PDCA cycle (Plan, Do, Check, Act), which is also found in the ISO 9001 or ISO 27001 ff standards.
IEC62443-3-2 risk analysis: creating visibility and knowledge
It makes little sense to try to implement the technical requirements defined in chapter IEC 62443-3-3 without first having performed a thorough security risk assessment according to chapter IEC 62443-3-2 "Security risk assessment for system design". Otherwise, a risky patchwork results without clear focus and consideration of the security risks that really exist.
The ultimate goal of the security risk assessment is to gain a complete understanding of the OT structure and potential risks. In our Rhebo Industrial Security Assessments, which we perform as standard before integrating our OT intrusion detection system with our customers, many security managers are surprised by the vulnerabilities and communication processes prevalent in their OT. It is usually the first time they open the black box of their OT and get an idea of the inner workings.
An OT monitoring already supports significantly in this first step to collect all important information for the risk assessment and subsequent decision making:
- Network map with all assets (hardware and software) (Fig. 2),
- Information and properties of the assets (Fig. 2),
- Existing vulnerabilities (e.g., due to outdated firmware, OS),
- Existing security risks (e.g., due to connections to and from the Internet, unwanted connections between assets, clear-text passwords, outdated or obsolete protocols),
- anomalies in communications,
- structure of communication paths,
- misconfigurations.
Fig. 2: Network map with detailed information and connection overview in Rhebo Industrial Protector
IEC62443-3-3 Security system: ensure basic protection and continuous verification
With the knowledge from the risk assessment, the OT security system can be developed in a targeted and focused manner. The IEC62443-3-3 chapter provides a large number of recommendations for this, which are grouped into 7 foundational requirements (FR) with a total of 51 standard requirements (SR).
It is recommended that all SRs be taken into account. However, practice teaches that SRs sometimes cannot be implemented or can only be implemented incompletely due to operational requirements (e.g., for real-time processes or occupational health and safety mechanisms) or infrastructural circumstances (e.g., legacy systems and certain dependencies). In addition, very few OT components are designed with cybersecurity in mind. They are usually "insecure by design." Given the 15-25 year life cycles of industrial infrastructures, this will not change in the foreseeable future. And during this period, attack techniques and cyber threats grow and change many times over.
In short, residual risks - often quite significant - remain (Fig. 3).
Recognizing that there is no such thing as 100 percent security in cybersecurity, the National Institute of Standards and Technology (NIST) and the German Federal Office for Information Security (BSI), among others, have long advocated defense-in-depth. This approach »involves layering heterogeneous security technologies in the common attack vectors to ensure that attacks missed by one technology are caught by another«[1].
Fig. 3: There is no such thing as 100% security in OT, which is why security officers should always be aware of security-related communication in the OT network, as seen here with the Rhebo Industrial Protector inbox.
OT monitoring with anomaly detection constitutes precisely this second level of defense against threats. It significantly supports the implementation, improvement and effectiveness of the basic requirements. Fig. 4 from the white paper "IEC 62443 requirements in today's risk landscape - Findings & insights from OT monitoring projects" analyzes this exemplarily for SR 1 to 3.
Fig. 4: OT monitoring and anomaly detection provide significant support in ensuring OT visibility and the effectiveness of implemented mitigation measures.
IEC 62443 is on the way to becoming a legal requirement
Some signs currently point in the direction that the standard will play an even greater, legally relevant role in the EU in the future, as cybersecurity expert Sarah Fluchs recently revealed. As part of the standard harmonization process for the upcoming Cyber Resilience Act (CRA), the CLC/TC 65X Technical Committee has been tasked with developing proposals on which standards should be used to implement the legislation. As Fluchs writes, TC 65X is the IEC committee TC 65's link to the European standardization institution CENELEC. “And TC 65 is responsible for an international series of standards that you have probably heard of: ISA/IEC 62443.”.[2]
The CRA is aimed primarily at all manufacturing companies that want to sell components with digital interfaces or applications on the European market, i.e., require the CE label for sales. Therefore, the focus will be on chapters 4-1 "Secure product development lifecycle requirements" and 4-2 "Technical security requirements for IACS components", which explicitly define cybersecurity requirements for IACS components.
NIS2 has already adopted some fundamental aspects from IEC 62443. With its application within the framework of the CRA, the standard will thus become mandatory in macroeconomic terms for every company that sells industrially deployed hardware or software with a security or central system function. This will also have implications for the companies that use such products in their networks, as we highlighted in Part 1 of our NIS 2 blog.
[1] Also see NIST SP 800-171, NIST SP 800-172, NISTIR 8183
[2] https://fluchsfriction.medium.com/what-cybersecurity-standards-will-products-in-the-eu-soon-have-to-meet-590854ba3c8c
