95% of critical infrastructure operators overlook these three vulnerabilities — are you one of them?

95 percent of companies face exactly these three vulnerabilities in their IIoT systems. Do you as well? In this episode, I talk to Klaus Mochalski. He has helped shape the security industry from the ground up and brings years of proven best practices from the industrial sector. Klaus is the Strategic Advisor and Founder of Rhebo. Rhebo is a cybersecurity expert offering dedicated monitoring solutions. Together, we’ll answer these and other questions: What are the top three use cases related to typical vulnerabilities in your system? What does Klaus recommend for your IIoT security strategy? The NIS2 directive is coming — are you prepared, and if so, how? And finally, another exciting topic at the end: artificial intelligence in security. Is it just a hype, or does it bring real added value? And if so, what exactly? You’ll find out now — based on a customer example from the renewable energy sector.

Hello Klaus, welcome to the IoT Use Case Podcast. I’m really happy to have you here today, especially since you are a podcast host yourself. We’ll definitely talk about that in a moment. Welcome!

Klaus

Hello Madeleine, thank you for the invitation. I’m really enjoying being here today and sitting on the other side of the microphone for a change. I’m looking forward to our conversation.

I have to ask you something on a personal note first: you’re active in various areas. On LinkedIn, it says you’re an Entrepreneur, Strategic Advisor, and Founder at Rhebo. What’s the story behind the entrepreneurship part?

Klaus

Until recently, my profile said I was the CEO of Rhebo — and nothing else. But in fact, I stepped down as CEO almost two years ago. After that, I took what I call a “working sabbatical” with my family abroad. During that time, I gave up my management role but continued to support Rhebo as a strategic advisor. I added “Entrepreneur” to my profile because I didn’t just want to list “Advisor.” I’ve founded three companies so far: the first in 2005 and Rhebo as my third in 2014. So I think I can rightfully call myself an entrepreneur.

We definitely need to dive deeper into that — I’m in a similar role myself. And one more quick question: how did you end up becoming a podcast host? That’s not something everyone does. Was it just something you felt like doing, or how did that come about?

Klaus

I have to say, this was definitely a discussion we also had within our marketing team at Rhebo — whether this was the right format for us. But I supported the idea from the very beginning because I’m a podcast listener myself. I think it’s a fantastic format, separate from all the video content we’re surrounded by these days, because you can easily listen on the side without disturbing anyone and without having to stare at a screen. That’s why I liked the idea from the start. We did a bit of experimenting in the beginning and started out rather unprofessionally, but by now, we’ve become much more professional and consistent. I really enjoy doing it now with different guests. We are now in a kind of second season, and many guests have already been with us several times. Meanwhile, guests even reach out to us proactively and ask to join. It has developed really well, and we will definitely continue.

For everyone listening and interested in checking it out: “OT Security Made Simple” — I’ll include the link in the show notes. Be sure to give it a listen! I’ve been a guest there myself, which makes me especially happy. Now, as you’ve already mentioned, this is also about the company behind it: Rhebo. Let’s briefly dive into your company before we talk more about your customers and the market. Today, we’re focusing on renewable energy, but also on the plants and systems behind it. So, just quickly about Rhebo: you provide OT and IIoT security solutions, especially with a focus on anomaly detection. I think we’ll take a closer look at how your customers are using it in a moment. But first, could you tell us a bit about yourselves and especially about your customers? What market are you operating in?

Klaus

Rhebo started in 2014, and from the very beginning, we’ve been a pure OT and Industrial IoT security provider. We didn’t grow out of IT security like many other players on the market; we started with the clear goal of protecting OT systems — industrial control systems in the broadest sense. That has always been our optimization target. The system we offer our customers today is essentially the same solution we developed back then. The concept has evolved, but it hasn’t fundamentally changed. We monitor communication in connected digital industrial systems, specifically in OT environments. We use algorithms to learn and understand what normal communication looks like. Once in operation, we continuously monitor that communication and look for deviations. As you mentioned — anomaly detection. Whenever there are changes in communication patterns, we try to assess whether these changes could lead to disruptions or outages in the system. In the end, what we sell to our customers is early detection of events that could cause downtime. These could be security incidents, but also technical malfunctions. In fact, many of our long-term customers, who originally implemented our system for cybersecurity purposes, are now also seeing the added value in identifying technical issues. These issues also generate anomalies in communication, and that aspect often delivers even greater value because it helps extend the lifespan of the system by identifying all root causes of disruptions within the communication infrastructure.

