ISA 62443-4-1 Standards - Secure Development Lifecycle (SDLC) Requirements

The risks associated with unsecured ICS and SCADA systems are unique as we shift from isolated, insecure, air-gapped systems, to a more interconnected and open infrastructure, which leaves systems exposed to various internal and external threat actors. The numerous security challenges linked to these systems must be overcome to prevent severe incidents at plants that could impact human life, assets, production, the environment and an asset owner’s reputation.

In order to combat these threats, businesses must consider the numerous security risks that are associated with their control systems including engineering workstations, historians, controllers and communication protocol vulnerabilities. Unfortunately, the security of these systems is often not addressed at the early phase of product lifecycle. Therefore, without considering security at the outset of product development, the reliability and safety of manufacturing and industrial facilities could be jeopardized. Moreover the cost of remediation activities becomes too high and complex once system is in production.

The draft of ISA 62443-4-1 (Security for industrial automation and control systems – Product Development Requirements) has been approved and submitted to the IEC for final confirmation. The standard defines the development process to ensure that security is built into the product design, which of course provides the required level of assurance and confidence for both suppliers and end users.

It is worth to mention that the standards applies to both hardware and software development processes, and its scope covers both new and existing products although some of the requirements will be hard to achieve considering the nature (insecure by design) of some of the control systems (e.g. legacy systems).

The ISA 62443-4-1 addresses various testing areas, for instance the Static Code Analysis (SOA) Section 8.2.1 (c) states that this testing shall be done if testing exists for that language and/or if the software has changed. The third-party software is also addressed in a separate section.

Section 9.4 covers vulnerability testing covers fuzz testing and network traffic load testing and capacity testing, attack surface analysis, and black box known vulnerability scanning. For software composition analysis on all binary executable, the following types of issues at a minimum:

  1. known vulnerabilities in the product software components,
  2. linking to vulnerable libraries,
  3. security rule violations, and
  4. compiler settings that may lead to vulnerabilities.

Industrial automation and control systems (IACS) security standards are emerging, and increasingly adopted by the industry.

Considering an ICS/SCADA vulnerability assessment? Applied Risk’s ICS/SCADA Security Assessment and Penetration Testing services could be the perspective — and the solution you need.