Sematicon was represented at Automatica, an OT trade fair, this year. What was the most frightening thing you heard?

Michael Walser: For many, cybersecurity is still an open book. We spoke to many production managers and their top priority is to keep robots and machines running and producing. Security is not their focus. They were shocked when they saw how quickly a plant can be paralyzed. Now, it has to be said that we don't hack at our stand, we only use legitimate features to undermine systems. We show interested parties the risks and how to avoid them. Many people are simply new to this. Many know that cybersecurity is necessary, that machines are at risk, but they don't know exactly what the threat looks like, what form it takes and how they should react to it. And that is a huge problem!

Education is massively important to give people the right tools and to understand how they need to react to a threat. Cybersecurity is not just a product issue: manufacturers like to advertise control units with security certification. That's nice, but there are also previous versions that are not: There are existing systems on the grid that are more than 20 or 30 years old. These also need to be secured. And safety certification does not mean that the system is safe per se. Security can only be guaranteed if the overall system as such, the plant as a whole, meets all requirements.

Cybersecurity is not achieved by installing and activating a product, but also through organizational and technical measures. If you simply nail down systems completely now, then of course you also have to ensure that maintenance is possible later on. If you want to put systems on the Internet, you need to think carefully about what the repercussions might look like. In other words, not only what information you supply to the Internet, but also what information comes back and what influence this has on the system. Creating this understanding of risk is extremely important. We need to bring cybersecurity up to the same level as physical machine safety - because you can't have one without the other.

When it comes to cybersecurity in OT environments, ideas from the IT sector are often used. How treacherous is this approach?

Walser: Two aspects need to be distinguished here. On the one hand, IT systems are protected by virus scanners, endpoint security systems and patches. This classic IT approach is often omitted in OT, although there are Windows systems and Linux computers here too. But in OT, it is often argued that no virus scanners or patches can be installed, as otherwise the system cannot be operated smoothly.

"So there are solutions whose approach works smoothly in IT, but which can quickly become a problem in OT due to their product characteristics."

On the other hand, there are very good solutions for network monitoring that perform intrusion detection, i.e. monitor for changes in the network, software or code and react to atypical incidents. The problem for the OT side is that similar solutions usually have to exclude critical maintenance access due to their nature. So there are solutions whose approach works smoothly in IT, but which can quickly become a problem in OT due to their product characteristics.

Video tip: In the video interview, Michael Walser explains various attack scenarios for OT environments.

