Satisfying the Security Requirements of IEC 62443 With Test Automation

Introduction to IEC 62443

IEC 62443 is an international standard that defines requirements and processes for implementing and maintaining secure industrial automation and control systems (IACS). These standards set best practices for security and provide a way to assess the level of security.

The standard outlines a secure development life cycle (SDL) that covers aspects such as secure coding, testing, deployment, maintenance, and disposal. Key to this is the definition of a security requirements specification, which identifies and prioritizes the security risks along with mitigation strategies to be used in the product or application throughout its life cycle.

A key concept of the standard is the use of threat modeling to identify and analyze potential threats to a product or system based on its architecture, components, interfaces, data flows, and functions. Threat modeling helps evaluate the impact and likelihood of each threat and prioritize them according to their severity. This is an ongoing activity since the threat landscape changes over time, especially for IACS products that have lifespans of decades.

Not all IACS products require the same level of security, which defines how the system responds to different classes of attacks. These range from no requirements and unintentional misuse to sophisticated attackers with unlimited resources. Products are expected to be broken up into security zones if security levels differ among components or subsystems.

IEC 62443 also provides guidance on how to build more secure devices and applications, such as the use of secure by design, reducing the attack surface, defense in depth, and so on.

Key Practices of IEC 62443

Here is a summary of the key practices identified by ISA/IEC 62443 Series of Standards.

Cybersecurity Management System

A robust security program requires establishing and maintaining a security program that defines the roles, responsibilities, policies, procedures, and resources for ensuring the cybersecurity of IACS products and solutions. This practice effectively encompasses all of the following practices as the overarching key practice.

Security Risk Assessments

Risk assessment is a crucial part of developing IACS systems for both safety and security. This is an ongoing process that involves:

• Defining the scope and boundaries of the system under consideration.
• Identifying and analyzing threats and vulnerabilities.
• Prioritizing risks based on potential consequences.

Risk is a factor determining the likelihood of an event happening and the consequences and impact of its occurrence. The deliverables of this practice include:

• Comprehensive list of critical assets
• Identification of dependencies
• Determination of critical risks to the operation and safety of these processes
• Appropriate responses to these risks

Specification of Security Requirements

To build in security from the beginning, defining the security requirements is needed for the entire product life cycle, from design, development, support, operation, maintenance, and disposal. It also includes defining the security levels that specify the degree of protection required for each function or component of a product.

Secure by Design

A secure product must be designed to be secure from the beginning. This means applying security design principles, such as defense in depth, throughout the product development life cycle to reduce the attack surface and prevent unauthorized access to or modification of the product or application. It also includes conducting secure coding standard reviews, testing, and validation to ensure that the code meets the security requirements.

Secure Implementation

Secure by design implies implementing secure coding standards in all phases of the product development life cycle to ensure that the code meets the security requirements. This also includes conducting verification and validation testing to verify that the code functions as intended under various scenarios and conditions.

Security Verification & Validation Testing

Security needs to be tested. Conducting formal or informal tests to verify security requirements are met is crucial. This also includes conducting defect management activities to identify, report, track, resolve, and prevent defects in an IACS product or solution.

Management of Security-Related Issues

Security issues are inevitable. Proper management is essential for any incidents related to cybersecurity that arise during or after the life cycle of a product. This also includes conducting patch management activities to apply updates or fixes to the product as needed. Additionally, managing product end-of-life activities needs to ensure that products are decommissioned safely and securely when no longer needed.

Security Update Management

The security of a product or application is always in flux. Managing any updates or fixes to deployed products is required. Although traditionally updates to IACS products are few and far between, this needs to change. Modern, secure products need patch management to ensure ongoing compliance. Additionally, the software supply chain must be monitored for new vulnerabilities, so dependencies that your product uses must also be updated and patched, for example OpenSSL or Log4J vulnerabilities.

The parts where test automation plays the most important role are secure implementation and security verification and validation practices. Therefore, this post will concentrate on these key practices.

IEC 62443 Practice 4: Secure Implementation

In the standard, sections 8.3.1 and 8.4.1 specifically call out the need for static code analysis, code reviews, and the implementation of secure coding standards. Another critical aspect of the requirements is traceability of security requirements to implementation and tests.

Security Implementation Reviews

Section 8.3.1 outlines the requirements for security reviews on product implementation. These specifically mention the need for coding standards, static code analysis, and traceability.

Section 8.3.1:

A process shall be employed to ensure that implementation reviews are performed for identifying, characterizing and tracking to closure security-related issues associated with the implementation of the secure design including…

b) identification of secure coding standards (see 8.4) that were not followed (for example, use of banned functions or failure to apply principle of least privilege);

c) Static Code Analysis (SCA) for source code to determine security coding errors such as buffer overflows, null pointer dereferencing, etc. using the secure coding standard for the supported programming language. SCA shall be done using a tool if one is available for the language used. In addition, static code analysis shall be done on all source code changes including new source code.

