There and Back Again: Detecting OT devices across protocol gateways

So let me introduce to to Rob Kim is this director of apply researchers. So welcome to Mexico City is the first time in besides 2025. So it's a pleasure for us that you speak that conference for in Mexico City besides 2025. So we start. So

okay we are ready. So

I forget it. I forget it. It's a tradition in Mexico City that drink meal. So, please drop continue with that traditional. [Music] Thank you so much. Testing testing.

So, this is going to be in English. I I apologize. Um, if I'm speaking too quickly or or something, please tell me. I'm happy to to slow down and uh I can speak a little bit of French if that helps, but otherwise it's going to be just in English. So there and back again discovering OT devices across protocol gateways. Well, first off, let's talk about what that even means, right? What do we what do we mean when we say OT protocols? OT in general. So it's these are terms that have lots of different definitions and all of them are different and some of them are correct and some of them are wrong. So we're going to give some

definitions and then we're going to ignore but operational technology OT that's the technology that's used to control things in the real world. So things like motors, generators, things that move and then industrial control systems are those devices that are specifically used in controlling industrial environments. So factories or x fabric and uh hey I I knew fabric was factored. Give me some credit here. And then you have supervisory control and data acquisition or SCADA. And SCADA is not a specific protocol or uh a specific technology. SCADA is an architecture of how to lay out how to use technology to control your back to control your industrial technology. But at the end of the day, everyone uses

these terms pretty much interchangeably. ICS, SCADA, all pretty much the same. But when people think about OT and ICS and SCADA, they think about this. They think about this. Looks like you're going to launch a space shuttle. Looks like you're going to land on the moon. It's super cool. All this flashy technology. Uh this in particular is the control room at a factory in Germany. Uh might be an electrical generation plant. I don't remember. But regardless, big important things, right? But really at the end of the day, what it is is this. It's the actual things that move and control systems and do important technological things. And so, how do we control them? Right? I mean, at the

beginning, it was all by hand. It was literally people like assembly lines putting stuff together and just a cog wheel moving. It was a man standing there flipping a lever up and down, keeping time. He was the brains of the operation, right? He was the programmable logic controller. But then it got a little bit more advanced. We wanted to have repetition, but more than could be achieved by just clockwork. We wanted to have a little bit more logic. And so we started adding this ladder logic to these devices. And this was just collections of relays that you could go and they were connected directly to the device that was being controlled. And you would have to walk

up to it. If you wanted to change something or check on something, you had to physically walk up to the device and push a button, read a thing, write it down on your your uh notepad, and be done. And that was still great. That was still more advanced, but it was still a hassle. You had to walk around the back, right? And so then someone said, "Well, those little lateral logic things are connected by wires. What if we just make the wires longer and put them all in one place?" And so you get this these these beautiful control rooms. Uh and this was what was called distributed control systems. So they were distributed because they were distributed across the

factory floor, but each individual valve and dial and le and switch had its own set of wires going to its own device. So it was very expensive, very uh prone to breakage, not super reliable. So then we started getting field buses and programmable logic controllers. And this is uh this is where things start to get really fun. So if anybody is really old like me, you might recognize that that is the same port that on the back of the the uh Commodore PET computers. Remember the PETs? Yeah. And so that was an HPIV port. Uh it's also known as the ILE E488 bus. And it was used originally to control laboratory instruments. So not factories, right? This was all stuff

that was on the same workbench. But what was neat about it is it was one set of wires. No matter how many devices you had, you could daisy chain. So one device would be connected to the next device connected to the next device and then you would there was a protocol that would let you selectively speak and query and command any of the devices that were connected in that chain. Um and like I said on the Commodore computers this was actually used uh for like disc drives and stuff which was pretty neat. But the benefit there was that the bus allowed one set of wires. You didn't have to have a bunch of set of wires.

