Episode 12: Digital Decoys, Sirens and Geofencing: Deception Technology for Industrial Cybersecurity

Jeremy Boren: So imagine this. You're in charge of cybersecurity at your company. It's Christmas Eve and your website, your company's front door, is getting hit with a denial of service attack. Traffic from outside the U.S.

is flooding your customer billing portal with requests and you have limited staff to help investigate and adjust your firewall. Meanwhile, the cyber attack could be a diversion for an entirely different target somewhere on the operations side of your manufacturing, production, or utility operations. It's a pretty common scenario, and there's more than one way to deal with it. But at Gray Matter, we're introducing a new solution called Deception Guard that puts your team on the offensive.

As my Gray Matter colleague Scott Christensen will explain in a moment, deception technology for industrial cybersecurity gives companies an option to automate their response to denial of service and other types of attacks by geofencing out all traffic from countries where threats commonly originate, countries like Russia, North Korea, and elsewhere. It also creates virtual decoys that draw attackers away from valuable assets and toward fake targets that can actually learn what the attacker is up to. I'm Jeremy Boren, Gray Matters brand manager, and today's topic is deception technology for industrial cybersecurity and Deception Guard, a new offering from Gray Matter. Don't forget to rate and review us on Apple Podcasts or wherever you happen to listen.

Now let's hear from cybersecurity lead at Gray Matter, Scott Christensen.

Scott Christensen: So, you know, we'll start with the bigger picture, right? What is deception technology? So the idea behind deception technology is I want to create a device that looks attractive to external or internal threats, but is in actuality a decoy from my actual primary assets. sets.

So when you look at it from that perspective, I'm in a network, I'm trying to hack into you, I'm trying to, I'm trying to break something. I see this great juicy target. It's actually not a real target. The most common term we see is honeypotting.

And in the sense that what we're doing with Deception Guard is we're taking a lot of those same concepts, but then we're adding in and wrapping in a couple more technologies, the ability to do it virtually and agentlessly, to be able to react, you know, automatically, as well as kind of engage in some network resource skill set. And in the OT space, which makes it kind of critical is I can now, instead of just looking like any old, you know, PC out there on my network, I can actually make a device look like a specific brand of PLC or HMI or DCS terminal. So I can make it look like an industrial control system target. So when someone decides they want to get into my network, I may only have one HMI, but it looks like I've got five, four of them being false targets.

So So in itself, that allows me to kind of protect the real targets as well as learn what's happening or how they got into my network and what actions they took once they were in because I'm using non-valuable virtual assets to protect my environment.

Jeremy Boren: What normally happens to a company that isn't using deception technology right now when there's an incursion attack, something like a denial of service attack, which is a super common way that people get affected?

Scott Christensen: Exactly. So denial of service or brute force attack where I'm just trying to overwhelm network resources, right? So traditional methodology, and we actually have had customers experience this. You can recover, you can get ahead of them, you can do it, but it requires a very large administrative lift, right?

Right. I've got to have my team in writing route statements. I got my team writing new firewall rules. I got my people doing port blocking or I'm disconnecting parts of my network.

All a bunch of different things, depending on what type of attack it is. I have to get ahead of it. So that's traditionally that's what you do is you basically throw manpower at it and try to fix the problem as quickly as you can.

Jeremy Boren: Right. And in a way that feeds into the nature of the attack itself, which is to consume a company's resources, you know, by making these repeated requests. So if you're spending a lot of time trying to stop what is already happening, you're kind of falling victim again.

Scott Christensen: Exactly right. Exactly right. It's a lot of times when you start looking at botnet attacks and denial of service attacks and a lot of these brute force methodologies, there's usually a couple outcomes that they're trying to achieve. One is let's hammer and overwhelm the resources to see what happens, see if I can't use that as an advantage to get into parts of the network I shouldn't be able to get into.

Or secondly, as they're focusing those resources, utilizing other methodologies to get in and take advantage of backdoor and get in and try to pull out data because there's so much focus and monitoring going on at the front end that you're not seeing the backdoor being utilized. and it's a pretty common kind of technique used specifically a lot of your more we'll call it organized criminal activities we'll we'll focus on this people who've got the resources to overwhelm you and what we've seen with the proliferation of IOT devices is I don't necessarily have to have a bunch of machines everywhere I can take over a bunch of you know thermostats or take over a bunch of simple computing machines that have some type of IOT functionality and use those to go after your network from a denial of service standpoint. So I can utilize a lot more in the day of the connected systems. It's much easier for me to get access to botnets and tools that let me overwhelm the kind of infrastructure and resources.