I think we’ll dive deeper into that in a moment. What really interests me is the concrete use cases and which vulnerabilities you’re identifying, particularly from your customers’ perspective. I’m sure that’s something many listeners are curious about. But before that, just briefly: you mainly work in the critical infrastructure (KRITIS) sector but also with industrial companies. Can you describe the kinds of systems you’re looking at in the renewable energy space? Just as an example: are we talking about wind turbines, specific hydroelectric plants, or does it not matter? Do you monitor any kind of OT systems?

Klaus

We are relatively agnostic when it comes to the types of systems we monitor. Of course, there are sometimes technical differences, but in the end, those play a rather minor role. You’re absolutely right — our core target group is also defined by regulations and legislation in Germany and Europe. From the very beginning, our customers have been companies subject to the IT Security Act and classified as critical infrastructure (KRITIS), which means they need to meet specific requirements. Initially, these were primarily large energy providers and major distribution network operators. Over time, more and more smaller companies have joined. Now, we’re also seeing medium-sized municipal utilities coming in, and with the upcoming NIS2 directive, this will broaden even further. The customers are becoming smaller, and as a provider, we naturally have to adapt our products and services accordingly. Renewable energy plants are automatically part of this ecosystem, as every large energy provider operates such plants and systems themselves. There are specific technical challenges in that area, which we can go into in more detail. We’ve often asked ourselves what the best approach is to monitor these distributed systems. Especially when it comes to renewable energy generation, we frequently deal with decentralized structures — and that’s a key difference. While a power plant operator might have two, three, or five large plants that can be monitored centrally and relatively easily — where we install our sensors on-site in the power plant or substation, and these sensors send their anomaly data to a central security dashboard — things are different when it comes to renewable plants. If, for example, I operate 30 wind plants, or look even more granularly at the individual turbines, which can also potentially be attack points, then we are suddenly talking about up to 3,000 units. You can imagine that it is not possible to install a sensor in each individual turbine to monitor it locally. Other approaches are needed to provide this functionality efficiently on-site.

I am sure there are also some people from manufacturing listening here. This does not only concern wind plant operators but also manufacturing companies that, for example, operate PV plants on their rooftops or use other renewable energy sources. This is currently a key topic in politics and business. I do not want to become too political, but it is definitely also relevant for manufacturing companies to integrate data from renewable energy sources into their overall energy mix. So, you are not focusing exclusively on wind plant operators.

Klaus

Absolutely. In the past, these systems were often exempt from CRITIS regulation because they tended to be smaller systems in terms of capacity. There have always been discussions and lobbying efforts regarding the specific threshold values, which then ended up in the amendment of the IT Security Act. It is regulated there whether the individual plant capacity is decisive – in which case many plants would be excluded, as they are often smaller in the PV and wind sector – or whether the total plant capacity counts. In that case, they are included again. We have all heard that Germany generated a very high share of its electricity from renewable energies last year — it was over 50 percent. This automatically makes it critical infrastructure, and these plants must be protected. Even on a smaller scale, this affects many industrial companies. One example is BASF, which relies on wind power and installs its own plants to supply the Ludwigshafen site with electricity. This also becomes a critical resource and must be protected like any other critical resource in the company.

There are of course some challenges — especially when it comes to the expansion of renewable energies, regarding grid stability or storage options. I know that today we want to focus on the topic of security. If you are interested: I have already recorded a podcast episode on this; it was episode 136 with RIZM. We presented two exciting examples — one with Schaeffler, which was about production at optimal energy prices, and one with BMW, where it was about the intelligent optimization of investments in energy systems based on data. If you would like to dive deeper, feel free to listen in. But now I would like to bridge to the question: why are we even talking about security today? You already mentioned it — it’s about NIS2. Perhaps we can briefly explain what this is about and why we are talking about security in the context of renewable energies. Let’s start there — first with NIS2. At its core, it is a directive that requires companies to have monitoring measures in place and also to prove that they are implementing IT security requirements.

