SIGNAL & DRAHT: Secure software development practices for the compliance of railway applications with IEC62443

Security in product development cannot be considered in isolation: it requires a well-defined framework where all the stakeholders collaborate effectively. The IEC 62443 series of standards provides a structured approach by assigning roles and responsibilities to the asset owners, integrators and product developers in technological operating environments. This article explores the key aspects of stakeholder involvement, risk management, secure coding and DevSecOps practices, thereby demonstrating how compliance with IEC 62443 strengthens cybersecurity, particularly in railway systems.

The stakeholders’ roles in the framework

Unlike corporate security standards, IEC 62443 is a well-established series of standards aimed at solving the security management issues presented in multivendor technological operating environments. It defines the roles and responsibilities of the industrial automation control system’s (referred to as IACS) owner, the integrator and the developer of the product being deployed. Devices and software in these environments rarely have the hardware or software capabilities that up-to-date security controls require. Yet, they are deployed in environments that resemble modern ICT environments and require additional security measures outside traditional industrial environments. The technology is not always the driving force; business cases ranging from integration to the centralised management of operations and auxiliary systems, data transfers, updates and maintenance warrant this. The standard allows all the stakeholders to engage in the project under the same framework and vocabulary, but it also requires all the parties to adhere to it for the deployment to succeed.

The asset owner is initially interested in deploying an IACS that is operable within its security management system (as defined in IEC 62443-2-1). The owner is accountable for the security of the entire system and defines the environment, security and business goals and the requirements, as well as the security processes applied in project.

The owner requires the integrator to ensure that the deployed system adheres to its policies, meets its security requirements and implements all the necessary controls. For the integrator, IEC 62443-2-4 sets out the required security measures and the integration of the system into the IACS owner’s security management. IEC 62443-3-2 defines the secure design process, while IEC 62443-3-3 defines the kind of controls that the deployed system needs to demonstrate.

The integrator needs to prove its ability to maintain the system’s security throughout its lifecycle. This is a major challenge if the product does not feature them required security features, fails to provide updates for any new security threats or vulnerabilities throughout the lifecycle or has been developed in a manner that continually introduces new threats to the system. This is covered by two standards: IEC 62443-4-1 and IEC 62443-4-2, the first of which defines the secure development process, while the latter defines the product security requirements.

In this kind of environment, the asset owner best understands the environment it is working in and the importance of the system to its operations. It is the primary authority in defining the threat environment, the security goals, the environment, the management principles and the continuity requirements for the system. On the other hand, the integrator has the best technical understanding of the system, while the product developer best understands the technology. These parties play an essential role in the design, threat management, risk assessment, designating the correct mitigating actions and implementing the controls. However, the process and criteria come from the asset owner in order to ensure that the results fit into their security management system.

Threat and risk management

UThreat and risk management is a recurring process for all the stakeholders: an integral part of both the system design and the product development processes. Even though product development is not likely to work directly together with the asset owners, the product still needs to fit the intended use.

IEC 62443-3-2 includes a risk assessment methodology for system design, including threat management. The following includes a closer look at threat and risk management due to it being applied in product development, but skips the rest of the design process. In order to succeed in risk management, the asset owner or product owner must also fulfil some prerequisites that have not been defined in the standard:

• The definition of the threat landscape: the threat landscape constitutes a holistic assessment of the state of the cybersecurity in global sense. This macro-scale environment includes current trends and the emergence of new technologies and is influenced by politics, available technology and societal constraints.
• The definition of the system’s security goals and objectives: how the system will be protected against the threat landscape in order to fulfil its business objectives. The goals and objectives may include strategic statements, security regulations and the standards being implemented.
• The definition of the threat environment: the concrete threats and challenges the system faces from the landscape. This often takes the form of threat scenarios that can be applied to the system in the risk analysis. The existing controls, user awareness and operating environment constraints impact the ability to mitigate threats.
• The definition of the risk assessment methodology, so as to ensure that the results of the risk assessment are consistent with the corporate risk management.
• The definition of the risk acceptance criteria and policy.

The security risk assessment process described in the standard is highly unlikely to be applied for risk assessment by the undertakings and it is therefore strongly recommended that existing processes that are familiar to both parties are used. Still, the chosen method needs to be detailed enough and must take a few important constraints that impact the system design into account. The justification here is that consistent and meaningful risk analysis is necessary, i.e. something that a novel approach may not provide. Therefore, this article does not cover the process itself, but does cover what the process should contain and what outputs there should be in order to modify the existing process.

