And hopefully this will be an informative session. I hate standing behind a podium normally. I like walk around when I'm talking. So this is going to try. He's going to walk and I'll talk a little bit and then we'll switch.

All right. This is a little bit easier for me because I have to pay some a little ADHD.

So what we're talking about is essentially using, we're trying to take a technology that we basically developed for the US government, US military, and our first commercial targets were in the ICS space. And the reason is because it's a similar use case. You have absolutely critical infrastructure that absolutely has to be protected.

You have some things that cannot go down and you can't load software on them and you can't look at the network traffic and you can't do any of those things because we have a lot of this big divide between the focus of the OT, which is safety and security and availability of the system, and the focus of IT, which is trying to prevent compromises and breaches.

And after, so I have a long, weird history. I won't go through the whole thing, but I spent, oh, that started as an engineer back in the 1990s. I took a detour through the FBI for 11 years as a special agent working mostly in cyber division and that type of stuff. And then I became a consultant mostly back to the government and did a lot of critical infrastructure protection

cyber events in an effort to help people talk more intelligently about risk decisions. And IT and OT divide was a big part of my consulting business back in the day because this difference between how people view things. I mean, there's lots of different things

you can go into about the psychological differences of how IT folks tend to think abstractly in terms of things like IP addresses and MAC addresses. OT guys tend to think concretely and things like mechanical processes and switches and all the way through to the

difference between a focus heavily on confidentiality and a focus almost entirely on availability and integrity, right? So can we go to the next one? Next one. There you go. So the problem is, of course, there's a shared deployment. In the old days, the OT and the

Modbus, serial ports, things like that, and IT was IP address, Ethernet, and they just didn't have a big connection. But now everything, including the Modbus, has gone to Ethernet as well,

and there's even wireless products that can be IP-based as well. And we have this problem essentially of we have to make some decisions about systems that the folks who traditionally do IT technology don't necessarily understand what the system is doing or how to judge the

context in which it's operating. So yeah, let me get to the last point that Jim was talking about. So there's been a lot of emphasis on using machine learning for security. And one of the main problems we have with machine learning is that, you know, that is the ground truth, which is when you're training your machine learning, you have to make sure whatever you claim is

good is actually good, and whatever you claim is malicious is actually malicious. And there is a very blurry line between the two. So coming up with that ground truth in the first place is very, very difficult. And the last one, when we talk about the endpoint paradox, is that most of the endpoint protection relies on actually installing agents on the devices

themselves. And of course, you need that endpoint information for context. If you're just looking at the network and you see a packet going through, you don't know what it did. You know, did it deploy? Did it do something bad to it? You don't know. You need to have that endpoint

context to really understand what's going on with your network, with your whole system. But in order to get that context, usually you need to install an agent in the endpoint itself, which means that it's a little bit like asking, you know, the fox, how many chickens are in the henhouse? Because the moment somebody compromises that endpoint, that they can make the agent lie to you. So we have that paradox that we call it, because

you need to rely on the endpoint, but you cannot trust it. All right. So a lot of the things that people do today, which are trying to separate the systems from the internet, good. Patching, good, but difficult if you've separated the system

from the internet. Using these kind of traditional IT systems, they're all things that are necessary, but not complete, right? They don't actually solve the essential problem. They also don't necessarily solve the fundamental insider problem that everybody kind of understands,

they now face. With this, you know, sorry. Sorry. Let me go back to Carlos, because there was something about the limited operations that he put on here, wasn't sure about. Right. Yeah. So like Jim said, IT and OT are very different. Most of the time,

when you talk about security, you bring the things that we learn in the IT world, we try to jam them into the OT world, and they're very different worlds. There's one quick example that, you know, for Windows updates, the best time to do it is on a Sunday at 2 a.m. in the morning when it's not disrupting anybody.

That would be the absolute worst time to do it in an OT system, because if something goes wrong, you want to have everybody looking at it so they can take action. So they're very, very different. And when you try to jam the security solutions from IT into the OT, you leave some systems vulnerable, because not all of them can be deployed. So you have, in addition to that, a lot of the operational requirements that are very strict,

they're very different from OT systems. You have embedded systems, you have legacy devices, you have a broad variety of platforms that have to interact, and where reliability is king. So it makes it really difficult to use the things that we have learned in the IT world

to directly just apply them in the OT. So yeah, that's what we were trying to say in this one. Yeah, and to that end, I kind of remembered, I sort of blanked there for a second, but I had an interesting two different consulting engagements, and of course I can't mention the companies involved, but both of them were utilities. And one of the utility proudly said,

we solve all of our problems with air gaps. And then they went on to describe their, I said, okay, so it's truly air gapped. And they said, yeah, absolutely air gapped. This is a power supply system. I said, okay, so you're billing of the energy, right? How does that get to

