A Balancing Act

The Conflicts Between Cybersecurity and Functional Safety

by Tijmen Molema

This paper was presented at the 2023 International Elevator & Escalator Symposium in Edinburgh, Scotland.

In the rapidly evolving landscape of technology, ensuring the safety and reliability of lift and escalator systems has always been of paramount importance. Over the years, the industry has witnessed a significant shift toward embracing innovative solutions. Over the last decade, Programmable Electronic Safety Systems (PESS) have proven themselves to be safe and “here to stay.” They are more flexible, cheaper, enable new designs, are easier to update and can provide (diagnostic) information. Incorporated with Industry 4.0, they enable preventive maintenance, near-miss monitoring, higher uptime and even shorter rescue times.

However, new possibilities come with new challenges: Cyber threats such as malware, Denial-Of-Service (DOS) and “man in the middle” attacks are major concerns and can impact your carefully designed safety system. Is it possible to also make a PESS cybersecure? And where do the standards for functional safety (IEC-61508) and cybersecurity (IEC-62443) conflict? How can we tackle this?

This paper delves into the intriguing interplay between functional safety and cybersecurity standards and laws, adeptly deciphering their conflicting demands. Unraveling the rationale behind these disparities, it offers insightful solutions to effectively harmonize the two domains.

Rise of Complexity

Although the world around us is changing fast, our main goal is “to ensure safety of lifts.” Safety is defined as “freedom of unacceptable risk” (IEC61508-4, 3.1.11) and risk is defined as likelihood x consequence (ISO/IEC Guide 51:1999, definition 3.1). As the complexity of a system increases so does the chance of faults — more components that can break in more ways and a greater chance of human failure. As a result, complex PESS systems have high demands on components and defined processes. However, most lifts operate in the safe womb of the building: the shaft. This is a fully controlled environment; no other cables or systems are allowed by the EN 81-20 standard. This is also why security was not a real issue until the Internetof Things (IoT) arrived. As soon as the outside world gets introduced to the controller, things become interesting.

Cybersecurity

When connecting a PESS system to the internet, new challenges arise. The internet, consisting of thousands of routers, switches, databases and so on, is not designed or validated according to the IEC 61508 series. This is why the connection is called “black channel communication.”

With black channel communication, there is no full control over the equipment used and there is no trust in the software/hardware. This is where cybersecurity finds its first major difference with functional safety. Functional safety is in a controlled environment where all software and hardware is known, but with cybersecurity, this is not the case. Even worse, the world of hacking is self-improving and beyond the control of system designers. In other words, there is no way to know what is going to hit you tomorrow. As hacking tools become cheaper and more readily available, and therefore more easily accessible, cyber threats are increasing rapidly.  

Types of Hackers

To be able to adjust the security level as a defensive mechanism for hackers, it is important to understand the different types of hackers and their motives. With different interests and goals, they tend to adopt different strategies.

The first group of hackers is the largest in number, but with the least knowledge. With the increasing flow of tools, highly sophisticated attacks can be performed with minimal knowledge. A well-known term for hackers with minimal knowledge is “script kiddies.” In a Carnegie Mellon report prepared for the U.K. Department of Defense in 2000, script kiddies are defined as:

“The more immature but unfortunately often just as dangerous exploiter of security lapses on the Internet. The typical script kiddy uses existing and frequently well-known and easy-to-find techniques and programs or scripts to search for and exploit weaknesses in other computers on the Internet — often randomly and with little regard or perhaps even understanding of the potentially harmful consequences.”

The second group of hackers is defined as those with limited money, resources and time. They are often technique enthusiasts or smaller hacker groups looking for information or money. They create a cyberthreat for their own gain and will often seek out targets with low effort, low risk and the highest profitability.

The third group of hackers has unlimited money (mostly funded by governments), resources and time. They perform targeted attacks on systems of interest. Currently, strategic utilities such as energy, water and means of transport (trains, metros) are the main target(s) of these groups. However, there is a growing trend of attacks on manufacturers (Threat Intelligence Index, IBM, 2021), for example, espionage. Because of the unlimited resources of these hackers, it is difficult to defend against these groups. It will always be a game of cat and mouse. Please note that it is not always clear at what level the hackers operate and whether they are government funded or not.

Deliberate Damage

What the three groups of hackers have in common is that their goal is to cause harm, and they always work for their own interests. Kidnapping systems and ransom demands (ransomware), selling privacy-related data or using a system to mine crypto tokens; money makes the world go round. This is fundamentally different from functional safety, where threats are not created to cause harm, but out of faults in a step in the life cycle. While a functional security engineer assumes the good intentions of the developers and detected errors can put a system in a secure state, the cybersecurity engineer views the entire outside world as untrustworthy, and any attempt or misbehavior has the potential to completely destroy the system.

Fail-Safe