You didn't have to have you didn't have to have a bunch of set of waters, right? Just the one. And then in 1979, Modicon, which ended up getting bought by Schneider Electric, invented the world's first programmable logic controller. This beautiful retro thing that I mean, I just love it. It looks so cool. But what this did was it let you have programmable logic in your industrial environment. So, logic, although it's still used. You can still program it that way. Not just simple repetition, but more complicated program. And it could control multiple devices. It wasn't just one controller for one thing. You could have multiple connections and it could talk to multiple devices across a shared system

called a bus. And the modicon bus became known as Modbus. Modbus is pretty much I wouldn't say it's the most anymore, but for a long time it was the most common industrial control protocol and it's still very common. And so these systems started letting you have much more complicated controls, much more interesting things you could do, much more automation, much less human involvement. And you can see that Modbus let you control systems with a shared bus, right? A shared medium. And also it was physical medium independence. So you can see here on the left it's talking over uh MB+ which is another kind of bus or another shared physical bus. In the middle you've got RS232 and it can only

talk to one device at a time. RS232 is the old serial standard. It's not old. It's it is old but it's also still the serial standard. And then you have Modbus over RS485 which is another daisy chain kind of bus. But the point is there was this abstraction and you can see at the top there that it's Modbus running on top of TCP. Now that did not start happening until the 2000s. But Modbus could the goal here is to explain that Modbus can run on many different physical media and control many different devices all from one they can link up the controllers. So you've got an HMI which is a human machine interface a screen controlling all these

different things. So that led to this concept of ITOT convergence which everyone just loves to say. So what happened was IT protocols like TCP IP, DNS, HTTP, all these protocols, Ethernet became commoditized. They became very cheap. It was easy to get them. And so everybody to use IT protocols for their OT networks because an Ethernet card is a lot cheaper than a custom, you know, ITE48 card. So, and also it made it easier to in uh to integrate with your existing IT network for monitoring, for checking things out, for deploying new commands. So, we got this concept of industrial Ethernet. Now, there's other kinds of convergence, but industrial Ethernet is is the big one. And

industrial Ethernet is really just Ethernet, but the devices tend to be hardened because they have to work in electrically noisy environments. There's lots of vibration. There's lots of dust, but it's still at the end of the day, it's still basically Ethernet, standard Ethernet like you have on your computer at home. But this comes with this comes with security implications. So when you start integrating with things that can that can connect to the internet that speak internet protocol IP, you start being able to talk to them over the internet. And for decades, these industrial devices were assumed to be safe because the only way to get to them, the only way to talk to them was to be at the

factory, was to be physically present. There were always some back doors, you know, a modem somewhere or something, but generally speaking, you couldn't just connect to an industrial device from halfway around the world. And so you can see here this uh this is a report that was given to the president of the United States in 20 I think 2017. But it this is just showing how many devices industrial control devices are reachable on the public internet without any sort of controls or safety. Uh and you can see the graph is staying pretty much roughly the same. It's the number of devices in the US has gone down, but the number of devices in the rest of the

world has gone up. So, it's stayed pretty much the same. This is obviously a security nightmare because OT devices control things in the real world. You could hurt someone. You could destroy, you could interrupt food production or power production. So, obviously bad. And just as a very quick example, this is a uh Ver root automated tank gauge. And this is uh actually what you would see at a gas station. And it is what's used to say how much gas is left in the tanks underground, right? And uh a colleague of mine, HD Moore, actually wrote a script to enumerate all of the publicly accessible uh ATG automated tank gauge devices in the world. And as

you can see, there are a whole lot of them. So all over the world, there's these ATG devices that are accessible without authentication. You can go in and see what kind of fuel level is there, which, you know, maybe isn't so bad, but you can also, some of these devices will let you trigger a tank flush or a maintenance cycle, and you can interrupt fuel delivery. And there's been at least a few reports of this being done in cyber warfare where they've actually disabled fuel depots for, you know, military targets. Whether that's true or not, I'm, you know, I'm not a spy, I don't know, but it makes sense to me. And it's also, as a quick

aside, these, it's funny, you can tell whether these devices are real or a honeypot by how quickly they respond. Because if you if you go back uh these devices are not very powerful, right? These are very slow, very small devices. So if you connect to one and it responds immediately, you know it's not real because it's going to be really really slow. So anyway, we were able to determine that. So this is just an example of some of the devices that I found the other day on the public internet with no authentication. So if you want to go talk to, you know, Alen Bradley PLC. It's out there on the internet and you could potentially disrupt some sort of