Klaus

Exactly. NIS2 builds on the original NIS directive. I have already mentioned the IT Security Act in Germany several times — that is directly based on the implementation of this first NIS directive, which is a few years older than NIS2. These directives are issued by the EU and must be transposed into national law by each member state. This has taken place in all member countries. NIS2 is now a tightening and, above all, an expansion in terms of scope. This means that significantly more sectors are affected, and above all, also smaller companies. The thresholds, as far as I remember, are around 50 million euros in turnover and 50 employees. You can easily calculate that a large part of the German mid-sized sector falls under this — and rightly so. However, in Germany, NIS2 has not yet been implemented. Our current government problems have meant that it has not yet passed through parliament. The assumption is that it will be implemented in the course of the summer at best, but at the latest by the end of the year. After that, there is a transition period of about two years until it can also be checked to what extent companies meet these requirements.

If we translate that into practice — what does that mean for me as a wind plant operator if I, for example, operate 30 plants, or also as a manufacturing company? As I understand it, I have to think about: how do I deal with my vulnerabilities? How do I establish processes to identify and monitor such vulnerabilities? Can you explain that again? What does that mean in practice for an operation?

Klaus

Let me put it polemically and bluntly: theoretically, it means nothing. Anyone who operates their plants properly and conducts a risk assessment — as any management should do for all factors that threaten the business — is already on the safe side. If you install wind energy plants, you have to analyze which weather phenomena could damage them. The same applies to PV plants. You protect yourself against financial risks and generally weigh all potential dangers to the business. You quantify these risks and decide whether measures need to be taken for certain threats that are either very likely or would have drastic consequences. That can be an insurance policy or technical protective measures — and exactly the same applies to cybersecurity.

Anyone who has done their homework in this area does not actually need to change much. But concretely and constructively: what does this mean in practice? First — and this is also stated in the regulations — I have to carry out a risk analysis and establish an information security management system. However, that should be a given anyway. It is not an excessive requirement but a necessity. I should know and document my risks in the area of cybersecurity. In addition, there need to be defined instructions for action, responsibilities, and processes so that, in the event of an incident, chaos does not ensue.

[14:22] Challenges, potentials and status quo – This is what the use case looks like in practice

What are typical use cases? Which vulnerabilities occur frequently, and which ones should definitely be examined to carry out a well-founded risk assessment?

Klaus

Yes, absolutely. First of all, I would like to say: in the areas in which we are active — often the KRITIS environment, where we really monitor critical infrastructure — real incidents are relatively rare. This means that we often read more about it in the press than we hear from our own customers. And that is a good thing. Nevertheless, there is a certain discrepancy between the low frequency of actual incidents and the high frequency of vulnerabilities that we find with our customers. These vulnerabilities are potential entry points for intrusions. We therefore assess the risk as significantly higher than what actually happens. But we often only have anecdotal information about this. Perhaps we can talk later about a concrete case that we really observed. What we do observe systematically and empirically are security risks — vulnerabilities in infrastructures. These have already been described many times, but we have been quantifying them for years with our customers. For last year, I can name the most common vulnerabilities we found. We regularly publish a top-ten list, and from that I would now like to highlight the three most frequent points. Interestingly, these three occur with almost identical frequency — we observed them in about 95 percent of our customers for whom we conducted security analyses. These are unnecessary protocols and services. That means we find, in infrastructures that serve a clear purpose — for example, the control of a wind plant — communication protocols and software services that are active in the network but not needed at all. The best practice recommendation here is always: shut down everything that is not needed. Because every unnecessary component offers an additional attack surface.

Okay, that means concretely: I have, for example, in my solar plant or in the control systems of my PV plant on the roof, protocols and services that are not needed or that provide faulty information? What exactly is the challenge in this context?

