Klaus Mochalski
Hello and welcome to a new episode of OT Security Made Simple. I'm Klaus Mochalski, founder of Rhebo. My guest today is Klaus Kilvinger from Opexa. Please introduce yourself to our listeners.
Klaus Kilvinger
Hello Klaus, thank you for the invitation. Yes, Klaus Kilvinger from Opexa Advisory in Munich, Germany. We are active in the field of information security management and advise our customers on how to implement these systems in their companies in such a way that they bring the greatest possible benefit to them.
Klaus Mochalski
We had agreed in advance that we wanted to talk about ISO 27001 today. This is a topic that every medium-sized to large organization has dealt with at least once, and many may have obtained certification.
Now we're talking about OT security, and my first reaction was: ISO 27001 has nothing to do with OT security. At least, it's rarely discussed in that context. OT security is a relatively new topic. ISO 27001 is an ancient specification.
Tell us why it does have something to do with OT security. And then, I think it's also very important for our listeners that we conclude the podcast by discussing which aspects are particularly important here. But first, let's start with the general statement: [ISO 27001] has nothing to do with OT security.
Klaus Kilvinger
Yes, I'll elaborate a little. So what is the basis of the idea? A standard is always an agreement between experts to address a specific issue that would be a possible solution to problems for a certain segment of an industry, a technology, or a topic. On this basis, the foundation for 27001 was laid in England back in 1999. Later, this English standardization system was transferred to the international standardization system. The last English version was [at that time] from 2013. As you can see, it's quite old in principle. The latest version is from 2022. Of course, it also includes many current developments.
The basic idea behind the 27001 standard is to have an information security management system, i.e., not to view the system as a technical entity, but rather as a set of interrelated rules — such as guidelines, processes, minimum requirements, and tools — to ensure that security can be implemented in the company with the three basic objectives of confidentiality, integrity, and availability.
ISO 27001 does not ask: Is it an office system? Is it OT? Is it production? Is it logistics? It is an open standard. You can use it wherever you want, and it is not sector-specific. But of course, you now have the fundamental issue that a non-sector-specific standard is supposed to save the world in a specific environment.
This means that it is designed to set open requirements. The entire document is relatively short. ISO 27001, which I have open in the background, currently has only 27 pages in total. 27 pages, while the new AI standard, ISO 42001, has over 50 pages for comparison. The classic ISO 9001 [for quality management systems] has less than 20 pages. As you can see, there are different interpretation issues and different content. I'll just give you two examples to make that a little clearer.
Klaus Mochalski
Before we get to the examples, just a quick note. ISO 27001 is a fairly straightforward standard. If you're not familiar with it, you might be overwhelmed when you hear how complex the implementation processes are. That said, we definitely recommend taking a look at the document and reading through it. It's quite doable.
And the terms you just mentioned, which are relevant here, especially the information security management system, sound very familiar to someone who deals with OT security. And the regulations we have for critical infrastructure, for example, also require information security management. And I think that's exactly where the overlap comes in.
And now I think it would be interesting for our listeners to see what added value I get for OT security when I implement ISO 27001 in my company. [...]
Klaus Kilvinger
We see the added value in three areas. The first area is that when I implement 27001 in a company, I ideally implement it throughout the entire company. This means that specialists from production engineering, network technology, industrial communication, and specialists who are active in the company network all have the advantage of being able to discuss the following question together: “How do I make our company secure? How do I ensure that the business will be up and running tomorrow?”
To put it bluntly, I have a customer who, for example, introduced TISAX—a derivative of ISO 27001 in the automotive environment—because he said, "It's good to have the system in place at our company. I have 300 trucks in the yard every day. If things come to a standstill, they either stay inside and can't get out because we can't deliver anything, or the others can't get in because I can't unload them." This means that logistics, production, office, and administration work closely together. That's the first advantage.
The second advantage is that we have a general requirements specification. I'll come to the requirements in a moment.
The third advantage is that I can certify something like this. This means that I can have the application of ISO 27001 certified by a third party, by a professional auditor who must be separately certified as an auditor by the relevant auditing organizations. We can then use this as a selling point to show that our company applies this standard and thus generates a high level of security.
So that's the three areas where I see profitability. Let's take a requirement as an example.
Klaus Mochalski
Quick question about that. The last advantage you mention is that you can get certified. That means you can get the seal of approval that you've done your homework. When it comes to OT security and I am an organization that works in automated manufacturing and naturally operates OT systems there, how much OT security do I get from the correct implementation and certification of ISO 27001? Have I covered 50% of the ground or perhaps even 100%? What is your assessment?
Klaus Kilvinger
Initially, there is only one general requirement. [...]
The standard essentially consists of two parts. At the top, there is a normative section that deals with processes, responsibilities, and the context of the company. How are these supported? What do I need to do in operational terms? This can still be discussed in a relatively pragmatic way in many companies, but of course it is not yet focused on a single point.
There are 93 requirements in the appendix to the standards. These 93 requirements are in turn divided into four segments. One of these is technological measures, and requirement 8.7, for example, deals with the topic of protection against malware. And that is neutral. I have the same thing in OT or in other systems. And the standard only says: A measure must be taken, and, I quote: “Protection against malware shall be implemented and supported by appropriate user awareness.”
Now, you always have to read standards word for word. That means protection against malware must be implemented. This means that I have to implement protection against malware either physically, logically, or however else – either I have software installed or I have mechanical parts, or perhaps I have a plug that I can pull out – so that malware cannot get in at all.
The standard only says that I have to do something about it. Whether the criticality of your system then means increased effort – because you say: “Hey, these are the crown jewels. If that doesn't work, our entire production comes to a standstill. We can't leave 100 people standing at the assembly line here,” you then have to discuss that with the OT experts. We say, “Hey, can I create security here with network segmentation? Can I perhaps use a system where I update the patches?”
We see time and time again in vulnerability assessments that companies do not update their patches properly. They put it off: “I'll do it sometime.” Eventually, it gets forgotten. This means that there are also processes that are needed to keep updates up to date. When I read in the standard: “Protection against malware shall be implemented,” it's relatively simple. Then I look at the company: “How do I do that in office IT, for example? How do I do that with servers, routers, other products, the firewall? And then I also look at the OT to see which systems are at risk. Where can I avoid the relevant malware or where can I avoid it organizationally?”
There is always the question: “Where can I avoid it technically or where can I support it organizationally?” If I have an old Windows 96 computer for which there are no more patches, I have to think of something else. I'll probably have to physically disconnect it because I say I can't take any risks with it. I can't take it out. There is no longer any updated protection software for it.
Klaus Mochalski
Like so many standards, this one essentially tells me what I have to do, but not how I have to do it. This means that I am not only free to choose, but – and this is probably an important part of implementation in most cases – I can select different measures in different areas of my company to meet the requirements. These measures then also correspond to the specific circumstances, for example protecting my servers or my cloud infrastructure. In terms of malware, there are probably different things to do than with my 20-year-old unpatchable controllers and the old Windows system you mentioned.
Klaus Kilvinger
Exactly. And that's why I can also apply the standard in the manufacturing area. We repeatedly encounter companies where we conduct on-site inspections and find huge cabinets with lots of cables. Then I ask, “Who has the wiring plan here?” [And the answer is:] “We don't know exactly yet, we still have to follow up on that.” It's not because the colleagues are incompetent. They could do it all, but of course they have other priorities. They have to make sure the business runs smoothly. They want to ensure that production continues, and they try to keep administration to a minimum.
These are all understandable goals, and there's nothing wrong with them at first glance. But what do I do if something goes wrong? If the colleague who did the cabling is on vacation or retired, who knows how everything works? This means that sometimes it's just mundane issues such as administration, organization, and documentation that fall by the wayside because employees are focused on other things and say, “I'll do the administrative stuff later.” But being well organized and documenting things are also part of the job. The same goes for issues such as malware, where people say, “I do that in administration, I do that in production, I do that on the machine.”
When we then show the auditor, “Look, this is the goal! And we'll solve that with these items!”, he says, “Okay, you've given us an answer.” The standard can't go into detail. Every year there are a thousand new protocols, a thousand new malware issues. The standard can't keep up that fast. That's why we have to talk to the experts in production and say: "What security measures do you have in place for this system? What does the manufacturer offer, for example? What can I do myself?" And that's where the standard is very flexible.
So don't be afraid of the standard, it doesn't hurt. It just forces you to ask yourself: “Have I done my homework? Have I done anything [against] malware? If so, have I documented it? Is it currently stored in a system where I can see the whole thing? Check.”
And then the second point: Appropriate user awareness. That means I also have to look at who operates the machine, who controls it, who takes care of updates, and what the operating team is like. Are they all jolly people who try to access the Internet from the machine, plug their laptops in somewhere, or let other people plug in USB sticks without knowing what's on them?
So here, too, the second part is about raising awareness among employees. Not because they are now supposed to become cybersecurity experts, but because you simply need to cover the basics. So that you can say: “I don't do that! And if I'm not sure, who can I ask?”
Klaus Mochalski
Yes, that's a good point you make there. At first glance, the standard seems to be very well suited to the OT security sector. We know that many OT-specific standards are based on ISO 27001 and go into more detail in certain areas. With regard to ISO 27001, are there any possible counterarguments from OT infrastructure operators who might say: “ISO 27001 is not suitable for my environment because it requires things that I cannot implement”? You already mentioned that in OT infrastructures, availability and keeping production running are often the top priorities. Goals such as data protection take a back seat. Do these specific requirements mean that I cannot apply ISO 27001 in certain areas?
Klaus Kilvinger
Non-applicability is a myth. We have two major levers we can use here.
Firstly, you always have a risk-based approach. In other words, I don't have to do anything for systems that don't pose a risk. But then I have to be clear: What is my risk? Is it big or small? How many people are affected? Which location? What size? What production? First, I have to think about it myself: What risk am I taking here by declaring the standard inapplicable? And you have the option of discussing a scope with the auditor and saying: “Look, the standard only applies to production in site 1 in Fulda, for example. We're not that far yet in site 2 in Leipzig, so I can't apply it there yet. We'll work towards that first. We'll just do one scope for this location for now. Then we're good, we've done our homework, we have modern machines, everything is fine. And we'll take the other location out of the scope, so it's not included."
This means you have levers – risk on the one hand and scoping on the other – that help you make the whole thing applicable.
Klaus Mochalski
Okay, so it's very, very important to understand that there is no reason to reject ISO 27001 in the OT sector. And here, once again, to provide positive arguments. We had already started talking about the appendix and the 93 points it contains. Among other things, you mentioned malware, which is of course a huge topic in OT and one that is frequently discussed. You showed how the requirements of ISO 27001 can be implemented in the OT sector.
What other aspects are there? [...] We've actually talked about three examples, and with all three that you mentioned, I immediately said, “Man, we talk about that all the time in OT." What are some other good examples?
Klaus Kilvinger
These requirements in the appendix are initially formulated in general terms, for example in requirement 8.8. This concerns the handling of technical vulnerabilities. Technical vulnerabilities are everywhere. Every system has its own vulnerabilities – old systems, new systems, and so on. And with every Microsoft Patch Day, new vulnerabilities may be introduced and old ones closed.
Of course, this is something that can also be held against software development when talking about processes. In software development – and this applies to OT as well – it is often the case that, as part of software development, code segments are sometimes addressed that do not initially contain any “contaminants” or potential vulnerabilities, but that, in the course of development – over the years – other code segments are added, others are addressed, and others are dropped. The systems are alive! And that's why the question is always: What specific pool of vulnerabilities do I have in front of me?
And here, section 8.8 says: Handling vulnerabilities, I'll quote briefly: “Information about technical vulnerabilities of information systems in use should be obtained, the organisations exposure to such vulnerabilities should be evaluated and appropriate measures should be taken.” This means that if you now have a zoo of 100 different machines that are over 30 years old and represent different elements of development and production, then you might start by gathering information from the machine – in this case, machine one – which is now five years old. What information does the manufacturer provide? What is in the manual? What topics does the manufacturer cover? What has the operator learned? What has the programmer learned? What have we changed there?
And that changes all the time. Let's say a company has 100 different software solutions in different areas – maybe 30 in administration, 70 in OT – they have different systems. One has an Italian grinding machine, another has a Swiss drilling machine, and then there's the Swiss robot. Everyone has their own environment and their own risks. That means opening up the hood and asking: “Okay, what are the risks associated with this machine? What does the manufacturer say? What should not be done?”
I need a structural idea for that! How do I manage something like that? How do I document it? Do I go through everything once a month and look at all the manufacturers and ask, “What's new?” So this structural measure is, on the one hand, what you should do or where you say, “I'll subscribe to the manufacturer's newsletter so they send me the latest news . Then I don't have to search for it myself."
So this compilation of vulnerabilities is a very important point to start with. In OT, just like in normal IT, this is something that nobody likes to do. But it has to be done. Or you can google the manufacturer once a month: What was there? Or in the media: What's in Heise? What's in production magazines? And so on.
Then there's the issue of risk. Again, the question is: "What is my risk? If there is a high risk for machine A, it may not be relevant at all for machine B. Okay, check. I can rule that out.” Then I have to determine my risk and then I can say: "I have to do something here and I don't have to do anything there. That's good, I've already done 50% of the work. Okay, check."
And then take measures, which means:
- perhaps set up network segmentation or
- take the machine off the network or
- even switch off the machine.
Maybe the issue is so serious that I can't solve it at the moment because even the manufacturer says: "Hmpf, we really don't have a solution for that! The machine is now out of production. We're only in the maintenance phase. We'll have to see what we can do." And then you have to consider in OT: Can I find a workaround? Can I find another solution somewhere that will allow me to use the machine?
So, in this case, the standard does not specify exactly what you have to do. But you have to consider what your problem is and how you can tackle it.
Klaus Mochalski
Yes, it sounds very familiar again and like things you've been hearing in OT for years, as best practices, so to speak. The only aspect I stumble over here is obtaining information, because that can sometimes be difficult in OT. Because I may not be able to contact my manufacturer about this anymore. Because they may no longer exist. Because the component is no longer being maintained. There are many different reasons.
But I think even then you can... [The standard] doesn't say what obtaining means. That I contact the manufacturer, which I may not be able to do. Instead, I have to get support. Maybe someone else has already checked this machine for vulnerabilities, and I have third-party information, but that can also be solved.
Klaus Kilvinger
That depends a little on the problem. How do I do that? For example, ISO 27001 requires me to regularly review my information security management system. “Regularly” in the wording of the standard does not mean checking every five minutes to see if anything has changed. But at least once a year, I should go through all the chapters: Has anything changed here? Has anything changed there? And then I can also say in the OT: I check once a year to see if anything has changed with the machines. And then someone has to sit down and look through the fleet.
If I don't do that, I run the risk of only checking when something goes wrong. And then I have to check anyway. This means that this proactive measure is intended to ensure that you don't miss the patch day that came up somewhere. [Because often you hear:] "Yes, we've postponed it because we couldn't take the machine off the network in production. It had to run for 24 days straight. If I had patched it, I would have had to take another break and take it off the network. I didn't have the time in production. This can potentially disrupt normal manufacturing processes because I have to update a machine."
And of course, I want to avoid that by taking a structural measure where I say, ”Okay, once a year, we'll check every machine to see if anything has happened.” In 50% of cases, nothing will probably have changed, so we can tick that box. But then I know [for sure that] nothing has changed. Then I can sleep well. Maybe something has changed in 25% of cases, in the sense of: “Update coming on January 1, 2026, we have to comply with the new machine regulations, we have to...” Then you already know that something is coming, and you can prepare for it. And the other point is: “Oops, I have to do something with 25% of the machines.” And setting this process in motion is also partly a mindset where you just say, “I have to make sure that the place always stays up to date.”
Just like you take your car in for inspection and then want new brake fluid every two years so you don't get a nasty surprise when you brake, it's the same with machines. You have your inspection there too. The inspector comes by and maybe checks some devices. Then the maintenance technician comes by.
All these issues should be packed into an organizational framework. An information security management system can help you document this so that you know: “Okay, I've done this and that for requirement 8.8 on vulnerabilities. That's the result. Check.”
Klaus Mochalski
It's clear that you've been working in this field for many years and that the proactive approach is particularly important to you. That means not just getting the seal of approval initially, but then working continuously and proactively on further implementation.
In summary, what would you recommend to our listeners who come from OT security? What is the main benefit of implementing ISO 27001 and getting certified? And how do I go about it? How do I get started? What are the first steps?
Klaus Kilvinger
The main benefit is that you establish a structure for ensuring security. The basic idea behind this is that if I don't proactively deal with how to organize things, the system will eventually force me to organize myself when something goes wrong. And then I won't have time.
Klaus Mochalski
And as I understand it, it's cross-organizational. That means it affects all areas of the company. I'm no longer just responsible for IT, OT, and administration, but automatically take care of all areas.
Klaus Kilvinger
If I have network vulnerabilities that could potentially spill over from administration into my manufacturing organization, I'm not having fun. Vice versa, the guys over there aren't having fun either. So that means we should always pursue the idea: “Hey, we want the entire company to be secure, we want everything to be available, we want the data to be correct, and we want it to be confidential so that no production data goes to third parties who then build the same machine as we do.”
Klaus Mochalski
Absolutely, that makes perfect sense. And just briefly to conclude: what's the first step for newcomers?
Klaus Kilvinger
First step for newcomers: Start by conducting a gap analysis. Take the standard and ask yourself: “What have we already done? There are already some things that are being done. I don't have to do those again.”
And please, no electronic data graveyards with Excel charts and documents. Find a proper system, a Wiki, where you can store this information, and not a data graveyard on SharePoint or in Explorer. You will never look at it again, and neither will anyone else. You will have to work with this topic more frequently in the future because updates will come and so on and so forth.
And build an organization that looks forward from the outset, not backward.
Klaus Mochalski
Great, thank you very much. So, a strong plea for proactive implementation of security certification. I believe that this is very, very important for all areas, especially for the OT sector. Thank you very much. That was a very good insight. I think the discussion also provided a lot of useful information for our listeners who are not so familiar with ISO 27001. Thank you, Klaus.
Klaus Kilvinger
Until the next time. Cheers.
Klaus Mochalski
Cheers.