industrial process. Please don't. That would be bad. But you could and this is the consequence of So you can see there in this slide we've discovered these devices. So what do we mean by discovery? Well, for a long time, if you want if you had devices in your factory, you knew what you had. There were simply spreadsheets and blueprints and diagrams, and there was someone whose job it was to make sure everything that was there was actually there. So, when we talk about discovery, I'm talking about how do we discover these devices remotely over a network? How do we get these devices to divulge their secrets and tell us who they are uh without having to go physically look at it.

Right? So, first let's talk about when we're talking about the converge protocol. So, this is Modbus and as you can see the green part there is the common core of the Modbus protocol. It's extremely simple. There is a single function code and some data. And in Modbus TCP, there is a single function code and some data. On serial, you've got the uh the station ID, so the device you want to talk to, and a CRC to check things. On Modbus TCP, they just took the Modbus protocol and shoved it inside of a TCP session with a small header. This unit ID and this station ID are the same number. So really, you could have kept them green.

It's just that you don't usually need to set one in the TCP, but you still have so you have a transaction ID, a protocol ID, which is always zero, a length to show you how far it goes, and then the unit ID just like above. So when we talk about convergence, this is something that's happened with a lot of the OT protocol uh designs when they went into it, they took the protocol wholesale and just shoved it right on top. They didn't really modify it or if they did only very little. So with Modbus, Modbus was created back in 1979 which makes it a year older than me and I'm really old so it wasn't very

advanced. So you can see when they dumped it in there they literally you can see this is just another example. There's the TCP header and then there's the TCP data. There's that header, the function code and the data segment and they just shoved it all right there. And the function code is not particularly descriptive. There's not that many function codes in classic Modbus. In fact, here's an entire excuse me, here's an entire Modbus request. It's really short. It's just saying, hey, I've got a length of six. I want to do function code read input register. Give me the number that is in that register. And then there's the response. You just get the number back. There's not a lot

going on and in fact there's not really any way to identify this device directly but what and so you can see here's all the possible codes in classic Modbus all the all the possible classic function codes read a discrete input read a coil which is talking about uh thermal coils uh write coils read a register write a register nothing particularly fancy now there is this thing way down here at the bottom that looks promising this report server ID. What is that? Well, that actually only works on Modbus serial. Does not work on Modbus TCP. And all it does is tell you that my station ID is, you know, three or four or whatever. And that station ID is usually hardcoded.

Somebody goes in and actually toggles switches to set the station ID, right? So, you can't really use classic Modbus to identify a device on the network. But as Modbus became more and more popular and as it became more and more integrated with IP protocols, they pulled the same trick again. Just like how they took Modbus and more or less plopped it entirely into the data portion of a TCP session. They took this Modbus encapsulated interface transport which is almost a whole new protocol and shoved it in the Modbus data section under the uh function code 2B or not to be but um so what this does is if you get a function code of 2B and you're an

older Modbus device you just ignore it. It's just an unknown function code. You don't understand the question and you won't respond to it. But if you're a newer Modbus device, almost certainly one that speaks Modbus TCP, then you do understand that now there's a secondary op code. You can see these 14, this 13, 14, those are secondary op codes, right? An additional operation specification. And that additional operation specification, the only one that's really there is this read device information. But this read device information tells you so much more, right? You can say, "Hey, function code." So there's the function code encapsulated interface transport. So there's your mod bus function code. Then there's your MEI type. That's your

secondary function code. And you're saying I want to get extended device identification. So tell me everything you can about yourself. And the standard, this is actually standardized in the Modbus spec from 2006. So just about any recent Modbus device should speak. But as we all know, there's OT devices that are from the 90s that are still in networks. So, you know, be careful. And so, now you see we've got this extended thing. And it really is almost a whole new protocol. It's this whole objectoriented thing where you can select different things that you want to pull back. But here we're just showing you vendor name, product code, and you can see that it actually specifies quite a bit of