Klaus

One example could be this: we have a complete IPv4 infrastructure and see three or four systems communicating via IPv6. That is not a problem in itself, but it offers an additional attack surface for potential attackers. This IPv6 part is likely less well managed and possibly not as well protected by the firewall as the IPv4 area. Another example: in production environments, we have observed WhatsApp communication, because there are ways to gain access to the production network via a USB connection. Suddenly, private devices are communicating in the production network — and that is, of course, an enormous security risk. That was the first point of the top 3. The second point is so-called atypical communication patterns in the OT environment. OT-typical communication patterns include everything related to measuring, controlling, and regulating. These are industrial protocols through which control systems communicate with sensors and actuators, read data, and send control commands. The data volumes are very small, and there is usually a constant data flow. This looks completely different from typical internet traffic and behaves very consistently across all plants. If communication patterns suddenly emerge there that one would expect more in an office environment, that stands out. One example is backup software. Basically, backup software makes sense, but due to faulty network configurations, backup communication can overload the control network. This often leads to impairments in real-time communication. In the OT area, timing is crucial — not the volume. Control commands sometimes have to arrive within milliseconds or even microseconds, especially in automated production lines with robots running in cycle operation, like in the automotive industry. If I then transfer gigabytes or even terabytes of backups over a control network that already has limited bandwidth, this can lead to significant disruptions. In the OT area, we often observe a lack of basic IT know-how and best practices. There are also repeated discrepancies in collaboration between those responsible for the plants and the IT departments.

That is a typical phenomenon: IT and OT are growing together. But okay, the second case concerns the OT-typical communication patterns, as you described them — in particular the communication between sensors and actuators, which takes place more on the field level, and the example you just mentioned.

Klaus

Exactly. And behind this is a best-practice recommendation that is increasingly becoming established in the community: the strict separation of IT and OT infrastructures. This needs a bit of explanation, because there is always talk of convergence and how these worlds are coming closer together — and that is true. But although the networks are now digitally connected, they should remain clearly separated on an organizational level. Above all, there needs to be a security concept that defines the different security requirements in both areas, because these differ fundamentally. That must be implemented consistently. Generally, this is done through strict network segmentation and the use of appropriate firewalls. This way, you have pure OT communication on one side and IT communication on the other. If there is an exchange between the two, it must be clearly regulated and controlled.

Yes, absolutely important. If you are listening now and thinking: super interesting, we have similar challenges or would like to exchange ideas — Klaus, if that’s okay with you, I would just add your LinkedIn contact in the show notes. Then you can connect directly and exchange best practices. Especially the topic of how to implement this organizational separation in practice and what that means for operations is something I am also very interested in. We could probably even make a separate podcast episode about that. So please feel free to get in touch. Now, of course, I am curious about the third case. What would that be?

Klaus

The third point is based on the often outdated software versions used in this area. There is a lot of talk about control systems still running on Windows XP or even Windows 95. We have now broken this topic down in more detail. In the past, we simply said: “Old software.” Today, we know that this outdated software causes so many different problems that we have identified insecure authentication methods as the most important issue. That is, of course, often directly related to old software. Behind this is software that, for example, transmits usernames and passwords unencrypted over the network or uses cryptographic methods that no longer meet current security standards. An attacker can exploit these vulnerabilities within seconds using freely available standard tools. We see this quite frequently. One concrete example: unencrypted Telnet and FTP communication, where passwords are transmitted in plain text. There is no excuse for this anymore in the year 2025, because secure alternatives have long existed. This is definitely something that should no longer be part of your infrastructure.

[22:10] Solutions, offerings and services – A look at the technologies used

Now there is a question burning on my mind, and I would like to bring it forward. Earlier, we talked about anomaly detection, and you mentioned that there are specific algorithms for it. This kind of risk assessment can also be carried out based on data. Can you briefly explain how you do this at Rhebo, or how your customers approach this topic? I understand that you have identified a top-10 list of attack or vulnerability risks. How is this approached in practice? How do your customers support this process?

Klaus

