The ISA/IEC 62443 series is a wide-ranging collection of multi-industry standards for the secure development of Industrial Automation and Control Systems (IACS). It defines a set cybersecurity protection methods and techniques to defend industrial networks against cybersecurity threats. It categorizes these techniques to apply to all stakeholders including manufacturers, asset owners and suppliers.
There are four primary ISA/IEC 62443 sections:
The diagram shows the interaction between these different sections.
The fourth in the ISA/IEC 62443 series, ISA/IEC 62443-4:2018, specifies the requirements for the secure development of components products used in the make-up of IACS. Examples of devices that might be compliant include PLCs, HMI displays, three-term controllers, and components of Distributed control systems (DCS), as well as more obvious networking components such as ethernet switches. ISA/IEC 62443-4 defines a secure development life cycle applicable to these products and provides guidance on how to meet them.
ISA/IEC 62443-4-1 is the subsection of the ISA/IEC 62443 series primary focus for embedded system developers.
The development life-cycle phases include security requirements definition, secure design, secure implementation (including coding guidelines), verification and validation, defect management, patch management and product end-of-life. These activities and tasks apply to new or existing processes for developing, maintaining, and retiring hardware, software, or firmware.
The key practices identified by ISA/IEC 62443-4-1 are:
Although ISA/IEC 62443 has implications for Information Technology (IT) and Operational Technology (OT), the primary focus here is on embedded software applications which will generally be concerned with the latter.
The standard classifies the technical requirements for products developed in accordance with ISA/IEC 62443-4-2 (and the systems they contribute to) are assigned Security Levels (SL) according to their resistance against different attack types. ISA/IEC 62443-1-1 states that these levels are to be assigned to each requirement, rather than to complete products.
The levels are:
Security requirements and security levels are strongly related. The more demanding the security levels, the more demanding the security requirements will be.
The ISA/IEC 62443 maturity levels for processes are based on those from the CMMI framework. To fulfill each maturity level for the purposes of ISA/IEC 62443 certification, all process-related requirements must be practiced in their entirety during product development or integration.
The maturity levels are as follows:
There are many international standards for software cybersecurity, and these emerge regularly. This is not a comprehensive list.
Earlier versions of ISA/IEC 64333 were known as ISA 99.
IEC/ISO 27001 is potentially complementary to ISA/IEC 62443. ISA/IEC 62443 focuses on IACS systems and system components – that is, products. IEC/ISO 27001 provides guidance on the implementation of an Information Security Management System – that is, organizations.
It is therefore feasible for a company to apply IEC/ISO 27001 to its processes, and ISA/IEC 62443 to its products.
Originally developed in the 1990s as part of the Purdue Enterprise Reference Architecture (PERA), the Perdue model is a reference data flow model for Computer-Integrated Manufacturing (CIM).
ISA 99 featured the Purdue Model. After the name change, the first edition of ISA/IEC 62443-1-1 also included a diagram based upon it. However, subsequent revisions to the standard have instead adopted the more flexible concept of zones and conduits. ISA/IEC 62443-3-2 defines them in some detail. The PERA hierarchical arrangement of domains is therefore no longer relevant.
CLC/TS 50701 is the cybersecurity standard for railways, announced in June 2021 and developed by the CLC/TC 9X technical body. It provides guidance and specifications on the management of cybersecurity in the context of the EN 50126-1 RAMS life cycle process. CLC/TS 50701 describes security models, concepts, and risk assessment processes based on or derived from IEC 62443 series standards, which many rail projects have referenced in the interim.
The “fourth industrial revolution” concerns the seismic impact that the addition of cyber-physical systems, the Internet of Things, and the Internet of Systems has on the way we live, work and relate to each other. Such changes clearly have implications for industrial control systems and manufacturing processes across a host of sectors. “Industry 4.0” (or Industrie 4.0, or I40) is a prominent example of how industry is addressing the resulting constraints and challenges.
Industrial connectivity and industrial cybersecurity must go hand-in-hand, making ISA/IEC 62443 and Industry 4.0 seem highly complementary. However, there has been some criticism concerning a potential mismatch between the dynamic nature of an IIoT system applying Industry 4.0, and the rigidity of some parts of ISA/IEC 62443. However, the standard is the subject of continuous improvement, and its authors do appear responsive to changing technologies.
ISA/IEC 62443 is not the only cybersecurity framework on offer. For example, NIST Special Publication 800–82 was developed in accordance with the US Federal Information Security Modernization Act (FISMA) of 2014.
Like ISA/IEC 62443, NIST SP 800–82 presents detailed guidance on policies and procedures. The two standards take a largely similar view, and indeed NIST SP 800–82 references ISA/IEC 62443 extensively. However, there are subtle differences to be aware of as highlighted by some of those references. For example, NIST 800-82 rev 2 states “Organizations may also wish to consult ISA-62443-2-1 … which describes another view of the elements contained in a cybersecurity management system …”
The ideal framework for a particular organization is likely to depend on the industry and its associated regulatory drivers. The NIST standards are usually obligatory for the US public sector
LDRA’s expertise is mainly applicable to the ISA/IEC 62443-4-1, although other parts of the standard do impact on the principles promoted by it.
This V-model illustrates the IEC 62443-4-1 interpretation of the Secure Software Development Life Cycle (SSDLC). This proactive approach integrates security related best practices into the traditional Software Development Life Cycle (SDLC) that will be familiar to developers in the functional safety domain. It shows how the use of automated and integrated tools can help to achieve compliance. Verification and validation play an important role in the process, and several testing techniques are applicable to the standard’s recommended requirement-based testing approach.
LDRA’s proven tooling leveraged for Static Application Security Test (SAST, or static analysis), white box Dynamic Analysis Software Test (DAST, or dynamic analysis), and requirements traceability provide a sound foundation for the cohesive and integrated approach to application security.
7.2 discusses the principles of secure design. The LDRA tool suite supports the development of secure source code, which is an important component of a defence-in-depth approach. In particular, secure coding techniques have a key part to play for any code accessing data assets, examples of which are listed in §7.2.2.
8.3.1a states that a mechanism is required to allow the “identification of security requirements (see Clause 6) that were not adequately addressed by the implementation”. The LDRA tool suite provides appropriate facilities to test the measures implemented in accordance with those requirements.
Achieving a requirements format that lends itself to bidirectional traceability will ease compliance with the standard. Bigger projects (perhaps with contributors in different locations) are likely to benefit from an application life cycle management tool. Smaller projects can cope with carefully worded spreadsheet or word processor documents, written to facilitate links up and down the development process model.
The TBmanager component of the LDRA tool suite helps by automatically maintaining the connections between the requirements, development, and testing artefacts and activities. It allows requirements-based testing to be used in conjunction with structural (code) coverage analysis to highlight any parts of the code base that do not trace to requirements, and therefore present a potential threat. In addition, TBmanager can help in achieving the process compliance in accordance with the requirements of ISA/IEC 62443-4-1.
Most projects suffer from unexpected changes of requirements, or failed tests that demand a rethink. Both can cause a project management headache. The TBmanager component of the LDRA tool suite provides an impact analysis facility to help address such issues in a time-effective manner.
8.4 requires developers to incorporate secure coding standards and periodically review them. There are a number of potential sources of secure coding standards, and every opportunity to tune them to the needs of a particular development organization.
The CERT organization offers coding standards for several high-level languages designed for the development of safe, reliable and secure systems that adopts an application centric approach to the detection of issues. MISRA offers another option that is equally applicable where cybersecurity is a must, despite a common misconception they design their standards specifically for safety-related projects. Other options include CWE, which strictly speaking is a list of weakness types, rather than a standard.
The TBvision component of the LDRA tool suite offers support for a range of coding standards, including these examples. It achieves coverage of very high percentage of the rules dictated by each standard, and user-defined rule sets are also supported. The TBexclude module provides for the efficient management of justified rule violations.
SAST tools vary in terms of their ability to identify the more subtle nuances of standard violations, but the more sophisticated implementations can seem slower because of the additional processing required to achieve that. A sensible approach is to choose tools with the option to run in “lightweight” mode initially, and to apply more complete analysis as development progresses.
The SAST and DAST techniques provided by the LDRA tool suite support the “shift left” philosophy of the standard by supporting security testing throughout the development life cycle.
The automated calculation of complexity metrics provided by the TBvision component of the LDRA tool suite helps developers to manage code complexity. Code that is more complex than it needs to be is also more error-prone during development and maintenance.
The TBrun component of the LDRA tool suite demonstrates the correct implementation of defensive mechanisms, and their traceability back to security requirements.
When supplemented by the TBextreme module, TBrun automatically generated robustness test cases, ensuring that the handling of boundary conditions, null pointers, and default conditions are all correct and hence introduce no security vulnerabilities.
The purpose of data coupling analysis and control coupling analysis is to show that the control and data flow of the completed software reflects the intentions of its designers and developers. In a security context, the analyses in combination provide a means to recognize and correct potential security vulnerabilities.
The process involves three steps.
Video: Developing software to be compliant with IEC 62443-4-1
Article: Developing a safe, secure system: SEI CERT C versus MISRA C
Article: Process control cybersecurity gets serious with IEC 61508 and IEC 62443-4-1 in tandem
Webinar on demand: Application of IEC 62443 series for components and IACS
Webinar on demand: Process Control Cybersecurity Gets Serious: IEC 61508 & IEC 62443-4-1 in Tandem
Email: info@ldra.com
EMEA: +44 (0)151 649 9300
USA: +1 (855) 855 5372
INDIA: +91 80 4080 8707