information that you can pull back. Vendor name, product code, version are required to be sent back. And then it's recommended that it gives you the vendor, the product name, the model name, all sorts of useful information. So you can use this to discover Modbus devices or at least determine if it's so old that it doesn't support it because you'll get an unsupported function code back if you try to do this. And so with all that, you can see here's what we get. We get, you know, this was a power control device in uh one of my colleagues basement, right? So it's fairly fancy, but it speaks Modbus and we were able to identify it remotely.

So let's move on. This is a little bit more complicated of a protocol. Remember Modbus came out 1979. The MEI stuff came out in 2006. This is distributed network protocol version three. I don't know if there was a version one. I don't know if there was a version two, but we're at version three. and distributed network protocol three very commonly used in utility distribution water electricity uh wind farms electrical substations and pretty much nowhere else from what I can tell those devices speak DMP3 and it's supposed to be this standard and it is a standard but only that industry I don't think it's very much used in industrial control I don't think there's a lot of factories that use DMP3

but DMP3 is interesting so this diagram which was taken from an official specification of the the protocol, shows just how complicated it is. DMP3 has a version that runs on TCP, which we'll get to in a second, but it was designed to run on take your pick of physical media, right? So, serial, uh, canvas, all sorts of things, and in extremely electrically noisy environments. So, we're talking electrical substations with huge magnetic fields, lots of buzzing. I don't really know how electricity works, but it's something where there's going to be a lot of error correction and there's going to be I'm sorry, a lot of errors. And so, you need a lot of error correction. So, it defines whereas

Modbus just defined a very simple here's my serial connection. I'm going to say this is the device I'm talking to and here's the message and I'm going to get one response back. DMP3 has its own entire uh link layer and session layer and application layer. So it's almost as complicated as the whole TCP stack. So at the very bottom you've got a link level connection uh link layer that actually handles check summing and error correction and then you've got a trans and addressing and then you've got a transport layer where you can actually create connectionoriented connections just like TCP and then you've got your application layer where the data actually travels along uh again just

like TCP. So extremely complicated protocol and it's a lot of fun. I I wrote a parser for this and it's once you understand what they were going for it's really quite beautiful but it's super complicated but what they did when they did when they moved DNP3 to TCP when they put it on top when they converged with it what they did was put it just take the entire protocol and stick it on top of TCP. They just took the entire session and stuck it inside a TCP session. So now what that means is every Every device that speaks DNP3 over TCP has a TCP or has an IP address, a TCP port and then also a DNP3 address. So if you connect

to a DNP3 device over TCP, it's got going to talk. It will it'll establish the TCP connection. you will have a pipe and you can send data as much as you want, but you're sending full DNP3 packets with a DN3P source address and a DN3P destination address. And if the destination address, the DMP3 destination address that you send doesn't match the DMP3 destination address of the device you're talking to, even though it could only have one because you're talking to it and it's over a TCP and you know the IP address, it won't respond. So, If you want to discover these devices, you actually have to make some educated guesses. And guessing is always hard. So

a DMP3 address is 16 bits. So 65,000 addresses more or less. And they will only speak a DMP3 device will only speak to its designated primary device. So there's no negotiation. When you configure a DMP3 device, you say your primary is at address 27 or whatever and then if it gets a message from any other DMP3 address not other than 27. So 28 1 whatever it won't respond and then you still have to guess. So if you're going to do the discovery, you have to pretend you have to spoof to be the primary address and then you have to guess its secondary address because even if you send the primary the correct primary address as the source, if you

don't have the right destination, it won't respond. So this means that so there's some good news with the addressing. Um there was actually a really interesting paper uh from some researchers in Australia where they said at the end of the day the only guaranteed way to do this is to guess all possible connections which is uh you know four billion possible combinations. That's not going to happen. But the good news is that they kind of sort of shove the addresses towards the front of the address space. So most of the time you're less than 512. But that still means that there's what 200 yeah 262,000 possible combinations to guess. So really it's not very easy. Now I have

