In recent years, there has been an alarming increase in cyberattacks specifically targeting industrial control systems in sectors such as energy, manufacturing, transportation and utilities. According to the Kaspersky report "ICS CERT Predictions for 2024", ransomware is again expected to be the biggest threat to the cyber security of industrial companies this year, alongside malware. According to the report, 18% of ransomware attacks on industrial companies in 2023 led to production or supply disruptions for products such as medical devices, power grids and transportation systems.

To address the growing cyber risks, the International Society of Automation (ISA) and the International Electrotechnical Commission (IEC) developed the IEC 62443 series of standards for securing Industrial Automation and Control Systems (IACS) in 2018. It provides a comprehensive framework for implementing cyber protection measures in all areas of IACS, including people, processes and technology(Figure 1). Without automated tools, it is difficult to maintain comprehensive system inventories and test all possible attack surfaces.

In terms of software testing, the series of standards emphasizes the need for automated security testing as it facilitates the continuous validation of the cyber integrity of IACS applications. Automated security testing is essential for a thorough review of security requirements, regression testing for vulnerabilities and maintaining IEC 62443 compliance as products evolve.

The challenge of software complexity

In achieving and maintaining full compliance, the complexity of the software used in modern IACS environments is proving to be a particular hurdle, as IACS are increasingly based on heterogeneous software components from different vendors and integrators, often developed using different programming languages, frameworks and tool chains. From real-time operating systems and PLCs to SCADA (Supervisory Control and Data Acquisition) systems, distributed control systems, safety-related systems - each of these elements represents a potential attack surface that needs to be protected. This complexity is amplified by the networked nature of IACS, with plant systems integrated across functional boundaries and geographical locations, and risks associated with every application, middleware component and infrastructure layer that depends on each other. Other amplifiers are artificial intelligence and cloud connectivity. It is virtually impossible to keep up with the daily flood of newly discovered vulnerabilities using only manual processes. Consistently applying security patches and verifying that vulnerabilities have actually been fixed requires continuous automated security testing.

The author: Ricardo Camacho is Director of Safety & Security Compliance at Parasoft. © Parasoft

In addition to mastering the complexity of the IACS software used, companies must also enforce security at every stage of the software development cycle in accordance with the requirements of IEC 62443-4-1. Each phase requires robust processes and granular traceability that are difficult to achieve cost-effectively without automation. In addition, the IACS software is constantly evolving through updates, integration of new components and migration initiatives. This requires extensive regression testing to continuously validate the cumulative security of these dynamic, multi-layered applications.

Reduction of complexity

To cope with this software complexity, highly automated test procedures must be used across the entire SDLC. Some of these security testing procedures can help identify and fix large-scale vulnerabilities as the IACS software evolves. These are:

Figure 2: With the help of static analysis (SAST), vulnerabilities can be identified and eliminated on a large scale at an early stage of the software development lifecycle. © Parasoft

• Static analysis: Static Application Security Testing (SAST) analyzes source code, bytecode, binaries and build artifacts to identify insecure programming patterns such as SQL injection, buffer overflows, cryptographic errors and much more at an early stage of the SDLC.
• Unit tests: Embedded directly in the developers' workflows, they help to check whether the implementation code fulfills the security requirements. Unit tests that focus on authentication, data encryption, data decryption, access control, input/output validation, among others, enable fast feedback cycles.
• Integration tests: Automated integration tests can be used to uncover security vulnerabilities resulting from the interaction of multiple components. By simulating realistic runtime conditions, integration tests validate correct security configurations and identify breaks caused by connected software dependencies.
• Requirements-based testing: A central principle of IEC 62443 is to start safety from the initial analysis of requirements. By translating specified security requirements into executable tests, organizations can automatically validate that the system behavior correctly implements the defined security controls.
• Code coverage: The use of code coverage tools shows which parts of the security code have been properly tested and which have not and pose a risk. Coverage metrics such as Modified Condition/Decision Coverage (MC/DC) are best suited for a complete safety check in safety-critical and high-risk software modules (Figure 2).

Robust and secure development processes

In order to comply with IEC 62443 verification methods, IACS companies must apply robust and secure development procedures. These procedures have emerged as best practices:

Figure 3: The process of a TARA method consists of the key steps of project definition, threat identification and risk assessment, defense measures, implementation and validation. © Parasoft

• Continuous code verification: Automating static application testing within developer IDEs and commit workflows enables continuous code review and rapid remediation of security defects.
• Establish coding standards from the start: Developers should follow security rules for areas such as memory management, input validation, authentication, cryptography. To avoid security patterns, the integration of SAST rules that automatically check compliance with these programming standards helps. Basic security should be defined by guidelines and selection criteria.
• Adhere to secure supply chain practices for third-party software: Organizations should implement secure software composition analysis (SCA) to manage and secure the use of open source software components within a larger software application.
  Software Bill of Materials (SBOM): Detailed and updated software inventory lists should be maintained for all product versions to support continuous monitoring and mitigation. SCA and SBOM practices need to be largely automated to analyze the vast amount of external software.
• Continuous testing: In addition to automated code analysis, IEC 62443 mandates rigorous security testing at all stages of the SDLC and after every change or update. Organizations should equip DevOps pipelines to continuously perform automated security testing as part of their CI/CD workflows.
• Engage suppliers: Consistent with the software supply chain risk management controls outlined in IEC 62443, IACS owners should validate that all third-party vendors are able to document compliance with secure development processes. Without a rigorous review of security practices across the supplier ecosystem, cyber resilience is at risk.
• Adopt a TARA strategy: Developers should apply a Threat Assessment & Remediation Analysis (TARA) as it is strategically aligned with IEC 62443 guidelines (Figure 3). By monitoring new vulnerability reports and updated guidance from sources such as ICS-CERT, NVD and CWE and automatically correlating them with an updated SBOM, organizations can ensure full traceability of their cyber risks and take appropriate remediation actions. Interactive Application Security Testing (IAST) can also provide insights into real-world attacks across the entire IACS attack surface during runtime. (ag)