(Photo: © generiert mit Dall.e)
April 2025
The subject of cyber security did not just suddenly become a topic of conversation in the lift sector upon the entry into force of ISO 8102-20:2022, published in August 2022. The problems and tasks associated with the subject are indeed not new.
By Roy Schneider
During my own professional career, the first case of an attack on lifts occurred 18 years ago via the analogue telephone network – for quite banal reasons. An employee left a lift company on bad terms. He exploited his knowledge and the remote diagnosis software on his PC to call the lifts and switch off the external controls.
The discussion on how access data were to be handled when employees left companies began at this time too. Even then we wondered what one should actually be allowed to change remotely without anyone bringing a standard into play.
Thus, today’s discussion about cyber security is not new but logical, since such access for maintenance and support during start-up and repair is far more common today than earlier, when only a few lifts could be reached via analogue modems.
A brief excursion to ISO 8102-20 now will serve better understanding. The norm includes so-called "domains" – these are requirement levels. The standard does not directly specify the components. The assignment occurs through the use and tasks of the individual components. Hence, most lift components, such as the controller or drive, must be assigned to the "Essential" domain (see box) according to this standard.
This is because when components assume the tasks of functional safety and are connected via I/O and fieldbus, assignment to a lower domain can scarcely be justified. The "Others" domain is really only occupied by components that are connected neither with the bus system of the lift nor with their data points (IO), i.e. which practically only share the power supply.
Security level 2 (see table) is required for the "Essential" domain. This security level 2 is defined as follows: "Prevention of unauthorised disclosure of information to a unit searching for it with simple methods, low effort, general skills and low motivation."
Let’s take a look at the table. The lift is mid-field here. It is not necessarily the most important part of the infrastructure. Of course, particular lifts no doubt have to be considered and evaluated differently (lifts that travel to an operating theatre or move ammunition on a ship). In addition, it is true that the common-or-garden lift in a residential block is not currently affected – that would be cracking a nut with a sledgehammer.
Assignment to the "Essentials" domain automatically carries with it classification as security level 2 – this refers to the skills of the attacker. Contrary to current discussions in the lift sector, this does not cover state entities, which operate under cover and with a major deployment of resources. It also excludes attacks by organised crime, intelligence agencies or their military associates.
It refers rather to attackers such as adolescents, who consider hacking a lift an exciting task or people who want to acquire access to premises by attacking a lift. However, both kinds of attackers require local access, have to get into closed rooms and the damage is limited to the lift itself. This belongs more to the sphere of cyber vandalism or criminality and consequently is a matter for criminal prosecution. Apart from hackers, another real threat is posed by "crawlers", i.e. automatic scripts that look for open network ports to attack and cause damage.
When speaking of cyber security in the meaning of the standard, this refers more to widespread attacks on transport infrastructure. In other words, attacks launched from a safe distance. Attacks on remote maintenance connections, i.e. the connections between the lift and the cloud, are best suited for this. The relationship between effort and achievable damage is attractive to the attacker and the inhibition threshold low.
This is why as software manufacturers we have to be prepared to answer the questions:
• Can the settings for functional security, for example the contactor monitoring, be changed remotely?
• How can such parameters be protected in general?
• Where do we document which parameters and password level is needed and which parameters or assistants can only be changed or used on the spot?
• How can we document parameter changes to ensure that they can be later tracked as far as possible in the order they were made?
• Recommendations for cyber security for users are of course also important, e.g. that passwords to protect important settings should be lift-specific and a company-wide password should only be used for maintenance tasks. But cloud providers also have to be prepared to answer questions, e.g. how they protect access data and how they inform customers in suspicious cases. Incidentally, the answers to such questions can be laid out clearly with the help of role diagrams (RACI) and flow charts.
And maintenance companies?
• The maintenance company that uses the cloud has to be sure that internal processes have been established that specify how the cloud access of former employees is deleted.
• Who is actually responsible in the company for the administration of remote access? In short, who retains an overview in order to amend or block access in suspicious cases?
• What is each employee authorised to do? The point is that access rights should always only be assigned according to the task (minimisation of access rights).
• Similar to data protection, each company should have a designated person/body. The latter is responsible for avoiding unnecessary delays in suspicious cases due to the person who is responsible being unclear.
• When it comes to classic (metal) keys, the transfer of "access" is more straightforward, provided no one has made physical copies of the keys. This is less clear in the case of digital access. Passwords obviously cannot be removed retrospectively from heads.
The author is a senior software engineer at Thor, a control software producer.
The domains in ISO 8102-20:2022: Others: Additional functions not related to safety, essential or alarm domains.
Alarm: Devices used to verify entrapment, to call for help and to rescue passengers in case of entrapment.
Essentials: Function or capability that is required to ensure the availability of the lift, escalator or moving walk, and its compliance to safety regulations, and which do not belong to Safety or Alarm function domains.
Safety: SIL-rated control functions
Digitalpaper
Write a comment