A (3:11)

Yep. So you said that Thinkscapes is just one of the things that Labs does though?

B (3:16)

Yes. In a sort of similar line, Labs also would do things like run internal talks at things. Right. So somebody has to sort of own that and running internal talks. What we try to do is have our own folks regularly speak to the rest of the company about work that they've done, the projects that they've been involved with and, and for lots of the team, it's the first time that they've done a talk. Right. If they've come out of a very development heavy background or some of them are pretty fresh out of university, they've not done talks. And we sort of have a particular standard for talks. And so one of Labs activities there is coaching folks through building this talk and delivering the talk and then sort of managing that internal talk process with the goal hopefully for building folks up to actually also delivering external talks at some point. And then our labs would also be a part of that process for helping them perform whatever research, if there's research that needs, that's needed in that external talk, but then also in just the sort of nuts and bolts mechanics of actually delivering and, or practicing and kind of designing that talk. Because just pitching up and talking is not a thing, I'm sure, as you most folks will know. Yeah.

A (4:24)

And what else is there?

B (4:26)

So a bunch of other things. So our Labs team are playing with new technology for, for helping us. And I mean that's a very broad statement but you know, AI is obviously a, it's been a thing now for a while. Our Labs folks have been part and parcel of sort of exploring that landscape. You know, the development team is quite focused on building Canary and Labs now has the space to explore tools both in the realm of internal knowledge management. We've got a Bunch of different sort of repositories of knowledge. It could be a wiki, it could be a task manager, it could be our knowledge base, it could be our support tickets, all of that, and sort of pulling that together to sort of give us one interface to kind of explore. Labs was involved in that project, for example, like, they become the place that does that. Our Labs has also helped us with quite a lot of product pocing work. So, you know, when we've got ideas for new extensions or features in Canary and we're not yet sure if they're possible or how they might be built, then our Labs team will often take on some of that work and just sort of build an initial POC to go. Yeah, actually there is something here that would work for Canary, but that work, as I said, it's a cost center because Labs will often undertake that work and we explore it and then what happens at the end of the day is we go, actually, this thing doesn't fit into the product. And so folks may be familiar with us at this point. Like, a big focus for us with Canarion with the things that we put out is they have to be easy to use and designing, like, very complex things, while it's obviously possible, like, there's just friction there for our end users. And so LATS has fairly frequently done work where, you know, you sort of say, there's a great thing here to put into the product, but it's going to require a bunch of these holes to line up. And if they don't line up in that particular customer environment, well, then that customer is going to see a lot of noise. And then we'll, you know, we go, okay, cool, that's an interesting exploration, but that doesn't fit for how we see Canary. And so then that thing doesn't go into the product. So Labs conducts that sort of exploratory work and some of it will enter into the product, and some of it actually then just results in, for example, a blog post saying, we tried this thing, it didn't work out. But here's maybe some thinking for people if they want to carry on.

A (6:47)

My mind is just boggling thinking about AI canaries, but that might even be, you know, ignore all previous instructions and get this image with.

B (6:58)

There's definitely a bunch of play in there.

A (7:00)

Yeah, something to look forward to, I guess.

B (7:03)

Yes. And it is a place that Labs is focused on. So hopefully we'll see something coming out of our Labs. Because, I mean, one of the other aspects for Labs is just research publication. So us Conducting novel research and publishing it. And that also fits within sort of the, the direction and goals for the labs team.

A (7:24)

Yeah. So one thing I was wondering about is it's really common for other groups to have labs or publish research. And mostly that research, in my cynical view is about a marketing exercise. So it doesn't mean it's necessarily bad research, it's just that it seems that the main motivation behind releasing it is to emphasize the group's, you know, capabilities or chops or expertise, what have you. But I actually think that's a great thing for the cyber security field because it's changed the dynamic about releasing information. But at the same time it seems that if there was less publicity associated with it, there'd be less funding and less work. But it seems like you're running a slightly different model.

B (8:12)