When it comes to new customers, we support them by starting with a security analysis. That means we install our sensors — this can either be a software agent or a hardware device that we integrate into the infrastructure. Then we let the system run passively for a defined period, usually two weeks. During this time, all communication data is collected, and the system learns what normal communication looks like. Afterward, an expert from our team, who performs such analyses on a daily basis — we have a dedicated team that supports our customers continuously — takes a close look at this data and checks for anomalies. There are certain patterns and anomalies that the system detects automatically. But since the range of plants we monitor and the possible vulnerabilities and attack scenarios are very diverse, we do not rely solely on machine intelligence. We always analyze the data manually as well, to ensure that we do not overlook anything. Especially with new customers, we enter infrastructures that have often been in operation for many years, sometimes decades, with a wide variety of systems. That’s why a manual component is always part of it. We want to ensure a complete analysis that captures all anomalies. We then discuss with the customer what we have found. Many of the examples mentioned earlier come directly from these analyses — these are our empirical data. In the next step, we then discuss what needs to be done: whether it’s about network segmentation, patching, or replacing components, each case must be evaluated individually.

You’ve been working in this field for a long time now. What are your personal experiences from these projects? You support a wide variety of customers, and I’m sure there are many pitfalls or things you need to watch out for. What are typical situations where you think: “If only we had talked earlier” or “Money was spent here on things that weren’t necessary”? What are your personal experiences?

Klaus

The biggest problem I’ve seen repeatedly over the years, and that still exists today, is interestingly not a technical one, but a personnel issue. And that has various facets. On the one hand, there are far too few experts who are really well-versed at the intersection between the operation of industrial plants and IT security. There are only a few people who combine this know-how in one person. That means it always has to be a team effort. But these teams often have different priorities. For an operator of a plant, a wind park, or an automated production line, the top priority is stable operation and avoiding downtime. In IT, however, the focus is on data protection and data security. This is where the first “clash of cultures” happens. Many organizations are still struggling with how to best set themselves up and collaborate in this regard. There are models that have been established in large companies. But especially in smaller companies, structures and personnel are often lacking. That’s why, from my point of view, it’s extremely important to bring trustworthy service providers on board — especially for smaller organizations. For me, the biggest bottleneck is indeed the shortage of skilled professionals, even though it’s something you hear often and some people are tired of hearing it. But collaboration between the various teams within an organization also remains a major challenge.

And the customers who decided to work with you — I don’t know if we’re allowed to name them, I know a few from our preliminary discussions — what was the deciding factor for them? I could theoretically handle it internally, but as you say, the shortage of skilled professionals is a big problem. Alternatively, I could say: I’ll get external support, for example, your solutions. What were the reasons your customers chose this external solution? What’s the business case behind it?

Klaus

The original trigger for an investment decision is often the topic of compliance — in other words, regulatory requirements that must be met. The second major factor is the capacity issue. This has developed significantly over the years. In the past, we had many customer conversations where people said: “We operate the system ourselves. Our IT department takes care of it. We don’t need any additional service.” And in fact, six years ago, Rhebo didn’t offer its own service. We sold the system as a platform, and the customers operated it themselves. Large energy providers, who monitor thousands of plants, also have their own dedicated teams for this. But if you look at a municipal utility in a city of 200,000 inhabitants, where perhaps two or three people work in the IT department, it’s questionable whether the capacity and know-how are really there to operate the system independently. For exactly this reason, we have continuously expanded our service component over the years. Today, our standard offering is a complete package of platform and services. These services can take different forms. There is the option of pure support — the customer operates the system themselves, and we help as needed, for example with a forensic analysis after an incident. But there are also customers who completely hand over the operation to us. In these cases, we take on the role of a SOC (Security Operations Center) and continuously monitor the stream of anomaly data that our system generates in the customer’s infrastructure. In the event of critical incidents, we proactively contact the customer.