In safety engineering, the highest achievable systems are fail-safe; whatever breaks down, the systems always go to a defined safe state. This behavior can be misused by the hacker. By executing an attack, the system detects it is under attack and can enter a stopped safe state. The functional safety creates the possibility to hijack the lift and possibly hold building assets hostage. Distributed DOS (DDOS) attacks are among the most performed attacks. They are one of the easiest attacks to perform within a reasonable budget and can be the most difficult to defend against. Once the system depends on an internet connection to perform its task, a DDOS attack becomes a major threat. A possible solution can be learned from functional safety, where a cybersecure state can be described as “no connections to the outside world,” or island mode. As soon as the system detects that someone is trying to tamper with it, it goes into island mode. A consequence is that this gives constraints to the design, as the safety functions cannot rely on the network.

To Update or Not To Update

Cyberthreats are 99% due to software issues or bugs. Fortunately, software is easy to update. When a bug is found in a product or library, a patch can be created. This patch, in combination with the patch notes, will be inspected by hackers. As a result, the bug is now publicly known and will soon be used by hackers of all levels. Tools will be created and trickle down to script kiddies. Keeping software up to date is one of the cornerstones of cybersecurity.

Functional safety demands strict control over system changes and updates to avoid introducing potential errors or failures. For each update, a process shall be started with an impact analysis. Each step of the process shall be verified and documented, ending with testing and verification to ensure no additional risk is added. This process could take months because endurance tests must be done to gain confidence in the system.

The increase in lead time can cause serious conflicts within the company. The initial solution is a risk assessment. In such an assessment, it is decided which action has the most risk and if an update is necessary. On second thought, this way of working is a mitigation tactic rather than a real solution. It is better to split the software stacks already in the design phase, so that functional safety is not affected by cybersecurity updates.

Documentation

Within functional safety, it is good practice to share information about the system with installers, maintenance employees, system integrators and inspection bodies. By sharing the limits of the system and the prescribed maintenance, the overall condition of the system and, therefore, safety remains at the desired level.

When combining several subsystems from different manufacturers, detailed architectural information is needed to assess the overall safety level. Typically, a safety manual will describe all demands for surrounding systems of a subsystem.

In cybersecurity, it is the other way around. Documents shall be restricted and confidential to give attackers minimal starting points. As a result, the first stage of a cyber attack (Reconnaissance phase, initial preparation phase for the attacker to prepare an attack by gathering information about the target) can be delayed, sometimes to the point of no attack. When time and money are limited, hackers tend to go for an easier target.

Hence that “security through obscurity” is not the goal, and not even secure at all and Kerckhoffs’s principle should always be respected. You shall be able to explain the security to your trusted parties (for example a notified body), without giving them the keys or certificates and still be secure, even from them.

Safety and Security in the Lift Industry

Functional safety is currently in the “vast majority” phase. It is widely spread, and the requirements and limitations are understood in the field. The field of cybersecurity is just emerging for the lift industry. Mostly, the task of cybersecurity is given to the functional safety group, because “safety and security are almost the same, right?” However, as this article shows, the whole philosophy is clearly different and might lead to conflicts, if either of the two fields is not respected. A project is doomed to delay and cost overrun, with the ultimate consequence of unsafe or insecure systems.

Example of a Conflict

A lift controller manufacturer has an internet-connected system, which also offers several safety functions. The security department demands at least two-factor authentication for all (local) logins, as this is currently best practice. However, after a requirement review the multi-factor authentication is rejected.

The implementation of security measures should not cause loss of protection, loss of control, loss of visibility or loss of other essential functions (IEC62443-3-3). Security shall not disrupt essential operations. Since maintenance is part of the safety manual and for maintenance the operator needs to login and perform several safety functions, this demand cannot be met. A different strategy must be found to keep the system safe.

Conclusion and Recommendations

The worlds of cybersecurity and functional safety have great differences in philosophy, design and solutions. New technologies create new challenges where standards can give conflicting demands. Understanding both worlds and the origins of their demands is the basis for a proper design.

Recommendations

1. Ensure that a safety function is never dependent on an internet connection and that the lift can operate safely in island mode or at least evacuate.
2. Split the software stack for functional safety and cybersecurity as much as possible so that security updates can be performed in a timely manner.
3. As with safety, make sure you can explain your security systems without losing your security. For security reasons, only communicate this information to trusted bodies.
4. Split the functional safety and cybersecurity responsibility into two groups and ensure there is good communication and understanding between them.
5. Realize that once your connected system is on the market, you’re never done with cybersecurity. See certification as the starting point of your cybersecurity journey.

The conflicts between cybersecurity and functional safety are inevitable in the increasingly interconnected and technologically complex world in which we live. However, these conflicts should not be seen as insurmountable challenges. Instead, they should be seen as opportunities to develop a more comprehensive and integrated approach to system design and management. Collaboration between safety engineers and cybersecurity experts, adherence to established safety and security standards and a proactive mindset toward addressing these conflicts will be key to creating robust and secure systems. Only through a balanced and harmonized approach can we ensure that technology continues to drive progress while safeguarding the well-being of individuals and society as a whole.

Reference

[1] Mead, Nancy R.; Hough, Eric; Stehney, Theodore R. (31 October 2005). Security Quality Requirements Engineering (SQUARE) Methodology (Report). Carnegie Mellon University. doi:10.1184/R1/6583673.v1.