Jeremy Boren: Now, if you add a layer to it, deception guard, deception technology, what happens when that same type of attack occurs? hers?

Scott Christensen: So there's a couple of things that become pretty beneficial when you're using a technology like Deception Guard. So the first thing is the ability to geofence. So for example, if I notice that I'm getting a denial of service and it's all coming from, say, the Ukraine or Kazakhstan or, you know, one of the Eastern Bloc that are common for this type of attack, I can quickly geofence out and say, do not allow any connectivity coming from any location that's in one of those countries. countries.

So immediately I stop all traffic from those countries. So you kind of get ahead of the initial, and it only takes a few minutes to actually set that up. I can geofence in, like, I think we timed it out a little under five minutes. So instead of spending hours of resources and creating a bunch of firewall rules and a bunch of route statements and a bunch of things that I can do this in like five minutes, just simply block all activity coming from the Ukraine or China or Venezuela, wherever it might be.

So in five minutes, I've already minimized that threat attack. Secondly, when someone gets in and they're trying to exfiltrate that data and they're trying to pull that information out, if they're attaching one to one of my decoys, I can quickly see how they behave in my network and what kind of steps they took. And so I can use it from a forensic standpoint to remediate out before they actually get to any valuable data, right? Because as they're playing with a honeypot or playing with one of the decoys or one of the sirens, they all come under the different names.

But when they're interacting with them, because there's no reason to be interacting with them, it'll immediately send off triggers. And I can even automate some of those triggers. When someone tries to contact this, I can say throttle their bandwidth back or block their access from these network resources. There's a lot of things I can automate the process so that I don't have to throw a bunch of bodies and resources to protect myself.

the system can automate that. And then lastly, I think the third thing that's kind of really important about it is I then can take that data and even early in the kill chain, say in the reconnaissance phase, I can take that data and then I can look back to remediate to prevent that from being a reoccurring theme. So I can say someone came in over a specific port and then from there they pivoted over and tried to do reconnaissance scanning or in-map scanning of my network resources and that triggered. So I can simply say, hey, well, why don't I close this port or evaluate the value of that port being open to begin with.

So it allows me on the forensic side to make sure that I'm closing the doors as they get identified, as opposed to, you know, I always think about the little kid with the dike where he's putting his fingers in the holes. Yeah. So instead of putting your fingers in the holes, you're actually fixing the dam. Right.

So you're not waiting for the next hole to pop up. You're actually you're blocking it. And then let's let's get yourself a breathing point to where you can remediate and fix a problem. Right.

Jeremy Boren: And another advantage, and this is something that we had had a chance to talk with an actual user about, is that, you know, if you're making changes to your firewall rules on the fly, there's a chance that you're going to make a mistake and possibly make things worse. Oh, yeah. Right? Right.

Scott Christensen: It's the bane of every firewall admins existence is conflicting firewall rules where I say I don't want to allow X. And then the next guy comes along and says, allow everything or allow X. And you conflict with each other. That's the bane.

When you start looking at some of these routing tables, some of these firewall tables, you know, they could be hundreds of lines long. So you don't necessarily know every rule that you're you've created. or if you're not the only one touching that firewall, which is a lot of times the case, you look at a 20-year life cycle of a industrial switch or firewall, there's probably three or four people who've touched it and put rules in there. And then if you've not done a recent audit log, you don't even know what you've done.

And then you get into this emergency situation and you're just doubling down on how many rules you're gonna write. It's the likelihood just gets exponentially higher the more rules you're writing and how quickly you can kind of give yourself self a conflicting policy.

Jeremy Boren: Right. And so deception guard saves you that grief. Can you- Absolutely.

Scott Christensen: Absolutely. So- Can you describe how? Yeah. Yeah, exactly.

So if you start off with the geofencing concept, right, by blocking all traffic from a specific location, there's not a whole lot of firewall rules there. It's very simple. I see country A and I say block country A. That's the first part that becomes very simple.

Secondly, I can do the same thing on an IP level, right? So if I see a specific IP address trying to come in, I can do the same functionality and say, don't allow X. And then you can start getting more creative. But what's great about it is because I'm not having to create a big table of rules.