done some reconnaissance and if you limit yourself to just you know 16 addresses or 32 addresses you can often get enough information back to figure out how they're actually doing the addressing. Like maybe they're skipping by 10 or 20 or something like that. But sometimes you don't and it's not guaranteed unless you enumerate the whole address space. Unless you do the con this uh this banner sniffing that DMP3 does and DMP3 only does this over TCP. So it's a little bit of a kind of a violation of the protocol. It's actually that's not true. It's not it does it over uh nonTCP as well but in a different way. But what will happen is these DMP3

devices, if they haven't spoken to the primary device in a while, when a connection is established from the primary device, they will send what's called an unsolicited response, which makes no sense because a response by definition should have had something to respond to, but that's what they called it. So this unsolicited response, all it really does is say yes, here are the error flags that I had. Am I in a good state? Yes or no. Is my clock in sync with yours? Yes or no? So that's, you know, it's not a lot of information, but what's good is that it's a full DNP3 packet. So it's got the source address and the destination address of the DMP3

device. So the source address will be your target and the destination address will be the address that you have to spoof, that you have to pretend to be. Um, and so this is not this doesn't happen 100% of the time, but it does happen more often than not. I'd say probably 80% of the time if you connect to a DMP3 device, you will get this unsolicited response and get enough information to do more reconnaissance. And so DMP3 once you've actually figured out the addressing that was the hard right now you've got a collection of attributes. So one of the commands in DMP3 and DMP3 has way more commands than Modbus. I could not possibly fit them on

the the slide, but one of the commands is attribute value and it's this is not quite standardized but it's pretty standardized and so if you grab these attributes nine times out of 10 99 times out of 100 you'll get what this says they are you'll get the manufacturer name you'll get the device name the serial number and all that and so by doing all that here's what we get we get this uh this DN3P out station in India that has you got you see you've got your version and you got your serial number and your host name and all that so you can discover DP3 devices. The hard part there is the uh addressing. Okay, but

now let's get to the really really cool part. This is the part that's so much fun and also so much work. So this is what you see on the screen there. That is a uh Allen Bradley Rockwell control logics rack. And so what you what we've seen is you know as you Paul, a lot of these devices at the end of the day, they're just motors and switches and valves and pumps and things. And so they're controlled very simply electrically, right? On, off, up, down, you know, again, I don't know how electricity works, but what these devices do is you've got so over there at the very first slot, you've got the PLC, you've got the actual programmable

logic controller, the computer that does the magic. Then you've got right there the second one, an Ethernet IP adapter. We'll talk about that in a second. And then you've got lots of different modules that connect to different things that are being controlled, right? So the module the PLC talks to those thing talks to those modules and says, "Hey, turn that switch on. Turn that valve off. Make that thing hotter. Make that thing colder." All that. That's how the adaptation happens. That's where sort of new meets old, right? That's where it that's where we're going back to the basics of we are actually making things move in the real world. But let's talk about that Ethernet IP adapter. So, so these these

racks have been around since before the IT convergence thing really kicked off. So, there were lots of different protocol adapters that might be there, not just Ethernet IP. And by the way, Ethernet IP is not the IP and Ethernet IP does not stand for internet protocol. Uh, which is very confusing. Ethernet IP. The IP stands for industrial protocol. So you have Ethernet IP on top of IP on top of Ethernet. It's very it the naming is terrible. But let's talk about what Ethernet IP is. So Ethernet IP is a specific adaptation of a higher level protocol called Sith CIP. So SIP is the common industrial protocol. was created by Alan Bradley later Rockwell or vice versa I

don't remember who bought who but one of them bought the other and it was originally called the control and information protocol but what SIP so SIP defines an abstract protocol it does not care what kind of wiring there is it does not care what kind of transport there is it does not care how you're doing your addressing or how the data actually gets to it defines this abstract object orient oriented uh protocol that is then adapted to different physical networks. So you've got device net which is used in uh vehicles sometimes control net componet those are both used in industrial control and then Ethernet IP. So Ethernet IP is what happens if you want to run SIP on top of TCP IP and also uh

