(Photo: © vectorfusionart / okapidesign/123RF.com)
June 2025
A standard devoted to cyber security entered into force a while ago in the form of ISO 8102-20:2022. Even though it has not yet been harmonised, technical inspection organisations have been demanding manufacturer declarations since the summer of 2024.
These must plausibly demonstrate how manufacturers are meeting the standard. This is an explosive issue …
ISO 8102-20 actually describes the implementation of IEC 62443-4 (Industrial communication networks – Network and system security) for lifts, moving walkways and escalators. The latter covers the actual tasks, not the ISO 8102-20!
IEC 62443-4 consists of several parts with the first dealing with organisation. Reading it will remind some of ISO 9001 and it would be helpful for the practical implementation if ISO 9001 has already been put into practice in the company. Responsibilities and processes are presented here in the form of role diagrams (RACI) and flow charts.
IEC 62443-4 includes individual sections on secure management (SM). This is because cyber security is not just of concern to the IT department but also for company management. What does this involve?
• Section SM-4 of 62443-4-1 requires the existence of a process for installing IT security training programmes in the company. This is intended to ensure that people get assigned roles and tasks they can continually fulfil.
• Section SM-7 specifies that the working environment of engineers must be protected against unauthorised access to ensure that a cyber-attack does not already occur during product development.
• Section SM-8 calls for a definition of how digital keys are handled in the company. This is important for those who develop software and typically sign these today digitally before they deliver them to customers.
• Section SM-13, which deals with how the weaknesses collected in the NVD (National Vulnerability Database) can be exploited in the company, is of especial interest. This makes it possible to check whether your own products could be affected. The NVD is the US database for this purpose but the EU is currently also working on its own database as part of the Cyber Resilience Act.
In general, the use of management methods like KANban can also be a way to comply with sections of the 62443-4-1 standard, such as SM-1 ‘Development process’ or SM-2 ‘Responsibilities’. This is because these sections require that roles and responsibilities during development are organised and that the work process behind the development steps is documented, continually reviewed and improved.
One of the tools frequently used by small teams for this purpose is Jira. While not perfect, it is good enough and easy to use. But there are of course other tools on the market too.
Incidentally, documentation of the weekly ‘development meeting’ also forms part of Secure Management. For example, it helps to observe the standard when you discuss the latest security entries of the NVD to make brief notes as to whether they apply to your own product or not.
As a software developer, there is no getting around these two sections of IEC 62443-4. Section 2 in particular addresses software development and for example requires the use of a modern storage system (repository) for the source code, such as SVN or GIT. This ensures that during the editing of source text changes, the who-changed-what-and-when is automatically documented. Most of the companies that develop software will have been doing this anyway on purely organisational grounds.
For some developers, the requirement for static code analysis may be new, i.e. for programs that check the source code and analyse it for typical weaknesses. Here too there are good open source solutions, e.g. the free version of CPPCheck.
One point that is also addressed in Section 2 are "fuzzing tests". They are intended to ensure that exposed interfaces are sturdy enough to withstand attacks. During these tests, the interfaces are subjected to deliberate bombardment with faulty data and syntax errors to determine whether access rights can be obtained in an underhand manner or the interfaces rendered unusable.
This, too, is not really anything new for software developers. But what is new that through the reference to the IEC, the question of documentation from the ISO can now be posed. This applies above all to the control manufacturer or the manufacturer of a cloud gateway.
The regular CANopen ‘plug parties', at which cross-company testing of the CANopen interfaces of the respective companies occurs with regard to their mutual compatibility, are also a measure that can be included when implementing Section 2 of IEC 62443-4.
Cyber security is not just a question of software development but above all one of company organisation. No one can take care of cyber security on their own! This not only includes secure development and meticulous testing but also the users, who can make a direct contribution to protecting lifts against unauthorised access through their behaviour. One link alone in the chain cannot take care of this!
The author is a senior software engineer at Thor, a control software producer.
Outlook: ISO 8102-21, which deals with software updates, has now succeeded ISO 8102-20. For example, it requires that a software manufacturer must describe for the technician at the end of the chain how the latter has to carry out a backup and update. This also includes the technician being able to ensure at the end that the file he installed in the component is also the file the manufacturer previously released (i.e. checksum/hash). The reason for this is that attack or manipulation is also possible during digital transport and storage on file servers.
Digitalpaper
Write a comment