Okay, very nice. Compliance in this case means legal requirements for IT and OT security, protective measures that need to be implemented, and additional requirements that come on top. So that’s the main driver. And you offer companies the opportunity to meet these requirements together with you — both through your service and your products. That also includes the anomaly detection you mentioned earlier. If I understood correctly: you install the solution, then an expert analyzes the data over a certain period of time and looks for anomalies. Then you sit down with the customer to discuss where vulnerabilities exist and which measures would make sense. So, this is available both as a service and as a software solution, right?

Klaus

Exactly. We’ve already talked about the sensors. That means we install sensors at various, potentially very many, points in the customer’s infrastructure. These send their data to a central system where all anomaly information comes together. There is a central dashboard that we provide in the first step. This is the user interface of our system. On this central screen, all anomaly alerts come in, which can be analyzed in detail to derive appropriate actions. With customers who are already more advanced and have integrated the system more deeply, it often works in such a way that they no longer look directly at our dashboard. Instead, the data is forwarded to a SIEM system — a Security Information and Event Management system — that may already be in operation. There may even already be a dedicated SOC in place, where various systems are brought together. On the large screens in such rooms, the data from all security systems comes together — from firewalls, servers, and also from our anomaly detection. This allows the data to be correlated and intrusions to be detected more intelligently and quickly. Many companies are still at the very beginning of this process. But the option exists to fully integrate our alerts into such central systems.

Feel free to check out Rhebo’s website — rhebo.com. There you will find more information, and the podcast is also linked there. I personally still have many more questions, but that would probably go beyond the scope of this episode. So, to finish, I’d like to ask you one last question: the topic of security and anomaly detection is constantly evolving. Artificial intelligence is currently a big topic. Where do you see the future in this area? What should companies pay attention to? What are you working on at Rhebo in this regard? Do you have an outlook on what will become relevant in the future?

Klaus

One important topic that always concerns us at Rhebo is the question of how we can separate the relevant from the less relevant data in the flood of alerts about changes in plants — especially in large infrastructures. In the past, we mostly solved this with deterministic methods, because communication in these systems is relatively stable and deterministic. AI systems, on the other hand, work with probabilities. They recognize patterns and say with a certain probability that what is currently being observed resembles an attack they know from their database. For a long time, we said that probability statements are not sufficient for such critical systems. Depending on how you adjust an AI, it filters out certain things and classifies them as not relevant — but in hindsight, that can turn out to be a misjudgment. That’s why, for years, we have passed on this data unfiltered and invested heavily in preparing the large volume of information as intelligently as possible so that it remains manageable for humans. In the future, however, more and more AI will come into play — but as a supportive tool.

So basically, to distinguish whether it is relevant or rather irrelevant data. With AI, you could then support and say: “Take another closer look here.” Is that what you mean?

Klaus

Exactly. It works like a kind of pre-filter. Comparable to medicine: nobody wants AI to make the final diagnosis and decide whether surgery is performed or not. But it helps the doctor to recognize where to look more closely. It’s the same with us. The AI highlights certain points in the data sets, but in the end, a human still has to review everything before, for example, deciding to shut down communication to a power plant.

Thank you very much for this outlook toward the future. The time has flown by, and as I said, I still have a number of other questions. If you’re interested, feel free to get in touch with Klaus. I would also be happy to do another episode on this in the future. But for now, thank you very much for your time today. I found it very exciting. One point is still open — maybe I can add that to the show notes. You mentioned earlier that you differentiate between risks or vulnerabilities and actual attacks and incidents and hinted at something there. Maybe I can include a specific case in the show notes for that. From my side, thank you very much. Today we’ve gained a clear understanding of how you approach this topic, why it’s important, what the market drivers are, and what the top 3 use cases are. Thank you for this concrete insight! I’ll happily give you the last word if you’d like to add anything. Thank you for being here today!

Klaus

You summarized that very nicely. I also enjoyed it — it was a very lively discussion. I want to encourage all listeners to reach out and get in touch. I look forward to comments, suggestions, and exchanging ideas. And indeed, we didn’t manage to talk about the specific attack today. Maybe we’ll manage that in a future episode. Thank you for the invitation and the exciting discussion!

Very nice. Thank you, Klaus, and have a great rest of the week! Take care, bye.

Klaus

Bye!