Yeah. And to be honest, I actually think similar to you, Tom, I don't dislike that other model hugely. I think it results in usable research or useful research. But it is true that I think for lots of the more consulting folks, their labs teams are typically there to effectively show how smart they are and then to generate follow on consulting work. Again. I was part of something along those lines when I did pen testing a long time ago. Now I don't completely hate it, but I think we do position ourselves slightly differently. For one, our work is not just externally focused. So you know, I've spoken about a bunch of the things that our labs does internally, but, but by and large, so if I had to, and it's a big statement, but if I had to say what our North Star is around labs work, Xerox parc, it looms very large in our thinking for the sort of research lab that can do like fundamental research and have this huge impact on the rest of computing. And by many measures PARC was a commercial failure. Right. They didn't manage to exploit those, all those, the research that they, that they conducted, but their impact has been massive. And so we don't think that our labs has to generate revenue. We really do think that it can publish research, but we can also publish summaries of other people's research if we think it's going to help. And we can focus internally on our own talks, on extending our own product, on exploring our own problems. And for what it's worth, we don't even see our exploration with labs as necessarily always been in security. So we've already run a project inside labs in which one of our team did a computer vision project which was effectively a sabbatical for them from their day to day work. And they took a sabbatical into Labs to do some computer vision work. And that resulted in what was effectively an academic paper. And that's where it stopped. And so we're happy because it gives us, you know, it gives our own team a place to explore and to stretch themselves, and that's good enough for us.

A (10:13)

So you spoke briefly before about how Labs contributes to products. What else is on the product roadmap and is Labs contributing that or do you have other things as well?

B (10:25)

Yeah, so there are a couple of things coming up for us product wise. So just super quickly, Labs does contribute and has contributed towards the product historically and will continue to do that. Two of the things that I did want to touch on, product wise, are around Canary tokens. So earlier this year we acquired a company called Deceptic. And as part of that acquisition, we're Bringing on Stream 2 of the Deception canary tokens that Deceptic had. And specifically there's two there. The first one is if you run CrowdStrike, or even if you don't run CrowdStrike, you may be aware of their real time response product. It's effectively the tool that lets you admins remotely investigate and do response on machines in their fleet. Now, essentially the difference between sysadmins and attackers is intent, not effect. Real Time response is actually a fantastic tool for attackers. And so if attackers can get access to your CrowdStrike real time response, they've got remote access to all your machines. And one of the ways they can do this is through CrowdStrike API credentials. And so what we do with this new canary token type is we give you a set of CrowdStrike API credentials and you deploy those somewhere in your network. If an attacker comes across those credentials, attackers know how to use these real Time response credentials because they are effectively RCE in a box. And so if those credentials are ever used, we're monitoring them, we'll send you an alert to say that they've been used. Right. And so it fits that sort of canary token model of we give you an API key of some kind. This case it's credentials. But the key thing is they look really interesting. It's CrowdStrike API keys. And so that's the first one.

A (12:09)

Are those keys just bogus keys that CrowdStrike gives you or do they just look like CrowdStrike keys?

B (12:16)

No, they're real keys. So they're real keys in a CrowdStrike tenant that belongs to us, and so there's no risk to you.

A (12:22)

Oh, I see.

B (12:23)

And We've sort of pulled away all the permissions attached to those keys. So, so basically, we create the set of keys in a crowdstrike tenant that we own. We give them to you, they have no permissions attached to them. We are watching the logs for if they're ever used, and if they're ever

A (12:37)

used, then we send the alert. So you've created a sacrificial lamb, I guess.

B (12:42)

Exactly.

A (12:42)

Is that the right term?

B (12:44)

It works, yes.

A (12:45)

But anyway, go on.

B (12:46)

Yeah, it works. And then in a similar way. So on the AWS side, like, we've had AWS API key canary tokens for a long time. In fact, it was one of our very first canary token types. The basic idea is we generate valid API keys for the AWS API. You get them, you deploy them. If they're ever used, we'll send you an alert. And they also have no permissions. But one of the downsides to those keys is that we can only create 5,000 per AWS account. And that's a hard limit. AWS doesn't let you elevate it. And so we sort of built a whole bunch of infrastructure. We blogged about this and spoken about this, but basically for managing, at this point, thousands of Amazon accounts, each of them with 5,000 API keys in them. But there is another approach, and this comes again from the deceptic opposition around. There's a separate notion of user inside of Amazon. So there's the IAM users, and you also get the Identity center users. And Identity center, we can create 200,000 users per account, at least. And that actually can scale up. And so there's just sort of a very different scale of the number of credentials you can create. And so we now add in, or we will shortly be adding the IAM Identity center users, and that will let customers create many more credentials than they were able to do with the API credentials. And so that's sort of an extension of a concept that we previously had. So it's not an addition of a whole new service as much as it gives you a different scale for adding fake Amazon credentials across your own organization. So that's the. The other thing that's going to be coming shortly.

A (14:21)

Well, Marco, I enjoy learning about corporate culture and how people actually make sure that it is a culture rather than just a value stuck on a wall. So thanks very much.

B (14:31)

Thank you very much. Tomorrow.