d) review of the implementation and its traceability to the security capabilities defined to support the security design…

Section 8.4.1 specifics about security coding standards and the recommendation for automation via static analysis tools:

Section 8.4.1:

The implementation processes shall incorporate security coding standards that are periodically reviewed and updated and include at a minimum:

a) avoidance of potentially exploitable implementation constructs – implementation design patterns that are known to have security weaknesses;

b) avoidance of banned functions and coding constructs/design patterns – software functions and design patterns that should not be used because they have known security weaknesses;

c) automated tool use and settings (for example, for static analysis tools);

d) secure coding practices;

e) validation of all inputs that cross trust boundary.

f) error handling.

The Role of Static Analysis Tools in Security Implementation Reviews

Static analysis tools are excellent at detecting errors, bugs, vulnerabilities, or other issues that might affect the security or functionality of software. Static analysis can also be used to verify the compliance of the system with certain coding standards or requirements.

Specifically, static analysis tools are particularly useful in helping developers comply with IEC 62433 by identifying potential security flaws or weaknesses in the code before attackers exploit them. In addition, static analysis tools help achieve compliance with relevant standards or regulations that require secure coding practices, including secure coding standards.

Coding Errors, Software Weaknesses, & Vulnerabilities

Here are some of the capabilities and advantages of using advanced static analysis tools like Parasoft C/C++test for securing IACS software.

• Improved code quality. Static analysis tools enhance overall code quality by identifying coding best practices and ensuring adherence to standards. These tools pinpoint areas of inefficient, difficult-to-maintain, or error-prone code, which often lead to weaknesses that can be exploited if exposed to attackers.
• Early identification of vulnerabilities. Tools such as Parasoft C/C++test identify security flaws before they propagate in the software development life cycle. Providing detailed information and code execution trace information eases the process of correcting vulnerabilities.
• Accelerate compliance. A static analysis tool along with robust analytics and reporting capabilities reduces the burden of compliance with security standards and regulations in regulated industries. Records of secure coding standard compliance and early vulnerability removal provide evidence of due diligence. In addition, it eases the process of satisfying auditors and regulatory authorities, reducing legal and financial risks.
• Scales easily. Advanced static analysis tools are designed to be scalable and adaptable to diverse software projects and company sizes. They also work where the developer works in their development environment, integrating seamlessly into IDEs and processes for both small applications and large-scale enterprise systems. Static analysis tools also need to work with various programming languages to be applicable across an organization.
• No test cases or execution. Static analysis tools, by their very nature, work on source and binary code. Execution or even a complete system isn’t required. This makes the tools especially well-suited for early-stage security assessments, accelerating the identification and resolution of vulnerabilities.

Secure Coding Standards

Static analysis tools, also called static application security testing (SAST) tools, use code details and structure to enforce adherence to secure coding standards and guidelines. The built-in checkers are designed to detect code that doesn’t comply with well-known standards such as the SEI CERT C and C++ standards. These guidelines prevent C and C++ programmers from using language constructs that are known to create software weaknesses that lead to vulnerabilities. They also instill good programming practices that prevent these weaknesses from seeping into the code base if regular compliance checking is performed.

The IEC 62443 standard is explicit about static analysis tool usage and secure coding standards. As such, it’s imperative that these tools work with established processes, development, and build/test environments.

IEC 62443 Practice 5: Security Verification and Validation Testing

The standard is also quite explicit about the types and thoroughness of testing required to verify and validate security. The best practical way to implement these requirements is through software test automation.

Following are the relevant sections from IEC-62443.

Section 9.2.1: Security Requirement Testing

A process shall be employed for verifying that the product security functions meet the security requirements and that the product handles error scenarios and invalid input correctly. Types of testing shall include:

a) functional testing of security requirements;

b) performance and scalability testing; and

c) boundary/edge condition, stress and malformed or unexpected input tests not specifically targeted at security.

Section 9.4.1: Vulnerability Testing

A process shall be employed for performing tests that focus on identifying and characterizing potential security vulnerabilities in the product. Known vulnerability testing shall be based upon, at a minimum, recent contents of an established, industry-recognized, public source for known vulnerabilities. Testing shall include:

a) abuse case or malformed or unexpected input testing focused on uncovering security issues. This shall include manual or automated abuse case testing and specialized types of abuse case testing on all external interfaces and protocols for which tools exist

…

d) dynamic runtime resource management testing that detects flaws not visible under static code analysis, including but not limited to denial-of-service conditions due to failing to release runtime handles, memory leaks and accesses made to shared memory without authentication. This testing shall be applied if such tools are available.

The Role of Software Test Automation Tools in Security Verification & Validation