One example: systems are usually not built in such a way that people have to clearly identify themselves in order to be allowed to work on them. The technicians usually have full access (for argument's sake). It must also be ensured that parameters can be changed during operation. This means that you can change settings, software and code on the system during operation. This is also necessary to avoid downtimes in networked production. From my point of view, the problem therefore arises particularly with maintenance access when external systems such as technician PCs or notebooks are brought in, which in turn change the software in some way. The automatic protection systems mentioned above can hardly prevent an attack: How is the system supposed to know, for example, whether this is an experienced or an inexperienced person who solves problems differently. Even if they only use functions that are intended for maintenance, this can be misused. Or is it an attacker who not only exploits the so-called 'security vulnerabilities' but also the legitimate product features in order to disrupt operations?

Does this only apply to maintenance or remote maintenance?

Walser: Whether maintenance or remote maintenance - as soon as a third-party system is connected that is able to change something on the system. Due to the lack of authentication in most cases, this can be any system. I say: If no external devices or external content are brought into the systems, a virus scanner is probably not necessary. A security patch is also not necessary as long as a system is considered completely isolated. The problem with isolation: 'The system is separate' is only correct to the extent that an external system is never brought in. However, if a technician's notebook is brought in that has been connected to the Internet or an untrusted data carrier in the past, this device can no longer be trusted. Furthermore, in the case of external notebooks from external technicians, it is never possible to determine with certainty whether these devices are supplied with the latest updates and security patches.

In this context, trust is to be understood as a definition: All devices that are not part of the system must not be trusted under any circumstances. In technical jargon, this approach is also known as 'zero trust'. A predicate that also characterizes the approach of our in-house solutions.

"Many people don't know what a threat looks like" - Part 2: Stuxnet and open source software

But how can you ensure that a new code introduced into the system serves its intended purpose?

Walser: With validation and 'zero trust'. This means regularly checking whether the code in the system is still the code that was introduced. Let's take the example of Stuxnet: The malware was installed on various computers, but did not make an appearance there, but waited until enough computers were infected so that eventually one was connected to the target system. As soon as this computer was connected to the system, the malware started feeding data into the system and manipulating the network - it attached its malicious code when it left and removed it again when the data was loaded from the system during the scan. This means that the programmers only saw the code in their software that was supposed to be on the system. What does this mean? Quite simply, with the classic programming tools on the PC, we cannot ensure that the source code is correct across all systems. We need a third system that validates and is able to compare the code. We can't trust the technician per se, in other words: zero trust.

Stuxnet is considered a state attack. The effort behind it is enormous. A small or medium-sized company is unlikely to become the target of such an attack.

Walser: Stuxnet was developed for a specific purpose: They obviously wanted to manipulate systems without the technicians noticing. This means that different values were displayed on the instruments in order to operate the system in the background over time in such a way that it could be destroyed without being noticed. However, the instruments did not indicate an error. A cybercriminal will generally not attack a medium-sized company, but rather a specific product series from an automation manufacturer and exploit a vulnerability there.

"Many people know that cybersecurity is necessary, that machines are at risk, but they don't know exactly what the threat looks like, what form it takes and how they should react to it. And that's a huge problem!"

Let's take a control system as an example: the attacker may not have any explicit knowledge of how it works, but he can simply connect the input and output of the PLC together or close all PLC outputs. Perhaps the lights go on and off everywhere, or perhaps a gas valve is opened, destroying a production line or injuring a person. It is therefore important to distinguish between a clear attack such as Stuxnet, which served a specific purpose, or simply a blind attack, which is about blind destruction or gaining attention.

Video tip: In the video interview, Michael Walser explains various attack scenarios for OT environments.

So the most dangerous attackers are those who don't actually know anything about the target system?

Walser: I wouldn't say that. First and foremost, it's about sensitizing people and companies. An example: an engineer likes to build his own solution. He uses the advertised, easy-to-use mini PC for the DIN rail based on a Linux operating system, which is quick and easy to get started with, and uses the resulting system in his company. At this point, he becomes the manufacturer, but he does not really have control over his system and does not know how to identify and close security gaps. This opens up many more potential gateways for attackers.

What do you mean by "an engineer becomes the manufacturer of his own systems"? Does this entail certain obligations?

Walser: Not so much legal obligations at the moment, but a moral obligation: I have to take responsibility for my products and behave like a manufacturer; this is usually ignored. As a manufacturer, however, I have to ensure that the components used are always up to date and also ensure the correct (security) configuration. Many people also forget this: We are currently talking about security, but safety and security belong together: A security incident can of course also jeopardize safety. Safety is the protection of people. Security describes the protection of the system.

How is security mapped in hardware and software?

Walser: Software security is actually more a question of which processes run on the hardware. Hardware is also operated with software. This is called firmware. You can imagine it like this: If I want to write software or firmware today, it is not a complete in-house development, but the software is supported by external libraries, i.e. program modules that perform certain tasks. No technician today will write network communication themselves, but will organize a corresponding library. No manufacturer today will develop a GUI, i.e. a graphical user interface, but will get a framework for it. This means: framework plus libraries plus my own code form the software product used. The challenge is to determine the state of the library I am using.

What do I mean by that? As an example, I would like to mention the framework or software library 'Log4j', which has recently been all over the media. This is a small library that was maintained by an open source maintainer in his spare time. Many large corporations used the open source framework for logging application messages. When the security vulnerability became apparent, everyone put enormous pressure on the developer to fix the code. But with what justification? That a developer is developing open software for fun in his spare time that large corporations use voluntarily? This example shows how the open source concept is being misused here: I can't obligate anyone, because I didn't pay them to deliver a certain product - I simply used their library. And it is often underestimated how many free libraries have a security problem that is known and usually documented under a CVE number. This means that if hackers or security specialists discover security vulnerabilities in open source libraries, they usually give the manufacturer two to four weeks to fix the bug. After that, the security problem is published - then there is a known security vulnerability for parts of my software and I may not even know that this affects me or that I am using such a component.

This is what I meant earlier by manufacturer's obligation: It is my duty as a manufacturer to know which software libraries I include and how I can ensure that my software product - framework plus libraries plus my own code - is secure at the time of use or in regular operation. If I look for a library on the Internet that takes over my login to a self-built portal, then all my software is only "secure" as long as this library is secure. If I can bypass the login and password protection through an error in the component, then my system is no longer protected. This means that all the components have to stand together and I have to be able to find out for each individual module of my software whether it is at risk or not.

"Many people don't know what a threat looks like" - Part 3: Responding to security vulnerabilities

Can this process be automated?

Walser: A classic example of this are so-called SBOMs - 'Software Bill of Materials', i.e. a kind of 'list of ingredients' for software products. This must contain all the components used in a product. For this purpose, there are standard formats that are machine-readable, for example SPDX or Cyclon DX. This allows security managers to integrate a software list into their security management system and regularly search for corresponding CVEs, i.e. known security vulnerabilities. This enables them to react to a security vulnerability before it can be exploited by attackers. This means that I can react quickly when a gap becomes known, take the relevant software offline or take other measures.

This is simply not done in OT today - many manufacturers simply don't have any lists available or want to keep the content secret. A controller or software is delivered, period. In the industrial sector in particular, it is also argued that software should not be patched - also a big mistake, because why shouldn't a Linux or Windows system that hosts a database in an OT system, for example, be patched?

"Cyberattacks always happen when external systems or people intervene in a system."

This reasoning leads to the fact that I have no control over the system used, nor over the in-house development and therefore I have a relatively high probability of running into a problem that compromises me. Especially if maintenance access is via VPN. VPN is nothing more than an extended network cable. This means that the VPN tunnel is protected, but how do I know what is coming through the tunnel? A VPN also does not fulfill the principles of 'zero trust'.

Basically, what is the aim of security measures?

Walser: It's a good idea to ask yourself what you want to protect yourself from. I practice risk management: What are my potential risks? Where do I have problems? Every control system, every plant system is 'by definition always' unsafe. This means that my potential risk is direct access to the system. The moment a technician accesses the system, I have a potential risk. If a system communicates with the internet, how do I ensure that the process is inference-free? If I use an IoT platform, I send data to it. But is it a good idea to get the data back again? Because that gives me another gateway. Or an employee plugs a third-party USB stick into a computer or charges their smartphone at the USB socket of the system controller. These are all potential dangers.

"100 percent protection is not possible, but I can make the hurdles so high that the classic random attacker or so-called 'script kiddies' don't find it worth the effort to climb over them."

Cyber attacks always happen when external systems or people intervene in a system. So I have to think about where my biggest risks are and how I can protect myself against these potential dangers. 100% protection is not possible, but I can make the hurdles so high that the classic random attacker or so-called 'script kiddies' won't find it worth the effort to climb over them.

Targeted attacks on specific companies and industrial espionage are also a danger that should not be underestimated. As this is a targeted attack and not a run-of-the-mill scenario, it is more difficult to do anything about it. But here too, there are solutions and methods that need to be evaluated on a case-by-case basis.

Containers are another IT technology in the industry. How secure is the technology?

Walser: From the manufacturer's point of view, containers are great because I can supply all the components I need and run them within my container. Again, the problem is that when companies build a container, they also use ready-made components and integrate them into their software. An example: you write software in Java and the container delivers the appropriate Java runtime at the same time. There are also ready-made containers from open source sources, but these usually also include many components that I did not need for development but later for operation. Classic examples of this are package managers (for the subsequent installation of any software), corresponding editors and "sudo" programs that allow me to execute commands with the maximum possible rights. This means that when I build a container, I as the manufacturer have the responsibility to only put those components in the container that the user really needs for operation. And, as in the previous example, I have to consider beforehand whether there are vulnerabilities that affect me as the manufacturer - for example, functions of a library that is considered insecure. A container is not a free ride.

Another challenge with containers is the configuration: an unprivileged container that has no special rights in the high level system is usually easier to isolate than a privileged container with access to the high level system. As with all technologies, there are benefits and risks, I just need to know how to deal with the risk.

At the moment, ChatGPT is on everyone's lips and is also being used as a programming aid. How do you see this development?

Walser: It's a difficult question to answer. In development, it is sometimes difficult to tell who is programming something. Are they experienced developers or young professionals or hobby programmers with no training? Every technician searches the net for ideas and suggested solutions. Once a solution has been found, the question is whether it is the right one. Can I assess whether the sample code can be taken from the forum or not? Do I still need optimizations? Is the execution safe?

"There is currently no human-like artificial intelligence. What we know today is known in the professional world as "machine learning"."

Of course, we dream of having an intelligent system that can answer precisely this last question and support us in our work. ChatGPT gives the impression of being just such a tool. We like to talk about "artificial intelligence" here, but in the end it's just a complex algorithm. I hold the following dogma: as things stand today, there is no such thing as human-like artificial intelligence. What we know today is known in the professional world as "machine learning". This means that the system collects information, weights it and makes it available according to a query.

And ChatGPT works in exactly the same way: I ask the tool a question about a specific topic, ChatGPT answers very confidently in a seemingly moderated manner and backs up the answer with facts that appear to be correct. It uses the internet and all the information available there is unfiltered. Hence the use of racist or hostile terms. How is ChatGPT supposed to know which information is well or poorly researched? How is it supposed to know what is morally correct? Just because an assertion is shared by many sources and frequently replicated is no guarantee that it is correct.

There is the same problem with programming: ChatGPT takes programming snippets from the Internet, forums, etc.. How is the tool supposed to know which code is good or bad? Programming is more than just stringing together snippets of code. A developer should already know what he is doing. Like any tool, ChatGPT is a good support if I know how to use it and evaluate what comes out of it. But the responsibility for the result lies solely with the person using the tool.

Video tip: In the video interview, Michael Walser explains various attack scenarios for OT environments.