Two Major Challenges in Meeting the IEC 62443-4-1 Standard for Industrial Automation and IoT Devices

The International Electrotechnical Commission (IEC) does not have a set of standards specifically created for the security of the Internet of Things (IoT). However, it has a series of cybersecurity standards for industrial automation and control systems.

IEC lays out rules designed to support the development and deployment of secure industrial automation and control systems (IACS). These include requirements for secure development lifecycles, coding security, and patch management.

Not many organizations may breeze through complying with these standards, though. Difficulties will likely emerge. Some organizations operate processes with inherent security weaknesses that make compliance challenging.

What is IEC 62443-4-1 

IEC 62443-4-1 is the first subsection of part 4 of the IEC 62443 international series of standards. It focuses on the development and maintenance of secure products. It details the requirements for building secure IACS products and components as it provides a specific definition for a secure development lifecycle (SDL).

The standards under IEC 62443-4-1 cover the full lifecycle of products, from design to product end-of-life. It defines or clarifies the parameters of secure design, secure implementation, security verification and validation, the management of product defects, firmware patching, and product end-of-life (EOL) or retirement from the market. It also includes guidelines on secure coding.

The requirements set in IEC 62443-4-1 are applicable to new or currently used processes in the development, maintenance, and retirement of hardware and software, including the firmware used in IoT and other small devices. Following these requirements is the responsibility of product developers and maintainers.

Challenges in compliance

Product developers and maintainers are likely to encounter compliance hurdles mainly because of two reasons: the absence of on-device security and the black box effect. These are mostly applicable to IoT devices and small components used in process automation and system controls.

Lack of on-device security

The overwhelming majority of IACS and IoT products are designed to serve specific purposes. As such, they are not equipped with the hardware present in devices built to have significant memory storage and processing power. Their internal storage, RAM, and processing chip are limited, which makes it impossible to install full-fledged security systems in them.

It is not possible to install in IACS devices advanced security solutions such as endpoint detection and response (EDR) and extended detection response (XDR). In-code solutions like runtime application self-protection (RASP) are also impossible to implement with existing technologies.

These result in the difficulty or complete inability to undertake crucial cybersecurity mechanisms such as the automation of security policies for all processes, the sandboxing and monitoring of suspicious processes, and the generation of alerts during important events like the surge in resource consumption that happens during a DoS or DDoS attack. Additionally, it is not possible to harden existing processes for user authorization and authentication.

The absence of on-device security systems is a major drawback in the development and deployment of secure industrial automation and control systems as well as IoT and small devices. To secure them or at least have a semblance of security efforts, IACS and IoT makers, and maintainers rely on firmware patching. They send out software updates for their devices whenever threats or attacks are identified.

Patching is not fast enough to address the emergence of new cyber attacks, especially with the rapidly evolving nature of cyber threats. Threat actors quickly find new vulnerabilities and come up with creative ways to compromise networks and devices. Before a security patch is developed and sent to devices, a security compromise will have already taken place.

Black box effect

The black box effect is a setup wherein an artificial intelligence system or program submits useful information without divulging details about how it came up with the information it submitted. It does not provide explanations or elaborations regarding the results or conclusions it submits. In other words, there is the information submitted but the recipients do not have the means to dig deep into the processes that went through to produce the information.

This is what happens in the current setup between the device and device makers/maintainers. The latter usually do not have the means to look into the performance of their products, the operational problems encountered, as well as software defects. They may have the means to know if an error took place, but they do not have the ability to learn how the error happened. They have no means to know how their devices were used to arrive at a problem or glitch.

If there is any information available, this is usually insufficient or siloed. The data is likely kept in some form that is not readily usable for diagnostics and debugging. As such, device makers have a hard time understanding the nature of the problems in their devices and coming up with the appropriate solutions.

Specifically, it is difficult to monitor network activity and IP addresses. There are no audit logs of security events in different endpoints and platforms. There is usually no way of detecting unauthenticated or malicious activity and attempts to execute anomalous software. There are no viable mechanisms to identify failed login attempts and have these automatically reported. Also, it is difficult to monitor all system resource use to determine cases of overloads and malfunctions. Moreover, there is not enough memory capacity to store security audit data and meet the requirements for IEC 62443 compliance.

Addressing the challenges

The problems discussed above are not without solutions. It is possible to comply with IEC 62443 requirements by using a security and observability platform that facilitates the establishment and streamlining of processes to achieve a secure development lifecycle.

A deterministic security solution embedded in the IACS or IoT device can provide runtime protection to address known and yet-to-be-profiled threats. This expands security visibility into connected devices that are not capable of running their own security applications. An AI-driven observability platform can gather relevant information from IACS and IoT devices to centralize anomaly detection and deliver operational intelligence in real-time.

An effective observability platform designed with deterministic security functions compensates for the lack of on-device security and the difficulty to obtain information about device use, glitches, defects, and attacks. It empowers IACS and IoT device makers and maintenance teams to achieve IEC 62443-4-1 compliance and offer customers products that are secure and less likely to cause cybersecurity problems.