your billing department? They said, oh, well, it just goes through the firewall and the MPLS to the business system. But that's not an air gap. No, it's like an air gap, but it's not an air gap. And it was just kind of funny that we, as we were having this discussion, they really genuinely truly thought they had air gapped the system by putting a

firewall and MPLS through the firewall. I had another company that really truly, they were, as far as I could tell, air gapped, right? They had completely severed any IP connection into the system. Cool. How do you update the firmware? Oh, we go over to the internet machine, download the firmware, put it on thumb drive, walk over to the machine and load

it. Okay. Technically an air gap, but obviously another vector. And since they had no other software on the system to protect it or any other device to protect it because, hey, we're air gapped, what could possibly go wrong? They were doing that, which post ducks net, everybody knows it doesn't work. So what we're looking at instead is something

a little bit different. So the challenge here of course is to put something that doesn't require loading software, interrupting the network, or it could possibly become a point of failure for the entire system. So PFPs, what we've been researching and doing for quite some time in

the government space is looking at side channel analysis. Now everybody in the conference has heard somebody talk about side channel analysis, talking about reading RSA keys or breaking or doing bad things to a system, but we're kind of the other side of this, which is we want to use the same process. We want to look at tiny fluctuations on either the power or the EM emissions

to determine what the state of the system is. If it's in a known good state, a known bad state, or an unknown state, which in this type of application should be considered bad. So if you think about the power plane inside of an electrical device, like our badges and

everything like that, each time a processor, microcontroller, whatever has to make an operation, has to do something at a clock cycle, even if it's negligible, it has to reach in that power plane, it has to pull some power out. So if you think about that as a very still crystal

lake, like Lake Tahoe in the summer, it looks really clear you almost don't want to touch it, because as soon as you touch it, you're going to create ripples. Those ripples are going to go on smaller and smaller indefinitely. If you think about a deterministic process like an industrial control system reaching in, dipping into that power plane over and over again,

it creates very pattern, patternistic is not a word I'm sure, but deterministic patterns of waves on that plane. So we're using, usually in EM in these cases, and we'll talk about why, we're using that along with some signal processing and machine learning to basically

identify in time and frequency space, what are those things that are important between the different operating states, and then outputting a statistical fit of what state you're in, the machine thinks you're in, and how confident it is in that state. Is there anything you want to add? No, no, that's really it. There's a lot of signal processing involved, so when we

start talking to people about side channels and transforms and wavelet transforms and things like that, often the traditional cyber people, they have a little hard time wrapping their heads around it, but in principle it's very, very straightforward. When you have a digital device, you're flipping bits from one to zero to one, and the more bits they flip in every clock cycle,

the more energy you need to flip those bits. So as you're executing your logic, you're flipping more or less bits that give you this very tiny but very unique pattern that depends on both the hardware and the software. And that's the one we're going, the people doing side channel attacks, they go after that to steal information, we're flipping it around and we're using it to make sure that nobody has modified the

logic in your device. Oh yeah, this is the slide, the next slide, you will see in a minute, is one that for some reason takes a long time to load on this computer. But let me talk about it a little bit while this one loads. Oh yeah, sure.

So the training right now, and actually the our current setup is actually based, so I should probably have him talk about it more, but the machine learning training, we got a couple of different paths. One is the original machine learning algorithms that

Carlos, as part of his PhD work, developed some time back, and that has been developed into what we're currently using. I'm also doing some work now in deep learning convolutional neural networks to do the same thing, so less signal processing up front, more deep learning, which obviously takes more processing power, but can get better

separation in some odd cases, some difficult cases, but that's still kind of under development. But Carlos can talk more about his work. Yeah, so this was my background is in communications, I used to work with software defined radios, and the origin of the technology,

it was looking at how to help regulatory bodies certify software defined radios and enforce those certifications. When the FCC tests a new radio and puts a stamp of approval that can be sold, they certify a specific hardware or a specific software, it's a pair, and if you change either one of them, you have to go getting retested to get recertified. But they never said how they

were going to enforce that, so that was part of the work that we were doing in figuring out how can we help, how can we detect that either one of them has changed. Of course, we looked at such channels, they worked, and the application for cybersecurity was straightforward. In terms of the training, we have a battery, like Jim was saying,

we have a battery of different machine learning algorithms, and they go from the traditional, the support vector machines, random forests, just Bayes classifiers, and we're doing a lot of work lately with deep learning, and just giving really good results. And all of them work in different cases, so we have a battery of them, we do a lot of feature extraction ahead

of time, a lot of signal processing to clean the signals, synchronize them, and clean them up, and then we pass them to the classifiers. A lot of our work is part of a DARPA project on using AI to classify signals in different areas has fed this, so we're kind of finding

what are the best things to work on different use cases, because different machine models have different accuracies depending upon the signal, different parts of the signal. In fact, we still don't fundamentally understand why some things work better, and that's part of what we're doing now as fundamental research is can we figure out why certain machine learning