I'm kind of using the interface to drive what I want to block. I can make it much cleaner for myself for how I want to manage it. And then I can quickly use that to kind of identify, you know, maybe I can even be proactive. So for example, if there's never a reason you should be doing business with Eastern block countries maybe proactively i block all eastern block activity so i can start make creating these kind of geo-fencing perimeters so my threat you know and i commonly preach about shrinking your threat vectors you know shrinking your footprint uh that's one of the best things you can do it's you're not necessarily always going to be perfect but if i get smaller and smaller and my threat vectors are less and less then i only have to be worried about the one avenue that could be an issue versus everything come from everywhere so once i started shrinking that down, then I can focus my more targeted defensive techniques on the way that they got into my systems.

So I can look at things like encryption technologies and VPN and tunneling technologies and zero trust networking and more of the more granular controls. I can start putting those things in place because I've kind of got the big perimeter where I only have to worry about US-based IPs. So, okay, so I've now eliminated 80% of the world. Now I can say, okay, now that I'm only worried about USIPs, what are the most common ways they could have taken advantage of that?

So then I can start focusing on those areas. So I've shrunken my footprint to a much smaller size and made it much more manageable. And when you look at the industrial side where we don't have large teams of security administrators and threat hunters and counterintelligence people, you know, on the OT side, we don't tend to have a lot of that. We usually maybe have a network guy and we might have a dedicated, you know, what they call PCN person, process controlled network, who focuses is on security, but it's usually not a big team of people and they're not always eyes on glass.

So being able to streak what they have to worry about is huge. And then the fact that I can automate the response becomes more powerful, right? And because this is all done off of interactions with the sirens, the decoys and the honeypots, I can also say that my possibility of false positives is much smaller because I'm actually using interaction. I'm I'm using the actual data of how they're communicating with this decoy, with this honeypot.

I can use that data much more accurately because I've got real world data of how they interacted. It's not theoretical. It's not, this might be a threat. It's literally, here, they're interacting with this virtual device.

This is exactly how they're doing it. Prevent this from happening again. So I can replicate that very easily and cleanly and really minimize the false positive kind of side of things that we dread in OT security. Sure.

Jeremy Boren: And one thing that can be, that's, I think is kind of interesting in an industrial environment, and I mean, there may be a place for it in IT as well, is when you're creating these honeypots, these decoys, you can set it up so that if somebody connects to a PLC, you know that it's bad news because nobody should be connecting to it. There shouldn't be any connections, right? Exactly. So there's no legitimate reason that somebody should be connecting to it.

And if there is, you instantly know that there's an issue that needs to be addressed.

Scott Christensen: Exactly right. So whether it be someone just being curious on your network or if it's malicious intent, it really doesn't matter because there's no reason to be interacting with network resources, specifically the virtualized honeypots, because these are not actual assets. assets. And on flip side of that, the counter argument I always want to talk about too is it also gives a juicy target that is not in the way of my revenue side of my house.

So for example, not just PLCs, if you think about the cost of a DCS terminal, the cost of the software, you can get into six figures pretty quickly. And I don't want them trying to figure out what's on that terminal. So I give them three fake ones, let them do all their damage in the virtual world that does me no monetary damage. And then I can quickly make sure that they can't do that in the real world.

So I always use the analogy of a bear trap. You know, get that big juicy steak sitting in the middle of a bear trap. You want it to be very, you know, you want to be very attractive. So when the bear comes in and eats it, then you can pull the trap shut on them.

And that's exactly what we're talking about here is there's no reason to be pulling that bait. There's no reason to be touching those network resources. And if you do, I can then spring my response automatically on you and say, A, you're now locked out of resources. I've identified everything I need about you.

I know how you got in. I know how you try to exfiltrate data. I know how you kind of recon my environment. I can now take all that information and I can use that to improve so that A, it doesn't get repeated.

But B, I've also lowered my vulnerabilities because you just helped. You basically have given me a pen test for free.

Jeremy Boren: You know, you're able to say I've learned from this incident and I can make improvements to our system as a result. Yeah.

Scott Christensen: Yeah, like I said, to me, pen tests are simulated attacks, right? Trying to poke holes. This is a professional trying to break into my network who showed me what holes I had, and I just took advantage of that. So I get to use that as a counterintelligence data.

You think about a lot of times in security, we're very reactive to what we do. We wait to be hit. We respond and we recover. We put together DR plans and incident response plans and all these things.

Well, in this case, I can actually use these incidents in a low risk or a lower risk, I'd say, more accurate term, a lower risk way to get the same value because I've now got an actual hacker penetrating my network. Now I can learn how he did it and I can do it in a way that doesn't impact my day-to-day operations. The advantage we have is the OT is actually a perimeter within the perimeter of IT, right? So we're down lower.

