WEBVTT
00:00:03.359 --> 00:00:13.359
From our headquarters in Oslo, Norway, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.
00:00:15.199 --> 00:00:18.000
We all love a good SIEM project.
00:00:18.000 --> 00:00:26.079
Collect some logs, normalize the data, tune the alerts, reduce the noise, and do it all again with the next environment.
00:00:26.079 --> 00:00:28.559
Now compare that to a canary.
00:00:28.559 --> 00:00:34.799
You place a fake credential, bucket, secret, or session token where no one should touch it.
00:00:34.799 --> 00:00:38.960
And the moment someone does, you know something is wrong.
00:00:38.960 --> 00:00:43.759
No tuning, no baseline, just a high fidelity signal.
00:00:43.759 --> 00:00:49.280
And in some environments, that might be the only signal that you can realistically get.
00:00:49.280 --> 00:00:54.159
CI-CD pipelines, cloud accounts, appliances that barely log.
00:00:54.159 --> 00:01:00.799
Environments where sending everything to the SIEM is just too expensive or simply not possible.
00:01:00.799 --> 00:01:09.120
So if deception gives you cheap, fast, high confidence visibility, why did the industry stop talking about it?
00:01:09.120 --> 00:01:12.959
And why should you maybe start looking at it again?
00:01:13.760 --> 00:01:17.040
I'd say the spark that started to trace bit was my previous role.
00:01:17.040 --> 00:01:25.040
I led the engineering team, and I was also at times like the de facto CISO for an email security company called Tessian.
00:01:25.040 --> 00:01:26.879
They got sort of proof point a few years ago.
00:01:26.879 --> 00:01:31.280
Um, and it was there basically in that role as thinking about security of the organization.
00:01:31.280 --> 00:01:33.359
I wanted to do deception.
00:01:33.359 --> 00:01:38.799
So I was thinking about how we could detect thractors that got into our environment, how we would do that.
00:01:38.799 --> 00:01:50.319
And because of like the large, sprawling, ever-changing nature of our environment, uh, the idea of deploying some like tripwires effectively around that environment to detect intrusions seemed like a good idea.
00:01:50.319 --> 00:01:57.599
Long story short, we looked at the market, nothing really made sense for this kind of large, ever-evolving cloud environment.
00:01:57.599 --> 00:02:04.959
Um, we looked to build something ourselves in-house, realized to do that would take actually way too many resources that we couldn't justify.
00:02:04.959 --> 00:02:06.400
Um, so we shelved the project.
00:02:06.400 --> 00:02:09.599
And I can't really share the details, but we were unfortunately hit by an incident.
00:02:09.599 --> 00:02:14.639
It's actually a supply chain attack that led us to deeply regret not investing in deception.
00:02:14.639 --> 00:02:19.360
Um, we realized that if we had done, we'd have caught something maybe six months before we we wouldn't have done.
00:02:19.360 --> 00:02:24.800
Fortunately, there was not a significant impact to the business, but that was kind of the spark really that started TraceBit.
00:02:24.800 --> 00:02:33.599
Myself and my co-founder were both deeply involved in that incident, and we kind of saw the opportunity that that deploying some deception in the environment would have would have saved us, basically.
00:02:34.159 --> 00:02:37.680
Do you think that what incident would have been any different if you actually had deception in place?
00:02:37.680 --> 00:02:38.240
100%.
00:02:38.560 --> 00:02:53.840
Yeah, so so um again, I don't want to go on don't want to go into too much detail, but when we when we dug into it, the the the deception we wanted to deploy would have been hit on day one of this this incident, and we didn't actually pick up signals till months later.
00:02:54.719 --> 00:03:02.879
Would you mind explaining you said tripwires, uh canneries, I've heard, I've heard honey pots as well, and I know there's a difference there.
00:03:02.879 --> 00:03:03.919
What is deception?
00:03:04.240 --> 00:03:04.879
Yeah, for sure.
00:03:04.879 --> 00:03:10.400
Um so deception technology has has many different definitions, and it can be quite confusing.
00:03:10.400 --> 00:03:21.520
I mean, fundamentally, the idea is to create artificial resources somewhere inside your environment, could be inside the perimeter, outside the perimeter, to deceive attackers in one way or another.
00:03:21.520 --> 00:03:24.479
People do this to seek when they seek different outcomes.
00:03:24.479 --> 00:03:31.360
Some are seeking to produce threat intelligence to understand more about the threat actors are how are how they're attacking them.
00:03:31.360 --> 00:03:33.599
That's when you'll often hear like the word honeypot used.
00:03:33.599 --> 00:03:41.039
So this is where you might put a honeypot on the internet and you might associate it with your organization and you know, see who's going after you and what they're trying to do.
00:03:41.039 --> 00:03:42.960
And that would produce threat intelligence.
00:03:42.960 --> 00:03:47.439
What we focus on at TraceBit is more on the tripwire side of things.
00:03:47.439 --> 00:03:52.639
And that's where you hear terms like canaries or honey tokens or these sorts of things.
00:03:52.639 --> 00:03:55.280
And they would often be deployed inside the perimeter.
00:03:55.280 --> 00:03:58.319
And that the goal is high fidelity detections.
00:03:58.319 --> 00:04:03.039
But ultimately, they're they're fake resources that should never be interacted with by a threat actor.
00:04:03.039 --> 00:04:08.639
So it could be in a cloud environment, you might have an S3 bucket that should never be read.
00:04:08.639 --> 00:04:15.120
And if someone goes and reads it, you would jump on that signal because it likely indicates there's some compromise or some insider risk.
00:04:15.919 --> 00:04:19.839
Would you mind going into some of those artificial resources and what they actually are?
00:04:19.839 --> 00:04:23.040
You mentioned AW or an A or S3 bucket you said.
00:04:23.120 --> 00:04:23.759
Yeah, yeah, for sure.
00:04:23.759 --> 00:04:24.160
Um, yeah.
00:04:24.160 --> 00:04:30.000
So I mean the kind of classic way of doing this was uh virtual servers or network-based canaries.
00:04:30.000 --> 00:04:36.399
So you might have an SSH server or you might have a web server or a telnet server even, and you might be seeing who logs into those.
00:04:36.399 --> 00:04:46.639
Um the kind of approach we've taken that is a little bit different from these more traditional ways of doing things is leveraging like serverless resources in cloud environments.
00:04:46.639 --> 00:04:51.920
The reason we've done that is one, that is how threat actors are traversing through these environments.
00:04:51.920 --> 00:04:58.000
You know, they're generally not getting access to a network and running Nmap and then trying to get into a server.
00:04:58.000 --> 00:05:04.480
They're generally getting access to some credentials and then trying to move laterally or escalate privilege by jumping around.
00:05:04.480 --> 00:05:09.680
It could be roles or secrets or buckets or things like that in those environments.
00:05:09.680 --> 00:05:19.920
So, what we would canary, as we call it, would create deceptive resources for would be things like an S3 bucket or a secret manager secret in AWS, an IAM role.
00:05:19.920 --> 00:05:24.959
We do a ton of different things in a ton of different cloud environments, but it's it's the serverless resources.
00:05:24.959 --> 00:05:33.279
And the other benefit of that, as well as in being like how the attack paths actually look in environments, is they're actually very low cost and low maintenance.
00:05:33.279 --> 00:05:42.000
So it's basically financially intenable for any of our customers to deploy uh network honeypot into every virtual network they have in their system.
00:05:42.000 --> 00:05:45.920
They could have thousands of virtual networks, servers cost money to deploy.
00:05:45.920 --> 00:05:48.000
It's not really feasible to do that.
00:05:48.000 --> 00:05:56.240
But if you compare that to like an S3 bucket, which is basically free to deploy, you could deploy thousands and thousands of these without incurring a financial cost.
00:05:56.240 --> 00:05:59.040
And then also the cloud providers are maintaining these for you.
00:05:59.040 --> 00:06:00.959
You know, you're not patching your S3 bucket.
00:06:00.959 --> 00:06:04.399
So the actual risk and operational overhead of deploying these is also very low.
00:06:04.720 --> 00:06:05.199
Interesting.
00:06:05.199 --> 00:06:09.519
I was gonna ask you, how did you go about choosing those artifacts?
00:06:09.519 --> 00:06:12.160
Was it because of incidents that are going on?
00:06:12.160 --> 00:06:20.000
That's probably a little bit of that, and also because they are you also had to balance that with like the keep the operational overhead low.
00:06:20.319 --> 00:06:20.800
Exactly.
00:06:20.800 --> 00:06:28.240
So so yeah, of course, we're we're always gonna focus on you know, where are the like the juicy parts of an attack path that the attackers are after going after?
00:06:28.240 --> 00:06:34.879
So, like reading public threat reports, speaking to customers, that's like part of it, and popular resources as well, right?
00:06:34.879 --> 00:06:40.480
It's it's no good, it's no good as building a product around a resource that is very, very rare in environments.
00:06:40.480 --> 00:06:42.079
We we're shooting for that realism.
00:06:42.079 --> 00:06:43.360
And actually, it's surprising.
00:06:43.360 --> 00:06:50.160
We actually have you know six resources we do in AWS, and we're constantly hearing from customers like, actually, those are the ones I'm I'm worried about, like by and large.
00:06:50.160 --> 00:06:50.959
So that's part of it.
00:06:50.959 --> 00:06:52.800
Like, are these actually used in attack paths?
00:06:52.800 --> 00:06:57.120
And then, yeah, the other part is like the operational overhead, but also the risk, right?
00:06:57.120 --> 00:07:03.120
So the other benefit of an S3 bucket is it's many, as an example, is it's in many ways benign.
00:07:03.120 --> 00:07:09.680
You know, if a threat actor gets full access to that and uh you know they're able to do whatever they want with it, they don't have remote code execution.
00:07:09.680 --> 00:07:13.199
They can't like leverage that as a foothold and then pivot around the network from there.
00:07:13.199 --> 00:07:17.680
Uh, compare that to a server, there's actually quite a lot of risk with deploying a server in an environment, right?
00:07:17.680 --> 00:07:24.160
If I exploit your Honeypot server, it's like it's like a own goal that a lot of security teams don't really want to take that risk on.
00:07:24.160 --> 00:07:28.399
So the operational overhead and the the low risk is very much a big part of it as well.
00:07:29.279 --> 00:07:30.800
Do customers want different things?
00:07:30.800 --> 00:07:36.959
Do they ever ask you to make you know canaries for them that you didn't make before?
00:07:37.279 --> 00:07:42.240
So part of what we do with the platform is like customizing these canaries.
00:07:42.240 --> 00:07:48.480
So we will scan our customer environments and we're gonna like we're gonna take the naming configuration for the resources we we deploy.
00:07:48.480 --> 00:07:50.160
So it's gonna look similar.
00:07:50.160 --> 00:07:55.439
Um worth saying as well, actually, that the nice thing about that is it's quite hard to fingerprint these these things.
00:07:55.439 --> 00:08:05.120
You know, like uh an IAM role, let's use a different example, in a in an AWS account, only has a handful of properties to it that an attacker can see before they actually start interacting with it.
00:08:05.120 --> 00:08:08.879
So it's actually quite easy to make these blend in with the rest of the environment.
00:08:08.879 --> 00:08:13.279
Again, compared to a server, which is going to be fingerprintable over TCP.
00:08:13.279 --> 00:08:19.920
So that gets us very far with customers, just like making the resources named in a similar way and configured in a similar way.
00:08:19.920 --> 00:08:31.519
Where we want to get to is like imagine a world where you plug some threat intelligence into Claude or Codecs, and you say, Hey, I want some deception in my environment if for this threat actor.
00:08:31.519 --> 00:08:44.399
Uh and you know, you plug into TraceBit and we can deploy like nested canaries and deception around your organization, both on the out external perimeter and internal perimeter to detect and deceive that specific threat actor.
00:08:44.399 --> 00:08:45.519
That's not where we are today.
00:08:45.519 --> 00:08:51.519
We deploy lots of canaries at scale for for good coverage, uh, but that's where we want to go with the platform.
00:08:51.919 --> 00:08:53.360
I understand the internal case.
00:08:53.360 --> 00:08:54.720
What's the external case?
00:08:55.200 --> 00:08:59.440
So historically, the external case has been, to my point earlier, around threat intelligence.
00:08:59.440 --> 00:09:01.759
So putting pieces of honeypot, yeah, the research.
00:09:01.759 --> 00:09:02.879
Yeah, exactly.
00:09:02.879 --> 00:09:10.320
Um we have this feature we're launching soon called perimeter canaries, where you could point some public facing infrastructure at trace bits.
00:09:10.320 --> 00:09:14.159
So imagine vpn.customer.com points to us.
00:09:14.159 --> 00:09:21.919
Now, obviously, it's not it's not super useful for us to tell you someone scanned vpn.customer.com because that's going to be happening all day, every day.
00:09:21.919 --> 00:09:23.120
It's not actionable.
00:09:23.120 --> 00:09:24.320
You know, what are you gonna do with that?
00:09:24.320 --> 00:09:27.679
Your security team's already really busy, you know, they don't they don't need more information.
00:09:27.679 --> 00:09:29.279
It's not that's not super useful.
00:09:29.279 --> 00:09:37.600
But what if you placed a cookie on every single one of your users' workstations that referenced VPN.customer.com with a with a unique cookie.
00:09:37.600 --> 00:09:49.279
Well, now if a threat actor gets into that one of those workstations and they dump the cookies in an attempt to like move laterally, you know, or run an info stealer as is often the way, that's gonna be like really high up on their list of targets.
00:09:49.279 --> 00:09:51.519
Because they think they're they're gonna think they've got the VPN access.
00:09:51.519 --> 00:09:54.000
It's gonna make it look really believable and really legitimate.
00:09:54.000 --> 00:10:01.600
And then you know, you can imagine the future like customizing that to specific instance you've had or specific like things that are being targeted in your industry.
00:10:01.840 --> 00:10:03.120
Yeah, cool.
00:10:03.120 --> 00:10:07.039
So I had an episode four years ago about deception.
00:10:07.039 --> 00:10:08.240
I called it deception.
00:10:08.240 --> 00:10:08.480
Yeah.
00:10:08.480 --> 00:10:09.759
Uh as with Illusive.
00:10:09.759 --> 00:10:10.080
Okay.
00:10:10.080 --> 00:10:12.879
And then a couple, it mightn't have been that long before that.
00:10:12.879 --> 00:10:14.879
I had one on uh honeypots.
00:10:14.879 --> 00:10:20.000
But I haven't seen the adoption take off in in our neck of the woods, right?
00:10:20.000 --> 00:10:20.960
Uh in Europe.
00:10:20.960 --> 00:10:22.960
Why is that and what's changed?
00:10:23.360 --> 00:10:25.279
Yeah, uh, it's it's absolutely not taken off.
00:10:25.279 --> 00:10:34.720
And I think, you know, if you look at the history of this, you can see there was a lot of venture capital excitement in in Deception, maybe eight to ten years ago, and that's where companies like Elusive came out of.
00:10:34.720 --> 00:10:37.200
Uh, there were there were a bunch of them, and there was a lot of excitement.
00:10:37.200 --> 00:10:44.639
And I think I hear stories that if you went to RSA 10 years ago, like the expo floor was full of like deception technology as far as the eye could see.
00:10:44.639 --> 00:10:52.639
Uh, and you're right, like, you know, you speak to a CISO, and there's probably, I would say there's a 90% chance they're familiar with Deception and see some value in it.
00:10:52.639 --> 00:10:57.120
I'd say there's a 5% chance they've actually deployed it today, like from our experience.
00:10:57.120 --> 00:11:10.879
Um, I think that past wave of technologies from the folks we speak to that that bought and deployed them, they suffered a lot from some of the challenges I've already touched on around the heavyweight nature of deploying like virtual machines.
00:11:10.879 --> 00:11:16.240
And some of these technologies you actually shipped to a physical rack you had to go deploy into your data center.
00:11:16.240 --> 00:11:18.799
And then these things are expensive to deploy, right?
00:11:18.799 --> 00:11:20.399
You want to deploy like hundreds of servers.
00:11:20.399 --> 00:11:23.360
There's actually like a significant financial cost to deploy them.
00:11:23.360 --> 00:11:26.639
And then again, there's uh an operational overhead.
00:11:26.639 --> 00:11:33.039
The other challenge that I understand from folks who deployed these is that that like maintenance and management of them.
00:11:33.039 --> 00:11:39.519
So they often gave you some really nice building blocks to go and deploy deception in your environment, but they they left you to it.
00:11:39.519 --> 00:11:43.840
Like you had to go and go and figure out where to where to put all of this all of this stuff.
00:11:43.840 --> 00:11:49.679
Um, and because it was in the data center and it was an on-prem network, it was quite a lot of work to go and do that.
00:11:49.679 --> 00:12:03.279
We think it's different this time because like the cloud, you know, teams have aligned behind certain technologies, like Terraform is one of those, Kubernetes is another one, which allow for like the rapid scale of infrastructure around your environments.
00:12:03.279 --> 00:12:06.639
That infrastructure is lightweight, it's easy, easy to deploy.
00:12:06.639 --> 00:12:10.240
The other unlock for us uh has been LLMs.
00:12:10.240 --> 00:12:15.200
So we are using LLMs to create suggestions to customer environments.
00:12:15.200 --> 00:12:17.919
So when we started the company three years ago, they weren't that great.
00:12:17.919 --> 00:12:24.559
We did things like look to prefixes and suffixes for our naming schemes and things like that, but they've obviously come on leaps and bounds.
00:12:24.559 --> 00:12:41.120
So we will actually take metadata from customers' environments and we'll use that to say, hey, you know, create me sets of resources that are attractive to would-be attackers, that are benign to would-be attackers, create all these different resources and make them look realistic and tell a realistic story for this environment.
00:12:41.120 --> 00:12:45.200
And the security teams we show this stuff to are like, wow, like, you know, I wouldn't have even thought about that.
00:12:45.200 --> 00:12:49.120
Or I forgot we even did that project, but it'll be great to have a canary over there.
00:12:49.120 --> 00:12:54.879
So that that time save is a big part of it because security teams are usually the most busy people in the company.
00:12:54.879 --> 00:13:01.039
And the idea of spending three weeks to go and come up with some great deception is just not really feasible.
00:13:01.039 --> 00:13:04.399
Then, not least, if you think about maintaining that in the long run, right?
00:13:04.399 --> 00:13:06.639
Because your environment's going to change in six months from now.
00:13:06.639 --> 00:13:13.440
So six months, six months down the line, are you really gonna put in like another couple of weeks to go and move the deception around and reconfigure it?
00:13:13.440 --> 00:13:20.159
But if you automate that from day one and you use LLMs to create believable looking deception, that's where we think there's a lot of value.
00:13:22.080 --> 00:13:23.759
SOC, Security Operations Center.
00:13:23.759 --> 00:13:28.639
I'm assuming all your customers today are probably large and mature.
00:13:28.639 --> 00:13:30.480
And we can get back to whether we need to be.
00:13:30.480 --> 00:13:31.200
We can get back to that.
00:13:31.200 --> 00:13:32.399
Yeah, whether you need to be not.
00:13:32.399 --> 00:13:33.840
Yeah, we talked about this before.
00:13:33.840 --> 00:13:34.240
Yeah.
00:13:34.240 --> 00:13:40.480
But the ones that do have it today, what does it look like when they have deployed this technology in their current SOC?
00:13:40.480 --> 00:13:41.919
Like how does that coexist?
00:13:42.320 --> 00:13:43.840
Yeah, so it's it's fairly straightforward.
00:13:43.840 --> 00:13:46.000
We'll we'll usually be working with the SOC often.
00:13:46.000 --> 00:13:47.519
The SOC will buy trace bit.
00:13:47.519 --> 00:13:49.679
Obviously, it depends from customer to customer.
00:13:49.679 --> 00:13:52.480
But fundamentally, we are feeding these alerts into their sim.
00:13:52.480 --> 00:13:59.039
Uh and then the SOC team is taking those, it's they're augmenting them with other data in their environment, and then they're responding to those alerts.
00:13:59.039 --> 00:14:01.279
So it's it's relatively relatively simple.
00:14:01.600 --> 00:14:11.360
If you know everybody has a limited budget, if you had to take something out to put this in, make the make the case for you know spending 500k on trace bit then and 500k on something else.
00:14:11.360 --> 00:14:11.919
Yeah.
00:14:12.240 --> 00:14:12.559
Yeah.
00:14:12.559 --> 00:14:18.240
Um, I think there's we we have worked with customers on use cases around sim usage.
00:14:18.240 --> 00:14:23.440
And you know, we've we've heard from them, hey, I'm I'm not even doing anything with this sim data, it's way too noisy.
00:14:23.440 --> 00:14:26.000
I'm getting I'm getting too many alerts off it already.
00:14:26.000 --> 00:14:30.399
Uh certainly other tools like guard duty and things like that, like there's just no value in it.
00:14:30.399 --> 00:14:34.080
But I don't want to turn it off because that would leave me with zero visibility in that environment.
00:14:34.080 --> 00:14:37.200
So in some cases, there's a billion the ability to do that.
00:14:37.200 --> 00:14:42.399
I think the other interesting use case is when teams are wasting time on false positives.
00:14:42.399 --> 00:14:46.639
And again, they're in that state where they either put time into tuning them out, they turn them off.
00:14:46.639 --> 00:14:48.320
That's that's too much risk.
00:14:48.320 --> 00:15:03.679
There's there's a time-saving piece there where you know you can you can take a set of false positives and say, let's let's just turn these off because they're they're creating too much noise for us and we have comfort that we've augmented this, you know, we've we've replaced this with the visibility trace bits given us into that environment.
00:15:04.559 --> 00:15:08.639
So cheap visibility and no matter what, better than nothing.
00:15:08.639 --> 00:15:09.120
Yep.
00:15:09.120 --> 00:15:09.440
Yeah.
00:15:09.600 --> 00:15:10.480
Yeah, yeah, 100%.
00:15:10.480 --> 00:15:13.440
We go into environments where there just isn't that much telemetry.
00:15:13.440 --> 00:15:23.519
CI CD environments are a really good example of this, where what what logs do you have from those environments, especially if you're running that in in GitHub or Circle CI or places like that?
00:15:23.519 --> 00:15:27.039
Like, do you do you really have that much visibility of what's going on in those environments?
00:15:27.039 --> 00:15:33.600
Like, this is a quick win to get something in there very, very early that's going to give you that high fidelity signal if something is compromised, that environment.
00:15:34.480 --> 00:15:37.039
As we're speaking right now, there's probably a supply chain attack going on.
00:15:37.039 --> 00:15:37.840
I have no doubt.
00:15:37.840 --> 00:15:40.080
Yeah, we'll open our phones after this and read about it.
00:15:40.159 --> 00:15:40.399
I'm sure.
00:15:40.720 --> 00:15:41.360
Knock on the table.
00:15:41.360 --> 00:15:41.679
Yeah.
00:15:41.679 --> 00:15:47.360
Uh how would you, your technology, any deceptive technology sort of fit in that use case?
00:15:47.679 --> 00:16:00.080
Yeah, so so we we we did some research recently that we that we published with this, where um the the team PCP attacks that are very friendly for a lot of folks at the moment, one of the things they did was steal AWS keys and SSH keys from environments.
00:16:00.080 --> 00:16:02.240
And that's one of the ways that they that they spread.
00:16:02.240 --> 00:16:10.720
So very concretely, we ran some of that, those info stealers within some GitHub actions, and we were able to show that these would these would take these these keys from these environments.
00:16:10.720 --> 00:16:13.600
So TraceBit would detect when those keys were being used.
00:16:13.600 --> 00:16:20.399
One of the nice things that we do is we generate unique keys for every single build that runs in an environment.
00:16:20.399 --> 00:16:22.960
So like the scale is a big, a big important part of it.
00:16:22.960 --> 00:16:28.559
And what that means is when TraceBit goes off, you can actually jump to the exact build that this occurred in.
00:16:28.559 --> 00:16:30.720
So we met folks who've like built this themselves.
00:16:30.720 --> 00:16:38.000
They put a single AWS key in a Git repo that hundreds of developers have access to, and it pings one day from a funny IP address.
00:16:38.000 --> 00:16:41.039
And you fundamentally don't actually end up doing anything with that alert.
00:16:41.039 --> 00:16:48.000
You know, you know something bad has happened, but you don't even have the data or the telemetry to go and figure out where that bad thing has has occurred.
00:16:48.000 --> 00:16:55.840
Um, whereas when Tracebook goes off in an environment where like, hey, it was this build, you know, the the credential existed, you know, in the context for like 10 minutes.
00:16:55.840 --> 00:16:57.519
Like you need to go and investigate this right now.
00:16:57.519 --> 00:17:00.960
And obviously, if a lot more light up, then you know you'll have a you'll have a big impact.
00:17:01.600 --> 00:17:03.919
What about the other top initial access?
00:17:03.919 --> 00:17:11.920
Uh I mean, thinking of like, yeah, Mandiant would say that uh appliances getting popped are the uh the largest or info stealers, uh phishing.
00:17:11.920 --> 00:17:14.400
Do you uh do you have use cases for all those sort of yeah?
00:17:14.480 --> 00:17:16.880
So we do we do a lot on on workstations.
00:17:16.880 --> 00:17:19.759
So deploying deploying credentials onto workstations is a big one.
00:17:19.759 --> 00:17:25.039
I've mentioned this the session cookie piece that we're we're working on at the moment that I think is going to be gonna be really, really powerful.
00:17:25.039 --> 00:17:27.759
Um yeah, appliances I think is another really good example.
00:17:27.759 --> 00:17:33.759
Um we don't have like a ton of uh active deployments there, but I think credentials on appliances is super powerful.
00:17:33.759 --> 00:17:39.359
You don't have, you know, these they are often so underpowered you can't create logs or ingest those logs into your sim.
00:17:39.359 --> 00:17:45.680
But it's pretty trivial to go have like a cron, go deploy a uh a unique credential every every 24 hours.
00:17:45.680 --> 00:17:50.319
And if someone got onto that system, that's gonna look like a really attractive opportunity to move laterally.
00:17:50.319 --> 00:17:52.079
So that's the sort of detection we would make.
00:17:53.279 --> 00:17:55.279
Forgot his name, Caleb Simer.
00:17:55.279 --> 00:17:55.839
Caleb?
00:17:55.839 --> 00:17:56.240
Yes.
00:17:56.240 --> 00:17:57.200
He's fantastic.
00:17:57.200 --> 00:17:58.799
I don't know him, unfortunately.
00:17:58.799 --> 00:18:02.240
But uh he was on the cloud security podcast, I believe it was.
00:18:02.240 --> 00:18:04.880
Um, also a fantastic podcast.
00:18:04.880 --> 00:18:16.079
He said that it was surprising to him that companies don't invest that they go for like a big expensive sock as a reactive capability instead of going for something like your technology.
00:18:16.079 --> 00:18:16.640
Yep.
00:18:16.640 --> 00:18:19.119
I would assume that you would agree and like him saying that.
00:18:19.119 --> 00:18:21.119
Yeah, I thought it was really interesting.
00:18:21.119 --> 00:18:24.880
Uh because I I I share his viewpoint.
00:18:25.279 --> 00:18:28.480
We really do see this as a as a quick win that you can do early on.
00:18:28.480 --> 00:18:36.960
Um, by deploying deception previously, this was going to be something that was actually gonna create a bit of a workload for the team just to keep the thing like valuable.
00:18:36.960 --> 00:18:40.480
Whereas now it's automated, now this is something you can just plug and play.
00:18:40.480 --> 00:18:45.599
I I, incredibly biased, do think, you know, why not just do this like on day one of your security program?
00:18:45.599 --> 00:18:48.799
Like the idea that the times of value on deploying a sim, right?
00:18:48.799 --> 00:18:50.240
I'm talking like super early on.
00:18:50.240 --> 00:18:51.839
Like the times of value on deploying a sim.
00:18:51.839 --> 00:18:58.640
We speak to teams, you know, you come back six months later and they're still integrating this data source and that data source, they're still tuning.
00:18:58.640 --> 00:19:07.599
Like they could have had some super high fidelity detections across like a broad set of their environments within weeks if they deployed some deception in that environment.
00:19:07.599 --> 00:19:11.359
So I I think that like it is it is a massive quick win, but I'm obviously very biased.
00:19:11.599 --> 00:19:15.200
Yeah, SIEM is a never-ending project, as uh we both know.
00:19:15.200 --> 00:19:16.640
Uh LLMs.
00:19:16.640 --> 00:19:17.119
Yes.
00:19:17.119 --> 00:19:19.599
What are your thoughts around LLMs and deception?
00:19:19.839 --> 00:19:22.240
Yeah, I think there's I think there's like two key parts to this.
00:19:22.240 --> 00:19:25.039
Like one is offensive AI agents.
00:19:25.039 --> 00:19:28.720
Um we've actually done our own research on on this.
00:19:28.720 --> 00:19:38.160
Uh so we we created like a cloud lab and we we tested this out and we had an environment where they could get to basically root in in 14 minutes.
00:19:38.160 --> 00:19:47.680
Um, so I think I think LLMs for any security team right now, specifically offensive AI agents, you know, mean that attackers are gonna run much quicker through their environments.
00:19:47.680 --> 00:19:54.559
I also think they're just gonna have a broader set of techniques that they're gonna have available to them to get into those those environments.
00:19:54.559 --> 00:20:00.319
So, so for us, that means you want those high fidelity signals as soon as humanly possible.
00:20:00.319 --> 00:20:05.359
Um, and our tests show that that trace bit canaries like play a really good role in that.
00:20:05.359 --> 00:20:16.880
So the the the data we've we've produced and we've we published this show that we can make these detections of these offensive AI agents, like eight minutes into their their path to to domain admin.
00:20:16.880 --> 00:20:18.880
I I want to get that that number down.
00:20:18.880 --> 00:20:22.240
Uh, and I think there's there's all sorts of work we can we can do there.
00:20:22.240 --> 00:20:27.920
But I really think that, yeah, it's it's it's obvious that this is going to get um more and more serious over time.
00:20:27.920 --> 00:20:35.599
When the open weight models you know get this, get that good, which is probably six months away, we're gonna be in a really interesting situation.
00:20:35.599 --> 00:20:42.880
Um the other the other piece worth touching on uh that we do see in customer environments is like the internal AI agents.
00:20:42.880 --> 00:20:45.839
So you know, customers are are deploying these.
00:20:45.839 --> 00:20:51.440
Uh sometimes they're allowed to, sometimes it's it's shadow AI, you know, to do their to do their job.
00:20:51.440 --> 00:21:00.480
Um and what we're finding with deception is actually proving is quite a valuable detection for when those internal authorized AI agents like overstep the mark.
00:21:00.480 --> 00:21:09.200
So we've had examples in customer environments where the security team were surprised to find an AI agent you know make it all the way to a production canary.
00:21:09.200 --> 00:21:13.359
Uh and turns out, you know, an engineer was saying yes, yes, yes, yes, yes.
00:21:13.359 --> 00:21:20.319
And that's been a really useful uh detection for the security team to have that they otherwise wouldn't really have had any visibility of.
00:21:20.799 --> 00:21:27.519
So there's an insider use case here, not necessarily a human being or malicious insider, or but but it does cover both.
00:21:27.759 --> 00:21:37.359
We we cover both, and yeah, I've we've not really touched on that, but like folks will like buy Trace bit, usually for the outside in, the the external threat actor, and we'll provide value there, of course.
00:21:37.359 --> 00:21:41.920
But those um those detections, you know, are fortunately in most customer environments relatively rare, right?
00:21:41.920 --> 00:21:44.240
No, you're not getting popped every week.
00:21:44.240 --> 00:21:49.680
But the insider, you know, the someone who's it's it's not even insider risk, it's sometimes risky insider.
00:21:49.680 --> 00:21:51.680
You know, it's uh it's non malicious intent.
00:21:51.680 --> 00:22:02.079
Someone's trying to do their job, but maybe they've strayed into an environment they should have, maybe they're they've gone off a pro off a process they they shouldn't be following, and you know, they they End up saying off a canary.
00:22:02.079 --> 00:22:20.160
And those are often signals that the sim isn't tuned to detect and you know the security tool isn't set up to detect, but can often be the smoking gun for a security team that allows them to get a process fixed, you know, get some training improved, you know, get some um get some like guardrails tightened up and reduce risk for the business.
00:22:20.880 --> 00:22:26.799
Maybe uh sort of far out there, but has anybody ever used your technology for incident response use case?
00:22:27.119 --> 00:22:30.000
Uh it's something we have uh have explored with a few folks.
00:22:30.000 --> 00:22:36.000
But yeah, I think it's I think it's a super interesting use case, you know, when you you know someone is in the system and like proactively deploying that out.
00:22:36.000 --> 00:22:37.200
Just slow them down, right?
00:22:37.200 --> 00:22:42.640
Slow them down, confuse them, uh, detect them in places you you're you might not have telemetry for.
00:22:42.640 --> 00:22:44.319
Uh yeah, it's it's something we're exploring.
00:22:44.319 --> 00:22:46.400
It's not something we actively do with a product today.
00:22:46.640 --> 00:22:49.759
What was that study that we talked about in the elevator on the way up here?
00:22:49.920 --> 00:22:51.039
Uh the Tularosa study.
00:22:51.039 --> 00:22:51.839
Yeah, tell us that.
00:22:51.839 --> 00:22:58.960
Yeah, so the Tularosa study was um they took a couple hundred pen testers and it was kind of a test with a quadrant.
00:22:58.960 --> 00:23:08.880
So uh somewhere they were told there was deception and somewhere they were not told there was deception, and somewhere there um there was deception, and somewhere there wasn't deception.
00:23:08.880 --> 00:23:17.759
So that that was a quadrant, and that and they were trying to test out, you know, if you tell people there's deception in an environment and there isn't, like, does it change their behavior?
00:23:17.759 --> 00:23:22.720
Uh and if you put deception in environment and the and you don't tell people about it, does it does it change the behavior?
00:23:22.720 --> 00:23:23.839
Can you make detections?
00:23:23.839 --> 00:23:34.880
And yeah, the the the long and the short of it is they found that even the understanding or perception that deception was in an environment did change behavior and made folks less likely to reach their goal.
00:23:34.880 --> 00:23:41.839
And to the point earlier around the research we've been doing, we found that the same is true for for AI agents in environments.
00:23:41.839 --> 00:23:43.759
So I think it was Opus specifically.
00:23:43.759 --> 00:24:02.240
We found when you we ran this through our cloud lab, if you told Opus there was deception in the environment, its likelihood of reaching admin went from 20% to 3%, just because it believed canaries were there and it was trying to avoid them or taking steps to not get detected.
00:24:03.599 --> 00:24:17.039
I feel like it was one of your podcasts you had with uh the guy from Riot where you said uh where one you guys talk together and and you arrived at the conclusion that if everybody moves to deception, it'll be a cat and mask game as security always is, and the attackers will change.
00:24:17.039 --> 00:24:22.559
So in five years, if TraceBit is super successful and everybody's using Deception, what does the world look like then?
00:24:22.559 --> 00:24:24.559
What are the attackers gonna do differently?
00:24:24.880 --> 00:24:25.839
Yeah, it's a great question.
00:24:25.839 --> 00:24:34.400
I mean, and I think that's that is the case where we would make the case that like partnering with a vendor makes a lot of sense because you know you want someone, someone actively developing this.
00:24:34.400 --> 00:24:50.160
Because even if you went and did your own automation and set that up and did a really good job of it, so it does evolve automatically, you know, you're not gonna be inventing new resource types, you're not gonna be plugging different pieces together, you're not gonna be like building support for more systems over time, you're gonna build one piece.
00:24:50.160 --> 00:24:56.079
Uh, so for us, that's why it's really important uh to be constantly evolving the platform and adding new features.
00:24:56.079 --> 00:25:10.480
Um, and that's also why we're really excited about this like AI range that we've we've set up, because we can constantly iterate AI agents against these against these environments, and as they get better, um, we can detect that and we can evolve the product and platform to get better at detecting them.
00:25:11.519 --> 00:25:22.400
Is there ever like a case where you have so many canaries inside of an environment that like even that the attacker has to just and they just move on and they give up?
00:25:22.640 --> 00:25:23.039
Yeah, yeah.
00:25:23.039 --> 00:25:29.119
It's um so I think Kelly Shortridge from Fastly wrote about this uh in an article called Sludge for Good.
00:25:29.119 --> 00:25:37.839
And she made the case that you know you could do 95%, 99% uh deception or canaries versus uh 1% real resources.
00:25:37.839 --> 00:25:40.559
That is not something we've explored so far, to be honest with you.
00:25:40.559 --> 00:25:52.400
Uh I think uh you know our focus really is you know ease of deployment for us is also about not getting away in the way of your software engineers who you know are busy people and and you know don't want uh a ton of resources in their way.
00:25:52.400 --> 00:25:56.640
I I do see scope for that in the future for sure as something customers could opt into.
00:25:57.920 --> 00:26:01.200
Because if there were that many resources, how would it be in their way?
00:26:01.759 --> 00:26:01.920
Yeah.
00:26:01.920 --> 00:26:04.079
Uh from a software engineer's point of view, yeah.
00:26:04.079 --> 00:26:18.559
Well, imagine you're logging into a cloud environment and you know you're debugging a production issue at three o'clock in the morning and you're trying to find the real resource that is that is broken, and there's 10,000 canaries in there that you know you have to scroll through or page through.
00:26:18.559 --> 00:26:21.359
Yeah, so it's you know very valuable if you're a threat actor.
00:26:21.359 --> 00:26:25.119
It's gonna be basically impossible for you to find the real resource without sending it off.
00:26:25.119 --> 00:26:29.839
But that could create some friction if you are uh you know a DevOps engineer responding to an incident.
00:26:30.079 --> 00:26:35.759
Yeah, and that's what's been kind of holding deception back, if I understood you correctly, is the operationalization of it.
00:26:36.000 --> 00:26:46.880
The operational holding deception back is the opera opera line opera what's been holding the overhead for sure.
00:26:46.880 --> 00:26:54.160
Um but I would say that like that sludge idea is is maybe just taking things to the to the extreme, which I don't think is a bad idea.
00:26:54.160 --> 00:26:57.680
I just think it's it's something you would not want to put in every single environment.
00:26:57.680 --> 00:26:58.240
Yeah, for sure.
00:26:58.240 --> 00:27:01.279
Because like humans are operating in some of those environments.
00:27:01.440 --> 00:27:02.000
Yeah.
00:27:02.000 --> 00:27:09.519
Do you have any final thoughts or anything that we did not cover that you think is worth mentioning to enlighten security?
00:27:10.000 --> 00:27:16.960
No, I think um honestly, I think if you've if you've been intrigued by what you've heard, I would I'd really go sign up to our community edition.
00:27:16.960 --> 00:27:25.359
Uh something you can go and protect your your home PC with with deception right now, uh, and and your email and your password manager and other pieces like that.
00:27:25.359 --> 00:27:26.960
So I think that's a great place to start.
00:27:26.960 --> 00:27:29.599
Uh if you'd like to know more, you can you can book a demo on our website.
00:27:29.599 --> 00:27:30.000
Cool.
00:27:30.000 --> 00:27:31.519
Andy Smith, thank you so much for your time.
00:27:31.519 --> 00:27:32.160
Thank you much.
00:27:32.160 --> 00:27:33.200
We appreciate it.
00:27:33.200 --> 00:27:34.319
Thanks a lot.
00:27:35.039 --> 00:27:36.799
Well, that's all for today, folks.
00:27:36.799 --> 00:27:39.599
Thank you for tuning in to the Mnemonic Security Podcast.
00:27:39.599 --> 00:27:49.039
If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonic.no.
00:27:49.039 --> 00:27:52.400
Thank you for listening, and we'll see you next time.
00:00:03.359 --> 00:00:13.359
From our headquarters in Oslo, Norway, and on behalf of our host, Robby Peralta, welcome to the mnemonic security podcast.
00:00:15.199 --> 00:00:18.000
We all love a good SIEM project.
00:00:18.000 --> 00:00:26.079
Collect some logs, normalize the data, tune the alerts, reduce the noise, and do it all again with the next environment.
00:00:26.079 --> 00:00:28.559
Now compare that to a canary.
00:00:28.559 --> 00:00:34.799
You place a fake credential, bucket, secret, or session token where no one should touch it.
00:00:34.799 --> 00:00:38.960
And the moment someone does, you know something is wrong.
00:00:38.960 --> 00:00:43.759
No tuning, no baseline, just a high fidelity signal.
00:00:43.759 --> 00:00:49.280
And in some environments, that might be the only signal that you can realistically get.
00:00:49.280 --> 00:00:54.159
CI-CD pipelines, cloud accounts, appliances that barely log.
00:00:54.159 --> 00:01:00.799
Environments where sending everything to the SIEM is just too expensive or simply not possible.
00:01:00.799 --> 00:01:09.120
So if deception gives you cheap, fast, high confidence visibility, why did the industry stop talking about it?
00:01:09.120 --> 00:01:12.959
And why should you maybe start looking at it again?
00:01:13.760 --> 00:01:17.040
I'd say the spark that started to trace bit was my previous role.
00:01:17.040 --> 00:01:25.040
I led the engineering team, and I was also at times like the de facto CISO for an email security company called Tessian.
00:01:25.040 --> 00:01:26.879
They got sort of proof point a few years ago.
00:01:26.879 --> 00:01:31.280
Um, and it was there basically in that role as thinking about security of the organization.
00:01:31.280 --> 00:01:33.359
I wanted to do deception.
00:01:33.359 --> 00:01:38.799
So I was thinking about how we could detect thractors that got into our environment, how we would do that.
00:01:38.799 --> 00:01:50.319
And because of like the large, sprawling, ever-changing nature of our environment, uh, the idea of deploying some like tripwires effectively around that environment to detect intrusions seemed like a good idea.
00:01:50.319 --> 00:01:57.599
Long story short, we looked at the market, nothing really made sense for this kind of large, ever-evolving cloud environment.
00:01:57.599 --> 00:02:04.959
Um, we looked to build something ourselves in-house, realized to do that would take actually way too many resources that we couldn't justify.
00:02:04.959 --> 00:02:06.400
Um, so we shelved the project.
00:02:06.400 --> 00:02:09.599
And I can't really share the details, but we were unfortunately hit by an incident.
00:02:09.599 --> 00:02:14.639
It's actually a supply chain attack that led us to deeply regret not investing in deception.
00:02:14.639 --> 00:02:19.360
Um, we realized that if we had done, we'd have caught something maybe six months before we we wouldn't have done.
00:02:19.360 --> 00:02:24.800
Fortunately, there was not a significant impact to the business, but that was kind of the spark really that started TraceBit.
00:02:24.800 --> 00:02:33.599
Myself and my co-founder were both deeply involved in that incident, and we kind of saw the opportunity that that deploying some deception in the environment would have would have saved us, basically.
00:02:34.159 --> 00:02:37.680
Do you think that what incident would have been any different if you actually had deception in place?
00:02:37.680 --> 00:02:38.240
100%.
00:02:38.560 --> 00:02:53.840
Yeah, so so um again, I don't want to go on don't want to go into too much detail, but when we when we dug into it, the the the deception we wanted to deploy would have been hit on day one of this this incident, and we didn't actually pick up signals till months later.
00:02:54.719 --> 00:03:02.879
Would you mind explaining you said tripwires, uh canneries, I've heard, I've heard honey pots as well, and I know there's a difference there.
00:03:02.879 --> 00:03:03.919
What is deception?
00:03:04.240 --> 00:03:04.879
Yeah, for sure.
00:03:04.879 --> 00:03:10.400
Um so deception technology has has many different definitions, and it can be quite confusing.
00:03:10.400 --> 00:03:21.520
I mean, fundamentally, the idea is to create artificial resources somewhere inside your environment, could be inside the perimeter, outside the perimeter, to deceive attackers in one way or another.
00:03:21.520 --> 00:03:24.479
People do this to seek when they seek different outcomes.
00:03:24.479 --> 00:03:31.360
Some are seeking to produce threat intelligence to understand more about the threat actors are how are how they're attacking them.
00:03:31.360 --> 00:03:33.599
That's when you'll often hear like the word honeypot used.
00:03:33.599 --> 00:03:41.039
So this is where you might put a honeypot on the internet and you might associate it with your organization and you know, see who's going after you and what they're trying to do.
00:03:41.039 --> 00:03:42.960
And that would produce threat intelligence.
00:03:42.960 --> 00:03:47.439
What we focus on at TraceBit is more on the tripwire side of things.
00:03:47.439 --> 00:03:52.639
And that's where you hear terms like canaries or honey tokens or these sorts of things.
00:03:52.639 --> 00:03:55.280
And they would often be deployed inside the perimeter.
00:03:55.280 --> 00:03:58.319
And that the goal is high fidelity detections.
00:03:58.319 --> 00:04:03.039
But ultimately, they're they're fake resources that should never be interacted with by a threat actor.
00:04:03.039 --> 00:04:08.639
So it could be in a cloud environment, you might have an S3 bucket that should never be read.
00:04:08.639 --> 00:04:15.120
And if someone goes and reads it, you would jump on that signal because it likely indicates there's some compromise or some insider risk.
00:04:15.919 --> 00:04:19.839
Would you mind going into some of those artificial resources and what they actually are?
00:04:19.839 --> 00:04:23.040
You mentioned AW or an A or S3 bucket you said.
00:04:23.120 --> 00:04:23.759
Yeah, yeah, for sure.
00:04:23.759 --> 00:04:24.160
Um, yeah.
00:04:24.160 --> 00:04:30.000
So I mean the kind of classic way of doing this was uh virtual servers or network-based canaries.
00:04:30.000 --> 00:04:36.399
So you might have an SSH server or you might have a web server or a telnet server even, and you might be seeing who logs into those.
00:04:36.399 --> 00:04:46.639
Um the kind of approach we've taken that is a little bit different from these more traditional ways of doing things is leveraging like serverless resources in cloud environments.
00:04:46.639 --> 00:04:51.920
The reason we've done that is one, that is how threat actors are traversing through these environments.
00:04:51.920 --> 00:04:58.000
You know, they're generally not getting access to a network and running Nmap and then trying to get into a server.
00:04:58.000 --> 00:05:04.480
They're generally getting access to some credentials and then trying to move laterally or escalate privilege by jumping around.
00:05:04.480 --> 00:05:09.680
It could be roles or secrets or buckets or things like that in those environments.
00:05:09.680 --> 00:05:19.920
So, what we would canary, as we call it, would create deceptive resources for would be things like an S3 bucket or a secret manager secret in AWS, an IAM role.
00:05:19.920 --> 00:05:24.959
We do a ton of different things in a ton of different cloud environments, but it's it's the serverless resources.
00:05:24.959 --> 00:05:33.279
And the other benefit of that, as well as in being like how the attack paths actually look in environments, is they're actually very low cost and low maintenance.
00:05:33.279 --> 00:05:42.000
So it's basically financially intenable for any of our customers to deploy uh network honeypot into every virtual network they have in their system.
00:05:42.000 --> 00:05:45.920
They could have thousands of virtual networks, servers cost money to deploy.
00:05:45.920 --> 00:05:48.000
It's not really feasible to do that.
00:05:48.000 --> 00:05:56.240
But if you compare that to like an S3 bucket, which is basically free to deploy, you could deploy thousands and thousands of these without incurring a financial cost.
00:05:56.240 --> 00:05:59.040
And then also the cloud providers are maintaining these for you.
00:05:59.040 --> 00:06:00.959
You know, you're not patching your S3 bucket.
00:06:00.959 --> 00:06:04.399
So the actual risk and operational overhead of deploying these is also very low.
00:06:04.720 --> 00:06:05.199
Interesting.
00:06:05.199 --> 00:06:09.519
I was gonna ask you, how did you go about choosing those artifacts?
00:06:09.519 --> 00:06:12.160
Was it because of incidents that are going on?
00:06:12.160 --> 00:06:20.000
That's probably a little bit of that, and also because they are you also had to balance that with like the keep the operational overhead low.
00:06:20.319 --> 00:06:20.800
Exactly.
00:06:20.800 --> 00:06:28.240
So so yeah, of course, we're we're always gonna focus on you know, where are the like the juicy parts of an attack path that the attackers are after going after?
00:06:28.240 --> 00:06:34.879
So, like reading public threat reports, speaking to customers, that's like part of it, and popular resources as well, right?
00:06:34.879 --> 00:06:40.480
It's it's no good, it's no good as building a product around a resource that is very, very rare in environments.
00:06:40.480 --> 00:06:42.079
We we're shooting for that realism.
00:06:42.079 --> 00:06:43.360
And actually, it's surprising.
00:06:43.360 --> 00:06:50.160
We actually have you know six resources we do in AWS, and we're constantly hearing from customers like, actually, those are the ones I'm I'm worried about, like by and large.
00:06:50.160 --> 00:06:50.959
So that's part of it.
00:06:50.959 --> 00:06:52.800
Like, are these actually used in attack paths?
00:06:52.800 --> 00:06:57.120
And then, yeah, the other part is like the operational overhead, but also the risk, right?
00:06:57.120 --> 00:07:03.120
So the other benefit of an S3 bucket is it's many, as an example, is it's in many ways benign.
00:07:03.120 --> 00:07:09.680
You know, if a threat actor gets full access to that and uh you know they're able to do whatever they want with it, they don't have remote code execution.
00:07:09.680 --> 00:07:13.199
They can't like leverage that as a foothold and then pivot around the network from there.
00:07:13.199 --> 00:07:17.680
Uh, compare that to a server, there's actually quite a lot of risk with deploying a server in an environment, right?
00:07:17.680 --> 00:07:24.160
If I exploit your Honeypot server, it's like it's like a own goal that a lot of security teams don't really want to take that risk on.
00:07:24.160 --> 00:07:28.399
So the operational overhead and the the low risk is very much a big part of it as well.
00:07:29.279 --> 00:07:30.800
Do customers want different things?
00:07:30.800 --> 00:07:36.959
Do they ever ask you to make you know canaries for them that you didn't make before?
00:07:37.279 --> 00:07:42.240
So part of what we do with the platform is like customizing these canaries.
00:07:42.240 --> 00:07:48.480
So we will scan our customer environments and we're gonna like we're gonna take the naming configuration for the resources we we deploy.
00:07:48.480 --> 00:07:50.160
So it's gonna look similar.
00:07:50.160 --> 00:07:55.439
Um worth saying as well, actually, that the nice thing about that is it's quite hard to fingerprint these these things.
00:07:55.439 --> 00:08:05.120
You know, like uh an IAM role, let's use a different example, in a in an AWS account, only has a handful of properties to it that an attacker can see before they actually start interacting with it.
00:08:05.120 --> 00:08:08.879
So it's actually quite easy to make these blend in with the rest of the environment.
00:08:08.879 --> 00:08:13.279
Again, compared to a server, which is going to be fingerprintable over TCP.
00:08:13.279 --> 00:08:19.920
So that gets us very far with customers, just like making the resources named in a similar way and configured in a similar way.
00:08:19.920 --> 00:08:31.519
Where we want to get to is like imagine a world where you plug some threat intelligence into Claude or Codecs, and you say, Hey, I want some deception in my environment if for this threat actor.
00:08:31.519 --> 00:08:44.399
Uh and you know, you plug into TraceBit and we can deploy like nested canaries and deception around your organization, both on the out external perimeter and internal perimeter to detect and deceive that specific threat actor.
00:08:44.399 --> 00:08:45.519
That's not where we are today.
00:08:45.519 --> 00:08:51.519
We deploy lots of canaries at scale for for good coverage, uh, but that's where we want to go with the platform.
00:08:51.919 --> 00:08:53.360
I understand the internal case.
00:08:53.360 --> 00:08:54.720
What's the external case?
00:08:55.200 --> 00:08:59.440
So historically, the external case has been, to my point earlier, around threat intelligence.
00:08:59.440 --> 00:09:01.759
So putting pieces of honeypot, yeah, the research.
00:09:01.759 --> 00:09:02.879
Yeah, exactly.
00:09:02.879 --> 00:09:10.320
Um we have this feature we're launching soon called perimeter canaries, where you could point some public facing infrastructure at trace bits.
00:09:10.320 --> 00:09:14.159
So imagine vpn.customer.com points to us.
00:09:14.159 --> 00:09:21.919
Now, obviously, it's not it's not super useful for us to tell you someone scanned vpn.customer.com because that's going to be happening all day, every day.
00:09:21.919 --> 00:09:23.120
It's not actionable.
00:09:23.120 --> 00:09:24.320
You know, what are you gonna do with that?
00:09:24.320 --> 00:09:27.679
Your security team's already really busy, you know, they don't they don't need more information.
00:09:27.679 --> 00:09:29.279
It's not that's not super useful.
00:09:29.279 --> 00:09:37.600
But what if you placed a cookie on every single one of your users' workstations that referenced VPN.customer.com with a with a unique cookie.
00:09:37.600 --> 00:09:49.279
Well, now if a threat actor gets into that one of those workstations and they dump the cookies in an attempt to like move laterally, you know, or run an info stealer as is often the way, that's gonna be like really high up on their list of targets.
00:09:49.279 --> 00:09:51.519
Because they think they're they're gonna think they've got the VPN access.
00:09:51.519 --> 00:09:54.000
It's gonna make it look really believable and really legitimate.
00:09:54.000 --> 00:10:01.600
And then you know, you can imagine the future like customizing that to specific instance you've had or specific like things that are being targeted in your industry.
00:10:01.840 --> 00:10:03.120
Yeah, cool.
00:10:03.120 --> 00:10:07.039
So I had an episode four years ago about deception.
00:10:07.039 --> 00:10:08.240
I called it deception.
00:10:08.240 --> 00:10:08.480
Yeah.
00:10:08.480 --> 00:10:09.759
Uh as with Illusive.
00:10:09.759 --> 00:10:10.080
Okay.
00:10:10.080 --> 00:10:12.879
And then a couple, it mightn't have been that long before that.
00:10:12.879 --> 00:10:14.879
I had one on uh honeypots.
00:10:14.879 --> 00:10:20.000
But I haven't seen the adoption take off in in our neck of the woods, right?
00:10:20.000 --> 00:10:20.960
Uh in Europe.
00:10:20.960 --> 00:10:22.960
Why is that and what's changed?
00:10:23.360 --> 00:10:25.279
Yeah, uh, it's it's absolutely not taken off.
00:10:25.279 --> 00:10:34.720
And I think, you know, if you look at the history of this, you can see there was a lot of venture capital excitement in in Deception, maybe eight to ten years ago, and that's where companies like Elusive came out of.
00:10:34.720 --> 00:10:37.200
Uh, there were there were a bunch of them, and there was a lot of excitement.
00:10:37.200 --> 00:10:44.639
And I think I hear stories that if you went to RSA 10 years ago, like the expo floor was full of like deception technology as far as the eye could see.
00:10:44.639 --> 00:10:52.639
Uh, and you're right, like, you know, you speak to a CISO, and there's probably, I would say there's a 90% chance they're familiar with Deception and see some value in it.
00:10:52.639 --> 00:10:57.120
I'd say there's a 5% chance they've actually deployed it today, like from our experience.
00:10:57.120 --> 00:11:10.879
Um, I think that past wave of technologies from the folks we speak to that that bought and deployed them, they suffered a lot from some of the challenges I've already touched on around the heavyweight nature of deploying like virtual machines.
00:11:10.879 --> 00:11:16.240
And some of these technologies you actually shipped to a physical rack you had to go deploy into your data center.
00:11:16.240 --> 00:11:18.799
And then these things are expensive to deploy, right?
00:11:18.799 --> 00:11:20.399
You want to deploy like hundreds of servers.
00:11:20.399 --> 00:11:23.360
There's actually like a significant financial cost to deploy them.
00:11:23.360 --> 00:11:26.639
And then again, there's uh an operational overhead.
00:11:26.639 --> 00:11:33.039
The other challenge that I understand from folks who deployed these is that that like maintenance and management of them.
00:11:33.039 --> 00:11:39.519
So they often gave you some really nice building blocks to go and deploy deception in your environment, but they they left you to it.
00:11:39.519 --> 00:11:43.840
Like you had to go and go and figure out where to where to put all of this all of this stuff.
00:11:43.840 --> 00:11:49.679
Um, and because it was in the data center and it was an on-prem network, it was quite a lot of work to go and do that.
00:11:49.679 --> 00:12:03.279
We think it's different this time because like the cloud, you know, teams have aligned behind certain technologies, like Terraform is one of those, Kubernetes is another one, which allow for like the rapid scale of infrastructure around your environments.
00:12:03.279 --> 00:12:06.639
That infrastructure is lightweight, it's easy, easy to deploy.
00:12:06.639 --> 00:12:10.240
The other unlock for us uh has been LLMs.
00:12:10.240 --> 00:12:15.200
So we are using LLMs to create suggestions to customer environments.
00:12:15.200 --> 00:12:17.919
So when we started the company three years ago, they weren't that great.
00:12:17.919 --> 00:12:24.559
We did things like look to prefixes and suffixes for our naming schemes and things like that, but they've obviously come on leaps and bounds.
00:12:24.559 --> 00:12:41.120
So we will actually take metadata from customers' environments and we'll use that to say, hey, you know, create me sets of resources that are attractive to would-be attackers, that are benign to would-be attackers, create all these different resources and make them look realistic and tell a realistic story for this environment.
00:12:41.120 --> 00:12:45.200
And the security teams we show this stuff to are like, wow, like, you know, I wouldn't have even thought about that.
00:12:45.200 --> 00:12:49.120
Or I forgot we even did that project, but it'll be great to have a canary over there.
00:12:49.120 --> 00:12:54.879
So that that time save is a big part of it because security teams are usually the most busy people in the company.
00:12:54.879 --> 00:13:01.039
And the idea of spending three weeks to go and come up with some great deception is just not really feasible.
00:13:01.039 --> 00:13:04.399
Then, not least, if you think about maintaining that in the long run, right?
00:13:04.399 --> 00:13:06.639
Because your environment's going to change in six months from now.
00:13:06.639 --> 00:13:13.440
So six months, six months down the line, are you really gonna put in like another couple of weeks to go and move the deception around and reconfigure it?
00:13:13.440 --> 00:13:20.159
But if you automate that from day one and you use LLMs to create believable looking deception, that's where we think there's a lot of value.
00:13:22.080 --> 00:13:23.759
SOC, Security Operations Center.
00:13:23.759 --> 00:13:28.639
I'm assuming all your customers today are probably large and mature.
00:13:28.639 --> 00:13:30.480
And we can get back to whether we need to be.
00:13:30.480 --> 00:13:31.200
We can get back to that.
00:13:31.200 --> 00:13:32.399
Yeah, whether you need to be not.
00:13:32.399 --> 00:13:33.840
Yeah, we talked about this before.
00:13:33.840 --> 00:13:34.240
Yeah.
00:13:34.240 --> 00:13:40.480
But the ones that do have it today, what does it look like when they have deployed this technology in their current SOC?
00:13:40.480 --> 00:13:41.919
Like how does that coexist?
00:13:42.320 --> 00:13:43.840
Yeah, so it's it's fairly straightforward.
00:13:43.840 --> 00:13:46.000
We'll we'll usually be working with the SOC often.
00:13:46.000 --> 00:13:47.519
The SOC will buy trace bit.
00:13:47.519 --> 00:13:49.679
Obviously, it depends from customer to customer.
00:13:49.679 --> 00:13:52.480
But fundamentally, we are feeding these alerts into their sim.
00:13:52.480 --> 00:13:59.039
Uh and then the SOC team is taking those, it's they're augmenting them with other data in their environment, and then they're responding to those alerts.
00:13:59.039 --> 00:14:01.279
So it's it's relatively relatively simple.
00:14:01.600 --> 00:14:11.360
If you know everybody has a limited budget, if you had to take something out to put this in, make the make the case for you know spending 500k on trace bit then and 500k on something else.
00:14:11.360 --> 00:14:11.919
Yeah.
00:14:12.240 --> 00:14:12.559
Yeah.
00:14:12.559 --> 00:14:18.240
Um, I think there's we we have worked with customers on use cases around sim usage.
00:14:18.240 --> 00:14:23.440
And you know, we've we've heard from them, hey, I'm I'm not even doing anything with this sim data, it's way too noisy.
00:14:23.440 --> 00:14:26.000
I'm getting I'm getting too many alerts off it already.
00:14:26.000 --> 00:14:30.399
Uh certainly other tools like guard duty and things like that, like there's just no value in it.
00:14:30.399 --> 00:14:34.080
But I don't want to turn it off because that would leave me with zero visibility in that environment.
00:14:34.080 --> 00:14:37.200
So in some cases, there's a billion the ability to do that.
00:14:37.200 --> 00:14:42.399
I think the other interesting use case is when teams are wasting time on false positives.
00:14:42.399 --> 00:14:46.639
And again, they're in that state where they either put time into tuning them out, they turn them off.
00:14:46.639 --> 00:14:48.320
That's that's too much risk.
00:14:48.320 --> 00:15:03.679
There's there's a time-saving piece there where you know you can you can take a set of false positives and say, let's let's just turn these off because they're they're creating too much noise for us and we have comfort that we've augmented this, you know, we've we've replaced this with the visibility trace bits given us into that environment.
00:15:04.559 --> 00:15:08.639
So cheap visibility and no matter what, better than nothing.
00:15:08.639 --> 00:15:09.120
Yep.
00:15:09.120 --> 00:15:09.440
Yeah.
00:15:09.600 --> 00:15:10.480
Yeah, yeah, 100%.
00:15:10.480 --> 00:15:13.440
We go into environments where there just isn't that much telemetry.
00:15:13.440 --> 00:15:23.519
CI CD environments are a really good example of this, where what what logs do you have from those environments, especially if you're running that in in GitHub or Circle CI or places like that?
00:15:23.519 --> 00:15:27.039
Like, do you do you really have that much visibility of what's going on in those environments?
00:15:27.039 --> 00:15:33.600
Like, this is a quick win to get something in there very, very early that's going to give you that high fidelity signal if something is compromised, that environment.
00:15:34.480 --> 00:15:37.039
As we're speaking right now, there's probably a supply chain attack going on.
00:15:37.039 --> 00:15:37.840
I have no doubt.
00:15:37.840 --> 00:15:40.080
Yeah, we'll open our phones after this and read about it.
00:15:40.159 --> 00:15:40.399
I'm sure.
00:15:40.720 --> 00:15:41.360
Knock on the table.
00:15:41.360 --> 00:15:41.679
Yeah.
00:15:41.679 --> 00:15:47.360
Uh how would you, your technology, any deceptive technology sort of fit in that use case?
00:15:47.679 --> 00:16:00.080
Yeah, so so we we we did some research recently that we that we published with this, where um the the team PCP attacks that are very friendly for a lot of folks at the moment, one of the things they did was steal AWS keys and SSH keys from environments.
00:16:00.080 --> 00:16:02.240
And that's one of the ways that they that they spread.
00:16:02.240 --> 00:16:10.720
So very concretely, we ran some of that, those info stealers within some GitHub actions, and we were able to show that these would these would take these these keys from these environments.
00:16:10.720 --> 00:16:13.600
So TraceBit would detect when those keys were being used.
00:16:13.600 --> 00:16:20.399
One of the nice things that we do is we generate unique keys for every single build that runs in an environment.
00:16:20.399 --> 00:16:22.960
So like the scale is a big, a big important part of it.
00:16:22.960 --> 00:16:28.559
And what that means is when TraceBit goes off, you can actually jump to the exact build that this occurred in.
00:16:28.559 --> 00:16:30.720
So we met folks who've like built this themselves.
00:16:30.720 --> 00:16:38.000
They put a single AWS key in a Git repo that hundreds of developers have access to, and it pings one day from a funny IP address.
00:16:38.000 --> 00:16:41.039
And you fundamentally don't actually end up doing anything with that alert.
00:16:41.039 --> 00:16:48.000
You know, you know something bad has happened, but you don't even have the data or the telemetry to go and figure out where that bad thing has has occurred.
00:16:48.000 --> 00:16:55.840
Um, whereas when Tracebook goes off in an environment where like, hey, it was this build, you know, the the credential existed, you know, in the context for like 10 minutes.
00:16:55.840 --> 00:16:57.519
Like you need to go and investigate this right now.
00:16:57.519 --> 00:17:00.960
And obviously, if a lot more light up, then you know you'll have a you'll have a big impact.
00:17:01.600 --> 00:17:03.919
What about the other top initial access?
00:17:03.919 --> 00:17:11.920
Uh I mean, thinking of like, yeah, Mandiant would say that uh appliances getting popped are the uh the largest or info stealers, uh phishing.
00:17:11.920 --> 00:17:14.400
Do you uh do you have use cases for all those sort of yeah?
00:17:14.480 --> 00:17:16.880
So we do we do a lot on on workstations.
00:17:16.880 --> 00:17:19.759
So deploying deploying credentials onto workstations is a big one.
00:17:19.759 --> 00:17:25.039
I've mentioned this the session cookie piece that we're we're working on at the moment that I think is going to be gonna be really, really powerful.
00:17:25.039 --> 00:17:27.759
Um yeah, appliances I think is another really good example.
00:17:27.759 --> 00:17:33.759
Um we don't have like a ton of uh active deployments there, but I think credentials on appliances is super powerful.
00:17:33.759 --> 00:17:39.359
You don't have, you know, these they are often so underpowered you can't create logs or ingest those logs into your sim.
00:17:39.359 --> 00:17:45.680
But it's pretty trivial to go have like a cron, go deploy a uh a unique credential every every 24 hours.
00:17:45.680 --> 00:17:50.319
And if someone got onto that system, that's gonna look like a really attractive opportunity to move laterally.
00:17:50.319 --> 00:17:52.079
So that's the sort of detection we would make.
00:17:53.279 --> 00:17:55.279
Forgot his name, Caleb Simer.
00:17:55.279 --> 00:17:55.839
Caleb?
00:17:55.839 --> 00:17:56.240
Yes.
00:17:56.240 --> 00:17:57.200
He's fantastic.
00:17:57.200 --> 00:17:58.799
I don't know him, unfortunately.
00:17:58.799 --> 00:18:02.240
But uh he was on the cloud security podcast, I believe it was.
00:18:02.240 --> 00:18:04.880
Um, also a fantastic podcast.
00:18:04.880 --> 00:18:16.079
He said that it was surprising to him that companies don't invest that they go for like a big expensive sock as a reactive capability instead of going for something like your technology.
00:18:16.079 --> 00:18:16.640
Yep.
00:18:16.640 --> 00:18:19.119
I would assume that you would agree and like him saying that.
00:18:19.119 --> 00:18:21.119
Yeah, I thought it was really interesting.
00:18:21.119 --> 00:18:24.880
Uh because I I I share his viewpoint.
00:18:25.279 --> 00:18:28.480
We really do see this as a as a quick win that you can do early on.
00:18:28.480 --> 00:18:36.960
Um, by deploying deception previously, this was going to be something that was actually gonna create a bit of a workload for the team just to keep the thing like valuable.
00:18:36.960 --> 00:18:40.480
Whereas now it's automated, now this is something you can just plug and play.
00:18:40.480 --> 00:18:45.599
I I, incredibly biased, do think, you know, why not just do this like on day one of your security program?
00:18:45.599 --> 00:18:48.799
Like the idea that the times of value on deploying a sim, right?
00:18:48.799 --> 00:18:50.240
I'm talking like super early on.
00:18:50.240 --> 00:18:51.839
Like the times of value on deploying a sim.
00:18:51.839 --> 00:18:58.640
We speak to teams, you know, you come back six months later and they're still integrating this data source and that data source, they're still tuning.
00:18:58.640 --> 00:19:07.599
Like they could have had some super high fidelity detections across like a broad set of their environments within weeks if they deployed some deception in that environment.
00:19:07.599 --> 00:19:11.359
So I I think that like it is it is a massive quick win, but I'm obviously very biased.
00:19:11.599 --> 00:19:15.200
Yeah, SIEM is a never-ending project, as uh we both know.
00:19:15.200 --> 00:19:16.640
Uh LLMs.
00:19:16.640 --> 00:19:17.119
Yes.
00:19:17.119 --> 00:19:19.599
What are your thoughts around LLMs and deception?
00:19:19.839 --> 00:19:22.240
Yeah, I think there's I think there's like two key parts to this.
00:19:22.240 --> 00:19:25.039
Like one is offensive AI agents.
00:19:25.039 --> 00:19:28.720
Um we've actually done our own research on on this.
00:19:28.720 --> 00:19:38.160
Uh so we we created like a cloud lab and we we tested this out and we had an environment where they could get to basically root in in 14 minutes.
00:19:38.160 --> 00:19:47.680
Um, so I think I think LLMs for any security team right now, specifically offensive AI agents, you know, mean that attackers are gonna run much quicker through their environments.
00:19:47.680 --> 00:19:54.559
I also think they're just gonna have a broader set of techniques that they're gonna have available to them to get into those those environments.
00:19:54.559 --> 00:20:00.319
So, so for us, that means you want those high fidelity signals as soon as humanly possible.
00:20:00.319 --> 00:20:05.359
Um, and our tests show that that trace bit canaries like play a really good role in that.
00:20:05.359 --> 00:20:16.880
So the the the data we've we've produced and we've we published this show that we can make these detections of these offensive AI agents, like eight minutes into their their path to to domain admin.
00:20:16.880 --> 00:20:18.880
I I want to get that that number down.
00:20:18.880 --> 00:20:22.240
Uh, and I think there's there's all sorts of work we can we can do there.
00:20:22.240 --> 00:20:27.920
But I really think that, yeah, it's it's it's obvious that this is going to get um more and more serious over time.
00:20:27.920 --> 00:20:35.599
When the open weight models you know get this, get that good, which is probably six months away, we're gonna be in a really interesting situation.
00:20:35.599 --> 00:20:42.880
Um the other the other piece worth touching on uh that we do see in customer environments is like the internal AI agents.
00:20:42.880 --> 00:20:45.839
So you know, customers are are deploying these.
00:20:45.839 --> 00:20:51.440
Uh sometimes they're allowed to, sometimes it's it's shadow AI, you know, to do their to do their job.
00:20:51.440 --> 00:21:00.480
Um and what we're finding with deception is actually proving is quite a valuable detection for when those internal authorized AI agents like overstep the mark.
00:21:00.480 --> 00:21:09.200
So we've had examples in customer environments where the security team were surprised to find an AI agent you know make it all the way to a production canary.
00:21:09.200 --> 00:21:13.359
Uh and turns out, you know, an engineer was saying yes, yes, yes, yes, yes.
00:21:13.359 --> 00:21:20.319
And that's been a really useful uh detection for the security team to have that they otherwise wouldn't really have had any visibility of.
00:21:20.799 --> 00:21:27.519
So there's an insider use case here, not necessarily a human being or malicious insider, or but but it does cover both.
00:21:27.759 --> 00:21:37.359
We we cover both, and yeah, I've we've not really touched on that, but like folks will like buy Trace bit, usually for the outside in, the the external threat actor, and we'll provide value there, of course.
00:21:37.359 --> 00:21:41.920
But those um those detections, you know, are fortunately in most customer environments relatively rare, right?
00:21:41.920 --> 00:21:44.240
No, you're not getting popped every week.
00:21:44.240 --> 00:21:49.680
But the insider, you know, the someone who's it's it's not even insider risk, it's sometimes risky insider.
00:21:49.680 --> 00:21:51.680
You know, it's uh it's non malicious intent.
00:21:51.680 --> 00:22:02.079
Someone's trying to do their job, but maybe they've strayed into an environment they should have, maybe they're they've gone off a pro off a process they they shouldn't be following, and you know, they they End up saying off a canary.
00:22:02.079 --> 00:22:20.160
And those are often signals that the sim isn't tuned to detect and you know the security tool isn't set up to detect, but can often be the smoking gun for a security team that allows them to get a process fixed, you know, get some training improved, you know, get some um get some like guardrails tightened up and reduce risk for the business.
00:22:20.880 --> 00:22:26.799
Maybe uh sort of far out there, but has anybody ever used your technology for incident response use case?
00:22:27.119 --> 00:22:30.000
Uh it's something we have uh have explored with a few folks.
00:22:30.000 --> 00:22:36.000
But yeah, I think it's I think it's a super interesting use case, you know, when you you know someone is in the system and like proactively deploying that out.
00:22:36.000 --> 00:22:37.200
Just slow them down, right?
00:22:37.200 --> 00:22:42.640
Slow them down, confuse them, uh, detect them in places you you're you might not have telemetry for.
00:22:42.640 --> 00:22:44.319
Uh yeah, it's it's something we're exploring.
00:22:44.319 --> 00:22:46.400
It's not something we actively do with a product today.
00:22:46.640 --> 00:22:49.759
What was that study that we talked about in the elevator on the way up here?
00:22:49.920 --> 00:22:51.039
Uh the Tularosa study.
00:22:51.039 --> 00:22:51.839
Yeah, tell us that.
00:22:51.839 --> 00:22:58.960
Yeah, so the Tularosa study was um they took a couple hundred pen testers and it was kind of a test with a quadrant.
00:22:58.960 --> 00:23:08.880
So uh somewhere they were told there was deception and somewhere they were not told there was deception, and somewhere there um there was deception, and somewhere there wasn't deception.
00:23:08.880 --> 00:23:17.759
So that that was a quadrant, and that and they were trying to test out, you know, if you tell people there's deception in an environment and there isn't, like, does it change their behavior?
00:23:17.759 --> 00:23:22.720
Uh and if you put deception in environment and the and you don't tell people about it, does it does it change the behavior?
00:23:22.720 --> 00:23:23.839
Can you make detections?
00:23:23.839 --> 00:23:34.880
And yeah, the the the long and the short of it is they found that even the understanding or perception that deception was in an environment did change behavior and made folks less likely to reach their goal.
00:23:34.880 --> 00:23:41.839
And to the point earlier around the research we've been doing, we found that the same is true for for AI agents in environments.
00:23:41.839 --> 00:23:43.759
So I think it was Opus specifically.
00:23:43.759 --> 00:24:02.240
We found when you we ran this through our cloud lab, if you told Opus there was deception in the environment, its likelihood of reaching admin went from 20% to 3%, just because it believed canaries were there and it was trying to avoid them or taking steps to not get detected.
00:24:03.599 --> 00:24:17.039
I feel like it was one of your podcasts you had with uh the guy from Riot where you said uh where one you guys talk together and and you arrived at the conclusion that if everybody moves to deception, it'll be a cat and mask game as security always is, and the attackers will change.
00:24:17.039 --> 00:24:22.559
So in five years, if TraceBit is super successful and everybody's using Deception, what does the world look like then?
00:24:22.559 --> 00:24:24.559
What are the attackers gonna do differently?
00:24:24.880 --> 00:24:25.839
Yeah, it's a great question.
00:24:25.839 --> 00:24:34.400
I mean, and I think that's that is the case where we would make the case that like partnering with a vendor makes a lot of sense because you know you want someone, someone actively developing this.
00:24:34.400 --> 00:24:50.160
Because even if you went and did your own automation and set that up and did a really good job of it, so it does evolve automatically, you know, you're not gonna be inventing new resource types, you're not gonna be plugging different pieces together, you're not gonna be like building support for more systems over time, you're gonna build one piece.
00:24:50.160 --> 00:24:56.079
Uh, so for us, that's why it's really important uh to be constantly evolving the platform and adding new features.
00:24:56.079 --> 00:25:10.480
Um, and that's also why we're really excited about this like AI range that we've we've set up, because we can constantly iterate AI agents against these against these environments, and as they get better, um, we can detect that and we can evolve the product and platform to get better at detecting them.
00:25:11.519 --> 00:25:22.400
Is there ever like a case where you have so many canaries inside of an environment that like even that the attacker has to just and they just move on and they give up?
00:25:22.640 --> 00:25:23.039
Yeah, yeah.
00:25:23.039 --> 00:25:29.119
It's um so I think Kelly Shortridge from Fastly wrote about this uh in an article called Sludge for Good.
00:25:29.119 --> 00:25:37.839
And she made the case that you know you could do 95%, 99% uh deception or canaries versus uh 1% real resources.
00:25:37.839 --> 00:25:40.559
That is not something we've explored so far, to be honest with you.
00:25:40.559 --> 00:25:52.400
Uh I think uh you know our focus really is you know ease of deployment for us is also about not getting away in the way of your software engineers who you know are busy people and and you know don't want uh a ton of resources in their way.
00:25:52.400 --> 00:25:56.640
I I do see scope for that in the future for sure as something customers could opt into.
00:25:57.920 --> 00:26:01.200
Because if there were that many resources, how would it be in their way?
00:26:01.759 --> 00:26:01.920
Yeah.
00:26:01.920 --> 00:26:04.079
Uh from a software engineer's point of view, yeah.
00:26:04.079 --> 00:26:18.559
Well, imagine you're logging into a cloud environment and you know you're debugging a production issue at three o'clock in the morning and you're trying to find the real resource that is that is broken, and there's 10,000 canaries in there that you know you have to scroll through or page through.
00:26:18.559 --> 00:26:21.359
Yeah, so it's you know very valuable if you're a threat actor.
00:26:21.359 --> 00:26:25.119
It's gonna be basically impossible for you to find the real resource without sending it off.
00:26:25.119 --> 00:26:29.839
But that could create some friction if you are uh you know a DevOps engineer responding to an incident.
00:26:30.079 --> 00:26:35.759
Yeah, and that's what's been kind of holding deception back, if I understood you correctly, is the operationalization of it.
00:26:36.000 --> 00:26:46.880
The operational holding deception back is the opera opera line opera what's been holding the overhead for sure.
00:26:46.880 --> 00:26:54.160
Um but I would say that like that sludge idea is is maybe just taking things to the to the extreme, which I don't think is a bad idea.
00:26:54.160 --> 00:26:57.680
I just think it's it's something you would not want to put in every single environment.
00:26:57.680 --> 00:26:58.240
Yeah, for sure.
00:26:58.240 --> 00:27:01.279
Because like humans are operating in some of those environments.
00:27:01.440 --> 00:27:02.000
Yeah.
00:27:02.000 --> 00:27:09.519
Do you have any final thoughts or anything that we did not cover that you think is worth mentioning to enlighten security?
00:27:10.000 --> 00:27:16.960
No, I think um honestly, I think if you've if you've been intrigued by what you've heard, I would I'd really go sign up to our community edition.
00:27:16.960 --> 00:27:25.359
Uh something you can go and protect your your home PC with with deception right now, uh, and and your email and your password manager and other pieces like that.
00:27:25.359 --> 00:27:26.960
So I think that's a great place to start.
00:27:26.960 --> 00:27:29.599
Uh if you'd like to know more, you can you can book a demo on our website.
00:27:29.599 --> 00:27:30.000
Cool.
00:27:30.000 --> 00:27:31.519
Andy Smith, thank you so much for your time.
00:27:31.519 --> 00:27:32.160
Thank you much.
00:27:32.160 --> 00:27:33.200
We appreciate it.
00:27:33.200 --> 00:27:34.319
Thanks a lot.
00:27:35.039 --> 00:27:36.799
Well, that's all for today, folks.
00:27:36.799 --> 00:27:39.599
Thank you for tuning in to the Mnemonic Security Podcast.
00:27:39.599 --> 00:27:49.039
If you have any concepts or ideas that you'd like us to discuss on future episodes, please feel free to hit me up on LinkedIn or to send us a mail to podcast at mnemonic.no.
00:27:49.039 --> 00:27:52.400
Thank you for listening, and we'll see you next time.
