Okay, so let's talk about one of the biggest misconceptions in OT security, which is related to the Purdue model. The Purdue model is often conceived as something like a security architecture, which in fact it is not. And what I try to explain today is that it can be absolutely counterproductive. So let's dive into that. The Purdue model's heritage is in the idea to just provide some functional guidance on how to conceive a manufacturing process as far as the digital OT and the networking is concerned. However, it does not per se have a direct link to networks and network architecture. Unfortunately that was misconstrued later on, especially by people who are more on the IT side of things rather than in OT. So you will have trouble finding an engineer who actually uses the term Purdue. That's on Purdue level zero, for example. You will have a hard time finding such an engineer. Engineers would say, "Those are the sensors, right?" And then where the RTUs are, that's that different thing, right? But they wouldn't use the terminology, or that's on Purdue layer one, for example. So why is that a misconception? Some people think that this layering as documented in the Purdue model would tell you or suggest that you would place all those different types of OT devices in different network layers. And that's nonsense. And I explain why. So you would have all the sensors and actuators in one layer. Then on the next layer, you would have the PLCs and RTUs. Then you would have the HMIs, et cetera. And why is that nonsense? There are a couple of reasons for this. So the first thing is what I think the most important takeaway that you should get from this video is the important-- or like the crown jewels when it comes to your OT, or when it comes to your cyber-physical infrastructure, is not the sensors and the actuators. It's the engineering stations. Because once you are on the engineering station, you can compromise the whole physical process. Because then from the engineering station, you can jump onto the PLCs, the RTUs, et cetera, and then you're cooked. That is what you want to focus on. If you would place additional security layers below that network segment that the engineering station happens to sit on, that wouldn't do any good. Because the engineering station will always be able to directly reach all those lower levels. So it doesn't do you any good. The other thing that most people don't understand, even if you would introduce some additional firewalls, et cetera, once that you have compromised the engineering station, you can actually-- not just by downloading a new project onto the PLCs with malicious code, as we have seen in Stuxnet, but also just as far as the communication paths are concerned, you can totally reach every lower level from the engineering station or from that network where the engineering station sits. How is that possible? It's possible by something that is called Ethernet/IP, and especially Ethernet/IP route browsing. So what does that mean? The Ethernet IP protocol comes with the capability to route into lower level networks. The CIP route browsing, which isn't even limited to Ethernet/IP, it also extends to field buses such as ControlNet, DeviceNet, SERCOS, and so on. That already gives you an idea, hmm, well, that's bad. Let's just assume I actually had placed additional firewalls between these different layers. Well, if still I can route through the layers by virtue of that layer seven protocol, then all those firewalls don't give me any security benefits. That is important to consider here. So once that this upper level, that could be layer two, it could be layer three, once that this is compromised, your engineering, excuse me, your, all your RTUs, your PLCs, your sensors and actuators can be reached as well and can be manipulated. So therefore, the idea that you would place all those additional security measures between the layers is pretty much counterproductive. Why do I say counterproductive? Because it can actually do more harm than good. And let me explain why. The whole idea to use the Purdue model would be, well, we have understood finally that OT is insecure by design. There is no authentication. There is no authorization. So therefore, we need to make heavy use of network segregation. That's a good idea. So that is a very important and valid security approach in OT. However, the Purdue model doesn't give you that. The Purdue model would suggest that you do a horizontal segregation of your network architecture. And that's nonsense. I already gave you some reasons and it goes further. So consider this. When you start your network segregation, what you want to achieve is that in case of a compromise of one specific area, other areas can continue to function so that you can localize the damage. That is what you want to achieve with network segregation. Now unfortunately, if you do that segregation horizontally, you may end up with an architecture where, let's just say, ALL your PLCs are compromised. And that means ALL production lines are stopped or even dysfunctional. You may look at the destroyed product, et cetera. So that is not what you want. You want to localize the damage. But the only way to get there is that you first do an analysis of how your OT equipment is related to process function. And then you identify, OK, these are those individual zones. This is where the zoning comes in. Where let's just say we were looking at one specific machine line. If that specific machine line is compromised, all the other machine lines will be able to continue production. This is where you want to go. And again, the only thing to get there is to make that functional analysis of your infrastructure. That cannot be done using Wireshark. That cannot be done using threat intelligence. That can only be done by your engineers telling you, OK, all that. So these PLCs, sensors, and actuators, they belong to this, let's just say work cell, for example, right, to this other functional group. And based on that, you do your network segregation strategy. I would say it gets very clear if you simply look at a network diagram using different layouts. So if you do a layout for, let's just say, one specific building. And you do the layout based on Purdue levels, which is very simple to do in OTbase, right? So you can just do your network topology. And in the layout dropdown, you select hierarchy. Bam. And then you see all those network devices and all connections based on that Purdue hierarchy. OK. And then, so imagine why you would do the segregation at that horizontal layer. And you will see immediately, well, that actually is counterproductive. Now in OTbase, you can also change the layout to a functional display, where now the layer is based on system association. And once that you do that, you can clearly see which OT devices and network gear belongs to specific work cells or machine lines. And based on that, you're going to do your segregation. So bottom line, the idea is that the Purdue model was intended or can act as a security strategy or blueprint. That is nonsense. Second, it can even be counterproductive. Don't use it for your network segregation strategy. What you should do is you should first do that functional analysis. And based on that, you implement your network segregation.