and again because there's IP in there twice it's really confusingly named. So SIP defines it as SIP SIP defines itself by this concept of objects and messages. So every device that you're controlling will have this notional this abstract set of objects and every object there's different classes of objects. If you've ever done any object-oriented programming there are classes and instances but you can't create your own classes. These are defined by standards uh or by vendors. But each object you can send the message to the object and say give me the value of this attribute or set the value of this attribute or give me a information about this other object that you know about. So there's a way to sort of build

this tree of objects and then again once you've gotten into SIP space all that's well defined. Every class of object has its own unique identifier that's defined in the standard and every instance is just defined by number. uh some of the classes can only ever have one instance which is kind of silly but what are you gonna do but you get there v via one of those adaptations so for example with Ethernet IP so Ethernet IP is much lower level Ethernet IP is in fact you could almost imagine SIP as like the Modbus encapsulated interface and Ethernet IP as the sort of outer mod bus right so Ethernet IP supports um connections via or supports uh sending

messages simple commands via UDP and TCP. One of those is list identity and list identity tells the device to send back an Ethernet IP response. You're not actually talking SIP yet. This is still lower level. This is almost like ARC or something. You're not talking SIP yet, but it will send back a lot of information about the device and that's great. So for a lot of times for a lot of vendors who do discovery in industrial environments. This is as far as they go. And that's great. This is super cool. It will tell you everything that you can see. You can actually send a broadcast UDP Ethernet IP list identity message to an entire network

and all of the devices that speak Ethernet IP will respond and say, "Here I am. I'm, you know, here's my manufacturer name. Here's my version. Here's my uh model number." all that super cool stuff and you're done, right? Well, not quite. So, to go back, the only thing that's responding to that Ethernet IP message is that thing right there. We don't know anything about this stuff. And that's where SIP starts to come, right? Because I really want to know everything that's on my network. I want to know everything that's on my factory for I can't secure it if I don't know I have it.

Oh, and sorry. Yeah, that's what a list that's a list identity that I ran on something in my lab. It's a IO device. Super cool. There you go. It's an I only master. So, how do we decide or how do we discover things in that rack that aren't the Ethernet IP adapter, right? Because remember, the Ethernet IP message is going to stop stop at that communications adapter. So, here's a, you know, here's an example rack. You've got your Ethernet IP adapter. You've got your IP network. You've got the Ethernet IP protocol. You've got your programmable logic controller, your motor controller. You know, you've got all those little modules and they're all doing whatever it is they're doing,

making things spin, turning things on and off. Well, so each of those in the SIP protocol is required to have an identity object. So an identity object is an object that tells you what that device is. And there's a set there's a I'll show you in a minute, but there's basically a set of object or attributes it's required to have to tell you what it is. So if you go through with Ethernet IP and you connect to that Ethernet communications adapter and you establish a SIP session, so you say, "Okay, Ethernet IP, I'm going to now send you the command that says start a SIP session." And now your Ethernet IP is just carrying SIP messages. It's not

doing anything else. And then I say, "Hey, SIP, connect to your identity object." And it says, "Okay." And then I say, "Give me all the attributes of the identity object." what you get back is pretty much exactly what you got from the list identity uh the list identity command in Ethernet. It can it can give you more but it can it doesn't have to. But when things get really cool is that you can chain them. So I can say hey communications adapter a lot of those communications adapters will have a another object called a connection manager object and I can say hey Ethernet IP adapter establish a SIP session with me. It says okay and I say

hey attach or send this message to your connection manager object. It says okay and it says I want you to send a message through or I want you to use that connection manager object to establish another connection on my behalf from me through you to the next device in the chain or to the next device at this address or the next device wherever and it says okay great here's your connection and now anytime I send something to that connection it forwards all the way through and I can say hey I want to connect to the identity object of that thing on the other side and get all of its attributes and learn what it is and discover that device and SIP lets