If you use the Purdue model, right, they're five and above they're worried about and we're down in three, level three. So we're worried about that. So we're treating the IT almost as if it's the internet because it can pass data and be dangerous. So the assumption is they've already broken through the IT barriers.

They've already entered in and they've started doing their reconnaissance in the IT. And now they've taken the next hop and try to go from that layer four to that layer three. So they're breaking into my network. So the assumption is they've already done it.

Instead of giving them actual assets to attack, I'm giving them fake assets. And so the assumption is you've already been exposed. They've already broken your network at this point. You're not trying to attract them in.

All you're doing is distract them away is probably the most accurate way to put it. And I'm trying to give them something to go after so that I give myself the advantage of time. So early, early in the kill chain, I'm aware of what's going on because they're going after things that aren't critical to my day to day.

Jeremy Boren: How do you design a convincing decoy? How do you design something that's going to throw off data that an attacker, a real life person, human being looks at and thinks, yeah, this, this, this, I might be in the right place.

Scott Christensen: So there's a couple of things we do, which is kind of interesting. There's always an evolving process of a library of other decoys we've built and other data we've done and what we know. This comes from the 30 years Gray Matter has been deploying OT. This is not new to us.

So we can leverage that knowledge, that maturity we get. And that's something that you can't get from a lot of vendors out there is that we've been deploying PLCs and and SCADA systems, and analytics, and all these things. We've been doing this for 30 years. So there's that aspect of we developing our library of that.

And then the second part of what's really great is when we're working with customers, we'll actually take recordings of their traffic, and we'll learn what their traffic and how their devices behave and their assets behave so that we can create fairly accurate emulations of that so that we can appear, so we can map that out. So, you know, I can take a specific brand of controller, I can record its traffic, see how it behaves, see what it communicates with, and then I can replicate that in a virtual way. So one of the great parts about Deception Guard is the ability to spin up these sirens, these honeypots for OT. I can spin these up pretty quickly and easily based on just a minimal amount of customer data that replicates exactly what their environment looks like.

Version and bandwidth and types of devices and who communicates with what. I can replicate that pretty quickly with some minor information from the customer and a little bit of our knowledge on how these things should look from a cyber and an OT perspective.

Jeremy Boren: Who's primed for wanting to check this out, to see if it's right for them? What maturity level should they be thinking about? Because you don't have to be super deep into OT cyber to be able to do this.

Scott Christensen: Yeah, no, you have to have an OT cyber program if you've done the first step, which is identify, right? You identify your critical assets and data. If you've done that step, then this is a good maturation to the next step, right? I've already identified my assets.

I understand my network to some extent. Now I want to start putting in tools for both intelligence and counterintelligence work. This is that second or third maturity step. It's definitely not your first.

You still want to understand your network. You understand your risks. You want to kind of put what your mitigation strategy is. But this is a nice good one.

Specifically if you've got a high risk of something like a denial service. So if you're a well-known company that's a target or a government agency or municipality, all those, those would put you as pretty high targets. So if you've already started with the blocking and tackling and done like assessment work and identifying things within your environment, this is a nice maturity to the second step, which is detect and protect, right? So I'm now, I can now kind of use this in a defense in depth mentality to say, you know, this solves, this starts shrinking that threat vector, that footprint down.

So it's not the magic bullet, it doesn't solve everything for everyone, but I'm shrinking it down, right? So now I can focus on only the smaller footprint rather than every problem out there.

Jeremy Boren: We know that attacks, they try to be opportunistic. They look for organizations that they think have high value information, but maybe limited resources, which is why we see municipalities fall into that category. But it really could be anyone. anyone.

Scott Christensen: And that's probably a great part about the way we're bringing Deception Guard to market is we're not just throwing a box over the fence to someone's security team to figure it out and deploy and put it into their systems. We're packaging this together with Gray Matters cyber team and our knowledge to augment what your team may not have the resources or background to to do. So if you've got that limited resource and you've got that kind of struggle to figure out how to take that next step, we're here. That's exactly what we're here to do is help you figure out how the program should look and build the package around it as a service for you, not just as a, here's another mousetrap to work with.

Much more about, you know, here's how it should look in your environment. Here's how we can make sure this is accurate and representation of your environment. and here's how we can also do the incident response. All those things can be kind of packaged into a solution with our customer.

Jeremy Boren: Thanks for listening to the Empower Up podcast. I'm Jeremy Boren, Gray Matters brand manager. Don't forget to rate and review us on Apple Podcasts or wherever you happen to listen. See us online at graymattersystems.com.

you