• Identify the assets – i.e. what needs to be protected from threats. The system consists of components, is used by people and processes and is hosted on physical and logical sites. Prioritising the assets and defining the asset owners is required in risk management. Grouping assets into logical groups helps, as similar assets that have similar security requirements and are operated similarly face similar threats.
• Identify the relevant threats – threat environment definition, history data, threat databases and specialist analysis are common tools. The relevant ones must be chosen for the environment and implementation and the relevant threats that apply to them.
• Assess the likelihood and impact the threat has on the asset, which dictates the risk. Up until this point, this has involved heuristics and processes and good progress can be made if the given process is fed with information. The choice of mitigating controls and risk acceptance involves a large degree of compromise and uncertainty.

The unsatisfactory truth lies in the fact that the asset owner, integrator or product supplier work with limited resources, such as budgets, timetables, a lack of available specialists and even time constraints. It is necessary to be able to focus the efforts and resources on those things that have the largest impact and to sometimes choose controls that are not perfect, but are acceptable. When implementing new controls, it is necessary to consider whether the result is worth the effort.

• Assess whether the risk meets the acceptance criteria. If the threat poses an acceptable risk, it is possible to move on. If, however, the risk is not acceptable despite the built-in controls, countermeasures must be deployed to achieve risk tolerance.

There are various methodologies for choosing effective controls that reduce the likelihood or impact by means of technical controls, avoidance, limiting the attack surface, limiting the impact, shortening the impact or even sharing the risk. Risk assessment and the choice of mitigation controls is the reason for employing specialists who understand the environment and technology as part of the risk management group.

After deciding on a control, the risk when using said countermeasures and mitigating controls must be reassessed. It is necessary to consider implementing new mitigating controls, if the risk remains unacceptable. These mitigating controls must the be logged as requirements for the design process in order to ensure their implementation (and verification in the security case).

• Document the results. It is necessary to communicate the results of the risk assessment. The approval and release of the risk acceptance or the budgeting of the measures must be acquired and then issued as requirements for the implementing teams. Sometimes, mitigation requires implementation restrictions and conditions.

A similar process is used to analyse and implement the security features in product security. There are no environment specific restrictions and quirks, but it is necessary to communicate the constraints and restrictions when using the product instead. Even if the standard’s requirements are met, product security might be endangered by that one jury-rigged feature in the environment or non-standard implementation of an interface

Secure coding practices

Before talking about the code, here are a few points about system design. A well-designed system can prevent any security issues moving forward, thereby saving time and money and preventing security breaches. Problems in the design can be difficult or impossible to fix later in the implementation. An adherence to secure design principles lays the groundwork for secure application. Secure design principles:

• The Principle of Least Privilege: systems should only grant users and components the minimum permission they need to function.
• Fail Securely: in the event of a failure, the system should default to a secure state, thereby not exposing any sensitive information or allowing any unauthorised actions.
• Defence in Depth: the use of multiple defence layers (authentication, encryption, monitoring and zones) reduces the likelihood of a successful attack.
• Separation of Duties: the different roles within the system should be clearly defined and any actions that could cause significant harm should not be concentrated within a single person or module.
• Secure by Default: secure configuration should be the default, thereby minimising any risks from misconfigurations or user error.

When designing a system that complies with IEC 62443, as well as with the specific threats detected during the threat modelling, the system must also meet the cybersecurity technical requirements required by the standard. The standard defines four security levels, each with increasing requirements on top of the previous ones. The required level needs a separate assessment and the system can be divided into multiple zones, with each zone having a different target security level. As an example, we can pick level three for high cybersecurity: it aims to prevent an entity from actively searching for ways of compromising the system by using sophisticated means with moderate resources, railway system specific skills and moderate motivation. An example of a moderate actor could involve a security expert doing penetration testing, who has tools and knowledge and is willing to use some time and money to succeed.

Another issue not related to security standards involves is design mistakes that can be exploited. For example, if seats can be booked on a train for a group without a deposit, this could allow malicious actors to reserve all the seats in a train or in multiple trains. This could lead to profit losses and reputational harm. In addition, if this is a core feature, all ticket sales will use the group booking to reserve a seat until the payment is completed, which can be very time and money consuming to remedy.

Implementing the solution

Even the best design can be foiled by faults in the implementation. Therefore, care needs to be taken when implementing the solution. An effective method involves having a programmer who is knowledgeable and trained in cybersecurity. Another person then does a secure code review of the code and tools are used to scan the final result. As in the case of design, adherence to the following secure coding principles lays the groundwork. Secure coding principles:

• Input Validation and Sanitisation: ensure that all the data inputs have been validated against the expected formats in order to prevent any attacks such as SQL injection. Cleanse the inputs in order to remove any potentially malicious characters and scripts.
• Using Secure Coding Guidelines: implement the use of guidelines such as OWASP to avoid any common vulnerabilities.
• Secure Libraries and Frameworks: utilise vetted libraries in order to minimise any vulnerabilities, while ensuring that they are up to date with security patches.
• Regular Code Reviews and Static Analysis: conduct peer code reviews and integrate static analysis tools into the CI/CD pipelines in order to detect any issues early. These tools help automate the detection of vulnerabilities.

