ISO 21434 Vs IEC 62443

ISO/SAE 21434 and IEC 62443 are both standards that deal with cybersecurity, but they apply to different domains and have distinct scopes. However, there are several commonalities and intersections between these two standards. Here’s a breakdown of how they relate to each other:

1. Domain Focus

• ISO/SAE 21434: Focuses specifically on road vehicles and cybersecurity for automotive systems. It addresses cybersecurity engineering throughout the lifecycle of automotive systems, from the concept phase to production, operation, and decommissioning.

• IEC 62443: Focuses on industrial automation and control systems (IACS) and defines requirements for securing such systems, including SCADA (Supervisory Control and Data Acquisition), PLC (Programmable Logic Controllers), and other industrial equipment. Its aim is to protect against cybersecurity risks in industrial settings.

2. Shared Goals: Cybersecurity Risk Management

Both standards emphasize risk management to address cybersecurity threats, vulnerabilities, and risks, though they do so in their respective fields.

• ISO/SAE 21434 provides a structured framework to ensure that cybersecurity risks in the automotive sector are identified, assessed, and mitigated. This includes defining cybersecurity goals, conducting threat analysis, and performing risk assessments.

• IEC 62443, on the other hand, emphasizes risk management for industrial control systems, including understanding how vulnerabilities and threats can affect production environments, industrial processes, or connected systems, and protecting them accordingly.

3. Cybersecurity Lifecycle

Both standards outline a cybersecurity lifecycle approach that ensures security is considered during all phases of system development and operation.

• ISO/SAE 21434 requires a cybersecurity lifecycle process in the context of automotive development, ensuring that security is built into the design and maintained throughout the vehicle's lifecycle, from design to end-of-life.

• IEC 62443 similarly mandates a secure development lifecycle for industrial systems, including design, implementation, operation, and maintenance.

4. Cybersecurity Levels and Risk Assessment

• IEC 62443 introduces Security Levels (SL1 to SL4), which define the cybersecurity robustness needed for industrial systems based on the risk profile. SL2, for example, offers protection against intentional but simple attacks with low resources, similar to the moderate risk scenario in some automotive systems.

• ISO/SAE 21434 doesn’t define security levels explicitly like IEC 62443, but it focuses on cybersecurity goals and risk treatment decisions that result from detailed threat analysis and risk assessments. These goals can correspond conceptually to the different security levels in IEC 62443, as they are based on the assessed risk severity.

5. Threat Analysis and Risk Assessment (TARA)

Both standards require a Threat Analysis and Risk Assessment (TARA) process:

• ISO/SAE 21434 requires manufacturers to identify cybersecurity threats, assess their potential impact, and define countermeasures to mitigate those risks. The process is specific to vehicle electronics and communication systems.

• IEC 62443 requires a similar approach in the industrial context, identifying risks to industrial processes and suggesting protective measures depending on the security level (SL) needed. It addresses threats to industrial networks, controllers, and communication protocols.

6. Security Controls

Both standards define sets of security controls to be implemented to mitigate cybersecurity risks:

• ISO/SAE 21434 suggests various security mechanisms, including authentication, encryption, secure communication, and secure boot, to protect road vehicles against cyberattacks.

• IEC 62443 outlines detailed technical controls for securing industrial systems, such as access control, data confidentiality, and integrity, as well as system resilience to attacks.

7. Alignment in a Connected World

• As the automotive industry moves toward connected vehicles, there is increasing overlap between automotive systems and industrial systems, especially in areas like smart manufacturing (e.g., connected cars produced in smart factories) or vehicle-to-infrastructure (V2I) communications, which may intersect with critical infrastructure (e.g., charging stations, traffic management systems). In these cases, there is potential synergy between ISO/SAE 21434 and IEC 62443 for managing cybersecurity in interconnected systems.

8. Supply Chain Security

Both standards place a heavy emphasis on managing cybersecurity throughout the supply chain:

• ISO/SAE 21434 requires that the cybersecurity posture be maintained across all parties involved in the design, development, and maintenance of automotive systems, which includes Tier 1, Tier 2 suppliers, and external vendors.