you do this in again a almost protocol agnostic way. So this, you know, I'm connecting here to that first connection manager via Ethernet IP with an IP address and TCP and UDP and all that my my integrated converge network. But then this connection back here, it does I don't know what it is and I don't care more or less. It could be the back plane of that rack. It could be theoretically a serial connection. It could be canvas. It could be a whole other Ethernet network with its own addressing scheme and I wouldn't even know or care except that I do have to care a little bit which is very frustrating but we'll get to that in a second. So

um so you can see that you have to this is where you do actually have to care a little bit when you're specifying the connection that you want to establish. you're specifying how you want to get to the next object uh the next uh uh SIP object in the the network, you have to specify it via hops. You have to say, "Hey, forward this message." So, I'm gonna I give it a uh route path. So, if you've ever uh if you remember source routing from way back in the day with IP where it caused all sorts of huge problems because you could spoof networks and uh get to places you shouldn't be. It was super fun. It's essentially the same

thing. So you can say, hey, give me the route path. And in this case, you specify back plane and then you specify address 11 or whatever. So I want to talk to the 12th slot because it starts at zero. So I want to talk to the 12th slot. And you have to sp it's a long complicated bit of math that you got to specify because different address things are different lengths and different sizes. Some are 8 bit, some are 16 bit, some are 32bit. It's a pain in the butt, but ultimately you can generally get away with just saying, you know, back plane address or Ethernet connection IP address, which is kind of fun because

now you're forwarding across multiple uh multiple networks. But once you do that, you've connected to that device on the other side. There we go. And so once you've done that, you can walk the back plane. You can actually discover all of the devices that are there. And so you can see here's just this is just JSON but you can see that I've got my I'm talking to my Ethernet IP adapter and it's a Rockwell Al Bradley and then I've got a general purpose discrete IO and it's specifically a 24 volts uh direct current 16 whatever whatever output and then I've got an RS232 serial connection. And so I've discovered all those things. None of those things speak

Ethernet IP. None of those things speak IP internet protocol IP either. So the The only way to discover them is to actually go through these protocol gateways, go through these adapters. And so that Oh, I thought I had one more slide. Okay, so that's it. That's how you discover things across protocol gateways. Um, any any questions? Somebody can translate.

>> So I am starting in OT security. So do you have any recommendations like a book or a certification about OT and start to you know learn the basics before applying cyber security to it? >> So first off good luck. Congratulations. You're going to have a lot of fun. Um and So the biggest problem with OT security in my opinion is that so many of the standards and so much of the hardware is difficult to get. Um you have to speak to specific vendors. They won't sell it to you. A lot of the Rockwell, so all of those racks that I was showing you were Rockwell racks. A lot of those Rockwell racks are um

you you basically can't get them anywhere else. There's no simulators. you got to pay for it, which kind of is, you know, no fun. There is a new uh there's a Raspberry Pi, I think it's called Pi PLC, PI PLC, and it's a Raspberry Pi that actually looks almost like one of those little modules that you could put in the Rockwell rack and it's hardened and it's designed to work in industrial environments. It runs Linux, but it speaks a lot of these industrial protocols and they're not super expensive. Um, so I mean like they're really cheap compared to the training kits and everything. So that might be a good place to start. Um, there's also a fair number of simulators

for a lot of different systems. Um, the I've got a DMP3 simulator that it only works for 30 minutes at a time, but 30 minutes, but you know, then all you got to do is reboot. You do it, you know, you got more 30 30 more minutes. It's great, you know. So, um, you should totally pay for it. Totally pay for software. you know what I mean? Um, and then all of the major OT vendors offer training kits, but they get expensive. So, there are um there are companies that will rent them out to you, so you don't get to keep them forever, or there are companies where you can actually rent lab time and go to their lab. Uh, I

don't know about any in Mexico City, but I'm sure there's got to be at least one. So, this is the biggest city in in North America, so you know, there's got to be one. >> Yeah. Awesome. Thank Thanks for sharing your knowledge. >> No, no, thank you. Other other question now. So, thank you so much, Rob, for your presentation. We appreciate your participation. That was very interesting. That was a lot of information for us. So, thank you so much. Thank you everybody. Thank you.

in the conferencia.