To meet product deadlines and achieve an acceptable level of security, it is required to automate the testing process as much as possible. Modern software test automation tools accelerate these processes by removing as much of the manual aspects as possible, leveraging AI and machine learning where possible, and reporting and analytics to help focus testing where it’s needed the most. The following addresses the requirements for verification and validation from the standard and how test automation helps in each case.

Security Functional Testing

A benefit of automated functional testing is the capability of running tests at any time, day or night, without the need to have a person continually involved. Automated tests also run faster than manual tests. They follow the testing plan exactly, avoiding potential human errors such as using incorrect test data or omitting parts of the test. An added benefit is that automated testing gives the QA team more time to focus on urgent edge cases and write test scenarios for new modules and software systems.

Functional testing also doesn’t make any assumptions about system structure. It tests only what comprises the system and what makes it work. In terms of security, functional testing ensures that the developers have met all the product’s security requirements.

Performance & Scalability Testing

Performance testing assesses how an application behaves under specific conditions and analyzes the results so you can identify and address any bottlenecks or blockages that prevent smooth operation. This is important for security since attacks can attempt to block proper operation through denial-of-service attacks, for example.

With a load and performance testing strategy, your applications can be better prepared for unexpected demand. Load and performance testing tools ensure your system handles sudden bursts in traffic and delivers a superior user experience. These tests create extreme loads to find any faults and ensure your application can take the heat. Test automation makes it easier and faster to run a combination of performance testing steps in parallel.

Boundary/Edge Conditions, Malformed Input, or Abuse Cases

Boundary or edge test conditions are those that are well beyond the usual input or environmental conditions an IACS product would expect. However, these test cases are still within the theoretical bounds of system inputs. In terms of user input, edge cases are those where inputs are very long or may contain special characters. This is how SQL injections are perpetrated on websites, for example. In terms of IACS systems, this might also include extreme sensor inputs, network and interface inputs, and user/HMI access.

Software test automation tools like Parasoft C/C++test can be configured to use boundary and extreme test cases, also known as abuse cases, and even automatically generate test cases based on internal knowledge of software units, for example. These tests can also be added to a regression test suite that can run on a regular basis, automatically.

Dynamic Application Security Testing

Dynamic application security testing (DAST) is another form of security testing like static analysis (SAST), but it works while an application of the system is running. These tools detect runtime vulnerabilities in executing code. They have a high degree of precision since detected vulnerabilities are real, but they can only detect vulnerabilities in code that is executed and within conditions that are present during testing. IEC 62443 makes it clear that all types of application security testing should be done.

Traceability

Security requirements in IACS systems need to be verified and validated. This requires that there be traceability between the requirement, the implementation (usually source code), and the tests that validate it. Maintaining these links manually is likely impossible, so automation plays a key role in keeping traceability precise and up to date. Compliance records and documentation can also be automated as needed.

Automating Bidirectional Traceability

Application life cycle management tools include requirements management capabilities that are mature and tend to be the hub for traceability, which includes security requirements and threat modeling. Integrated software testing solutions, like those that Parasoft provides, complete the verification and validation of security requirements through automation. Providing automated bidirectional traceability to the executable test case includes the pass or fail result and traces down to the source code that implements the requirement.

Parasoft provides bidirectional traceability from work items to test cases and test results—both displaying traceability reports with Parasoft DTP as well as reporting results back to the requirements management system.

Parasoft integrates with market-leading requirements management and Agile planning systems such as Intland Codebeamer, Polarion from Siemens, Atlassian Jira, CollabNet VersionOne, and TeamForge. Parasoft’s test automation solutions, C/C++test, Jtest, dotTEST, SOAtest, and Selenic, support the association of tests with work items defined in these systems, like requirements, stories, defects, and test case definitions. DTP, Parasoft’s central reporting and analytics dashboard, manages traceability.

Summary

IEC 62443 establishes guidelines and processes for ensuring the security of IACS products, covering aspects such as secure coding, testing, deployment, maintenance, and disposal. The key practices of IEC 62443 include establishing a cybersecurity management system, conducting security risk assessments, specifying security requirements, adopting a secure-by-design approach, implementing secure coding standards, and conducting security verification and validation testing.

Software test automation plays a crucial role in these key practices, particularly in secure implementation and security verification and validation. Static code analysis is crucial for supporting code reviews and compliance with secure coding standards. In addition, static analysis detects coding errors, vulnerabilities, and weaknesses early in the development life cycle.

In terms of security verification and validation testing, software test automation tools are key to making testing feasible in time frames needed to deliver secure IACS products to market. Including accelerating testing processes, ensuring compliance with security standards, and providing evidence of due diligence. Automated traceability in verifying and validating security requirements is critical to ensuring security requirements are met. Automation also keeps requirements validation documentation up to date, ultimately contributing to accelerated compliance of IACS products.