algorithms work better on certain types of signals and not on others, and there's still a lot of fundamental questions to be answered about that. So we finally loaded the slide, and one of the things that when we tell people that we look at side channels, a PFP stands for power fingerprinting. We often look at power consumption of the devices. People often

think, oh, let me see the level of power in my cell phone, like the battery indicator, and that's not what we look at. We look at tiny, tiny patterns. This is what they look like. This is one of the traces from a PLC, actually. This is what they actually look like, and if you see the picture of the chip, the emissions radiating directly from the

silicon. This is part of the fundamental physics of the semiconductor state. As you're moving electrons around, they generate those fields, and those are the ones that we're picking up, because we tell people often, oh, we're looking at power. How are you looking at how much, you know, what if I turn my screen on, or what if I turn a fan that's going to mess you up?

No, we're looking at the emissions directly from the processor that is executing your logic. So it's a different concept. No packets, no system calls. Yeah. And one of the things about this part right here, so if you go see our demo in the

next area, you'll see that we have a very tiny little loop antenna. That little loop antenna is mostly going to pick up, because the question commonly comes up, well, isn't that subject to a whole lot of noise? But the type of probe that you'll see there is mostly picking up the magnetic component of the EM emissions, right? So it doesn't, that drops

off very rapidly with distance, so it's much, you know, more accurate when we use the EM. We also have some demos where there were some installed on the wall where you see it's using DC power, which is also pretty good, not always in an ICS if it's end line, because then potentially we could become a point of failure for the system, but the EM is really,

really good and works well in a noisy environment, because we're mostly measuring that, the magnetic field component of the EM field. So we talked already about side channel attacks, and the Tempest, you probably guys are familiar with, the Tempest was designed

specifically for those side channels. So when we, you know, if you're familiar with those, you know, that they haven't used for decades to extract this information, which is using it in a slightly different way, and if you see the racks and stuff that goes in there for a Tempest system, that's what you have to do to prevent the signal from leaking out. Oh, go ahead.

Right. Whether it's malicious or not. That's right. So basically that would be the case of

jamming, right? If somebody would be jamming you with a magnet or with anything else. So you would see it. You would see, oh, there's this big jam, and we will flag it, and somebody would have to go look at it, but it would be very obvious that you're being jammed in the signal. That's true. That's true. They could be just working with magnets.

Right. It is possible, but it's very unlikely. So we actually were doing some tests in a substation. They have these big, massive, massive transformers right next to it, and you can see

that, you know, there's this huge electromagnetic field surrounded, and actually when you go there, they ask you, no metal, you have to put your suit to be able to get there, and this will work just fine. Because, you know, at that point it becomes, you increase a little bit the

noise, and the signals come at different spectral bands, so you can filter those fairly easily. And if somebody, let's say, if somebody were going to be playing with a magnet right next to your device and doing things like, you know, several kilohertz moving it, well, that could probably, you know, impact us, but very unlikely. Yeah, a static magnet, the delta of the,

or the change from moment to moment of the magnetic field isn't going to really register. It's the delta. So if you're moving the magnet rapidly in and out, if you do it, you know, 10,000 times a second, then it would definitely make a field. And a lot of the magnetic fields we would be around might be static. Yeah. Yeah, I mean, exactly. It is potentially there.

That's part of the reason when you're doing the baseline, the machine learning, you should do it as much as possible in the environment in which it's going to be deployed, so as close to that environment as possible, so that the machine can already learn what the ambient noise that it might pick up looks like. Integrity assessments, again, what we're essentially

doing is trying to look at, once we have built a model of it, we're looking through those side channel patterns, we have our baseline, we measure distance from the baseline to what we're seeing right now, and then give you a confidence level out of,

this is the state I'm in, this is my confidence level, if the confidence level gets too far outside of what is acceptable, then, and it doesn't match any other state, then it's an anomaly. And I don't know what it is, I can't help you figure that out, but I can absolutely tell you that it's not operating exactly the same way. It could be because an electrical failure, it could be because somebody's doing something with electromagnetic fields nearby. I don't know

what it is, I just know I'm not in the right operating condition that you expect me to be in. Okay. This one I have to turn over to Carlos. So there's two ways in which we normally do the training. The way that we prefer is when we do the supervised learning,

and which means is that you grab your device that you're going to be monitoring and you bring it to your testing evaluation room and you make it go through all the different paces, go through all the different states. This is the exact same type of assessment that you would do to do code coverage on your traditional functional tests. So you want to exercise

all the different paths, doesn't mean you have to exercise all the different inputs, you have to exercise all the different execution paths, and that way you can come up with a complete library of what the normal, the real states are, and then if anything were to come in, we will flag it. Of course, that requires you to have a testing evaluation room, and then you

can able to monitor for the execution of different states. The other one is unsupervised learning, where you simply observe the device for a period of time, and whatever you observe at that time, you make it part of your library, and anything you don't see, you can match it,