A code review is a widespread practice used to improve code quality. A secure code review widens the focus to include security concerns. Together with static analysis, this is one of the most effective ways of identifying security bugs early in the system development lifecycle. The earlier vulnerabilities are detected, the faster and cheaper they are to fix.

The Open Worldwide Application Security Project (OWASP) is best-known for the OWASP Top Ten. This is a list of the most critical web application security risks. While it involves web application security risks, many of them also apply to embedded systems and railway control systems. This is good knowledge for both the programmer and the code reviewer. In addition, OWASP provides a code review guide that gives guidelines for a secure code review and contains technical references with examples of vulnerabilities. IEC 62443 also mentions OWASP as an example of a well-known guideline to use.autateiden ohjausjärjestelmiä. Tämä on hyödyllistä tietoa sekä ohjelmoijalle että koodin tarkastajalle. Lisäksi OWASP tarjoaa koodikatselmointiohjeen, joka sisältää ohjeita turvalliseen katselmointiin ja teknisiä esimerkkejä haavoittuvuuksista. IEC 62443 mainitsee OWASP:n esimerkkinä tunnetusta ohjeistuksesta.

Enhancing railway cybersecurity through DevSecOps and IEC 62443 compliance

With over 45 years of experience in the railway industry, Mipro has invested substantial resources in software product development. By leveraging its modern and innovative DevSecOps (Development, Security and Operation) pipeline, Mipro has effectively overcome the limitations of the triple constraint. Mipro Oy enhances system resilience, optimises resource allocation and ensures regulatory compliance by integrating security into the development lifecycle early on and adhering to IEC 62443 standards.

IEC 62443 provides a structured framework for securing industrial control systems. The company employs a combination of automated security testing, risk assessment and continuous monitoring to systematically fulfil the standard’s requirements. The integration of tools such as Jenkins and GitLab facilitates automated CI/CD pipelines with embedded security checks at each stage of software development and deployment. Jira plays a critical role in tracking vulnerabilities and ensuring that security issues are addressed in a structured and timely manner.

Ensuring software security validation is a key requirement under IEC 62443-3-3 and IEC 62443-4-2. The company employs SonarQube for static code analysis in order to enforce secure coding practices and detect vulnerabilities at an early stage so as to meet these requirements. OWASP DependencyCheck is used to analyse any third-party libraries, thereby ensuring compliance with the security policies and reducing the risk of supply chain attacks. Trivy is implemented in containerised environments in order to scan for known vulnerabilities, thereby guaranteeing the integrity of the deployed software components.

In addition to secure coding practices, threat detection and risk assessment are also essential components of Mipro Oy’s security strategy, thereby aligning with IEC 62443-3-2. Nessus is utilised to conduct regular vulnerability assessments, evaluate system security posture and identify misconfigurations before they become exploitable threats. The Robot Framework supports dynamic application security testing (DAST), i.e. the simulation of real-world attack scenarios to validate the system’s resilience against potential cyber threats.

The company has adopted a defence-in-depth strategy by integrating automated security scanning directly into CI/CD workflows in order to maintain its continuous compliance with IEC 62443-3-3. This approach ensures multiple layers of security validation and minimises exposure to any potential attacks. By implementing automated monitoring and continuous security assessment, Mipro Oy ensures that railway control system applications remain protected against evolving cyber threats.

The company has not only strengthened its software security by leveraging the DevSecOps tools in alignment with IEC 62443, but it has also enhanced its operating efficiency. This proactive approach to cybersecurity fosters robust threat detection, secure software development and resilient railway infrastructure, thereby ultimately ensuring safety and compliance within the industry.

While security tools are invaluable in identifying and mitigating security-related risks, their effectiveness is ultimately dependent on human expertise. Automated tools can highlight vulnerabilities, but translating these findings into actionable security improvements requires collaboration across multiple teams. At Mipro Oy, the software development team, security team, IT service management (ITSM) and DevSecOps team work together to assess, prioritise, and remediate any security issues in a structured manner.

The organisation has established a dedicated DevSecOps steering team to manage the complexity of its security operations and ensure alignment with IEC 62443. This team plays a crucial role in overseeing all the aspects of security integration within the development process, thereby ensuring that security and privacy considerations are embedded seamlessly into product development. By fostering cross-functional collaboration and strategic oversight, the DevSecOps steering team enables the organisation to maintain a proactive security posture and ensures compliance with the industry standards, while delivering high-quality, secure and efficient railway software solutions.

---

AIHEESEEN LIITTYVÄT SISÄLLÖT

---

Kirjoittajat