• IEC 62443 similarly focuses on ensuring that all suppliers, integrators, and operators in the industrial environment follow cybersecurity best practices to maintain the integrity of the control systems.

Conclusion

While ISO/SAE 21434 and IEC 62443 operate in different domains (automotive and industrial, respectively), both standards share a common goal of managing cybersecurity risks throughout the lifecycle of systems. The key difference lies in the specific context (vehicles vs. industrial systems), but they both require secure development practices, risk assessments, and implementation of technical controls. As these domains become more interconnected, especially with the rise of smart factories and connected infrastructures, these standards may align more closely in their approach to securing complex, interconnected systems.

„ The software shall comply with cyber security level SL2 according to IEC 62443-3-2 and IEC 62443-3-3” Does this requirement have an influence on the development of application software? (cf. Autosar Classic application software) If so, which one?

Yes, the requirement for the software to comply with cybersecurity level SL2 according to IEC 62443-3-2 and IEC 62443-3-3 does indeed influence the development of application software, including Autosar Classic-based systems. Here’s how:

1. Security by Design in Development

IEC 62443 SL2 sets a requirement for moderate protection against intentional security threats. To achieve this in application software, the development team needs to integrate security by design principles from the start. This means:

• Identifying potential threats and risks at each phase of development.

• Incorporating security features like encryption, authentication, access control, and secure communication channels.

• Ensuring that software modules are resilient to common cyber-attacks (e.g., tampering, data injection, etc.).

2. Security Lifecycle Integration

IEC 62443-3-2 and 3-3 standards emphasize a secure development lifecycle for industrial control systems. This will require your development processes to incorporate:

• Threat modeling and risk assessment: During the design phase, identifying risks specific to the context of the application, such as unauthorized access, manipulation, or denial of service.

• Security testing: Specific tests to ensure the application complies with the SL2 requirements, like penetration testing, fuzz testing, and vulnerability analysis.

• Secure coding practices: Following secure coding guidelines to mitigate common vulnerabilities (e.g., buffer overflows, injection attacks).

3. Functional Security Requirements

Under IEC 62443 SL2, there is a need to implement functional security measures that protect against attacks such as:

• User authentication: Implementing role-based access controls (RBAC) and secure user management in application components.

• Data integrity and confidentiality: Secure storage and transmission of data, using encryption or checksums to ensure the integrity of data both at rest and in transit.

• Logging and monitoring: The application software needs to log security-relevant events and be able to detect and report potential security incidents.

These functional requirements directly impact the development process because they require specific security-related modules and interfaces to be part of the application software.

4. Compliance with AUTOSAR Classic

In the context of AUTOSAR Classic, SL2 compliance impacts various layers of the architecture:

• Communication stack: AUTOSAR's communication stack needs to be configured for secure data transmission, which could involve the SecOC (Secure Onboard Communication) module.

• Memory protection: Compliance requires that memory access be tightly controlled to prevent unauthorized reads or writes, affecting how AUTOSAR handles memory partitioning.

• Secure boot and software updates: AUTOSAR software may need to incorporate secure boot mechanisms and secure updating procedures to ensure system integrity.

The application software itself, developed using AUTOSAR Classic, needs to follow these guidelines and constraints to ensure it is resilient to cybersecurity threats and conforms to the SL2 level defined by the IEC 62443 standards.

5. Interaction with Infrastructure

The application software also needs to interact securely with infrastructure components, like communication protocols, field devices, and supervisory systems, adhering to the SL2 security policies. Therefore, developers must ensure that the software aligns with secure communication methods and supports the necessary security mechanisms in the wider system environment.

In Summary

The requirement to comply with IEC 62443 SL2 influences the development of AUTOSAR Classic application software by necessitating the integration of security principles and processes throughout the software development lifecycle. This includes adopting secure coding practices, implementing security functionalities (e.g., secure communication, authentication), and complying with testing and validation processes to meet cybersecurity standards.