A (2:49)

So each of those 30 plus models you call them, are they like a different identity platform? So an equivalent of Active Directory?

B (2:59)

Yeah, they're ranging in complexity, so we call them extensions. And today these are all community supported. So they're all. There's no warranty. You go on GitHub and you can use these with your existing Bloodhound instance, whether you're a Community Edition or Enterprise Edition Edition. The further enterprise support we're building out now and we're going to complete that this spring. I'll explain what that means in a second. But each one of these, they range from like what we would call the control plane. Like so an AWS would be something like that, a GCP octa ping, for example. That's your control plane. Then you have the management plane, which would be something like a intune or a jamf. Like if you're maintaining a Mac fleet, you can use JAMF to manage those. And then you have the data plane. And this gets really interesting. It could have everything from like a Snowflake instance to a GitHub account. And that's where like your code is sitting. And each of these have a set of identities that you provision access to certain things within them and they chain together, which is I think the more interesting thing. Each one of these is hard to manage in its own right. You mentioned you can implement best practices for each of them, but chaining them together creates a huge problem that unfortunately seems to be between teams. We'll say that.

A (4:21)

Well, I mean it kind of makes sense, right? If you've got someone managing a particular directory service or whatever you call it, like they're usually not managing the other necessarily.

B (4:31)

Yes.

A (4:32)

So I guess I was wondering, you said it was without warranty. I guess what's the worst that could happen though? You import it into Bloodhound and it says there's an attack path and it doesn't exist or it missed something or.

B (4:44)

Yeah, so like these are all today. There's some that are written by SpectreOps individuals, there's some that are written by completely third party providers. So today just think of them as community open source projects. They can do what they say they do. Sometimes they could break. What we're building on the Enterprise side is kind of a pipeline. So there's going to be a subset of these that are validated. All of them are authored by us. So we understand that they don't present load to the system, they present accurate findings. You can automate the chokepoint analysis that we do in Bloodhunt Enterprise. So it's one thing to see a map, it's one thing to figure out where do you take action in that map. And that's what Bloodhound Enterprise does.

A (5:26)

And so if I'm one of those people who's got different identity systems, what would I get by trying to like combine different, I guess, nomenclature models or different bring them together in blockchain? What would I see and what would I do about that?

B (5:40)

Yeah. So today I'll give you an example of a engagement that we did last, late last year. So we were given the task of basically try to compromise AWS and we did so through GitHub. Now we modeled out all of that using Open Graph so we could see that the account that we had control over had access to a repository. Now, that repository was actually doing good things. It's not like they had hard coded credentials anywhere. But that repo allowed for some control over an account in aws. So basically it was their CICD process. They configured it, quote unquote correctly, but they did so in a way that allowed us to eventually take control of the AWS account. If you were the GitHub admin and if you were an AWS admin, you would not understand this. You only see it when you see the two together. Unfortunately, in that particular case, it wasn't a single employee, it was like every employee. And that was pretty jarring. But I would say that's, I would guarantee that's not unique to them. If you remember the sales off breach probably last fall, the same thing happened. It was like you went from GitHub to AWS to control over all these Salesforce instances through OAuth tokens. It's the same problem. So individually you can think you're making really good configurations. Looking at them in totality is when you realize you did something wrong.

A (7:12)

Could you actually use Bloodhound to identify the sales loss problem? Yes.

B (7:17)

Yeah, yeah, absolutely. I mean you can say, well, okay, I can't rewind time and say we could have done it then today if we had. If we had visibility over it. Yes, we could. Because we would understand that the AWS role, that they had access to some OAuth tokens, the limited amount of information that was out of that breach, we could say that, yes, we could detect that.

A (7:40)

Right. So is that just the understanding more you're uncovering? I guess it's like the red queen in Alison. You're running very, very, very hard to stay still. As the, as there's this drive for people to combine or. Well, they're not necessarily combining them, are they? There's just these interactions between different systems.

B (8:01)

Yeah, yeah, there's, I mean, so it's not, it's not that we're uncovering more. It's, I guess, two things. This, the connections have always been in place. And I don't think anybody in security, we've talked to a lot of different, like, and this is paranoia for them. Right. We, like, we have developers making assumptions on the identity side, like we're going to configure this setting or oauth to this source. And that seems good in isolation, but like, again, in totality could be pretty bad. And that's not a new situation. We're just uncovering it. And I'm not saying that you can replace a pen test or a red team with Bloodhound, so don't take this that way. But people could find this in the past, but they were super experts. Right. And you had to make sure that like they found the right setting at the right time. Those kind of known escalations, those, those ways that we connect identities, we can do that now with Bloodhound. So we discover it on a, on a engagement and then we pump it back into Bloodhound.

A (9:01)

So over time, how have you seen your customers evolve their practices? I guess it seems to me that this would be a new frontier that over time people would understand and start to adjust practices. Is that actually happening?

B (9:15)

Yeah, yeah. So two things on that. So first again, we started with Active Directory and there's been 20 years of active Directory technical debt. So once people get their hands on that, then they're like, oh my gosh, now I want to fix other things. And so that's what pushed us to go Open Graph. There's a couple things that we had to develop along the way. So one thing that we're putting in the new version of Bloodhound Enterprises is this feature called ETAC or Environment Targeted Access Control. Yes. It's a very engineering type branding. So forgive me, but what it means is it's useful for people who just deal with Active Directory. So we've had large multinational companies say, like we acquire a bunch of companies every year, we want to get visibility over, let's say Acme Corp, and we want to give Acme Corp that visibility too. But we don't want to open up their view to our entire environment, so only give them access to that one domain. The same thing applies now with Open Graph. So you're probably not going to want to have your Snowflake admin see the rest of your enterprise, but they need to have the visibility to fix problems within Snowflake and then you needed to see kind of the all up view. So that's what we, we've been basically just responding to what we see people using. The other thing is you mentioned like, you know, running fast and staying still. We think you're, you're going to be tackling bigger problems, but there's always companies that just don't have the resources or the expertise. And so that's why this year we've launched Bloodhound Sentry, which is kind of an identity risk reduction service. Basically it augments our product with our experts. So whether it's like the basic configurations and getting things deployed and configured or remediating attack paths, a lot of people are very scared when they see some attack paths like am I going to take something offline? Or how would I do it most efficiently? Yeah, I mean there's multiple ways that people want to use Bloodhound but they just might not have the expertise or the time, no matter how easy I try to make that on the product. Right.

A (11:13)

So I guess that's the. If you're in the position where your identity platforms or whatever you call them and the interactions are a bit of a mystery to you and you're trying to follow best practice, but you're not so deep in the weeds that you can go, okay, yes, I feel confident pruning this path or whatever. That's the kind of service where you would. Is it hand holding or just reassurance or having the expertise, I guess to know that that would be okay.

B (11:41)

Yeah, exactly. So it's everything from. There can be many issues that you might want to fix. Right. And there's maybe a critical path. Like first of all, that's the choke point that will isolate for you automatically by Bloodhound Enterprise. But then there's like, well, which ones are easy to do, which ones are low risk? Which ones can we log for and determine that there actually isn't going to be an impact if you remove it? Because you're talking about sometime removing privilege. And a lot of people want to say like, well, I don't want to take my application offline because you removed something. That's kind of a terrifying scenario. So our expertise can walk you through all of that and make sure you can take action. And a lot of people say quite simply, just don't have the time. This is a real problem. But I just need somebody to make it happen. Right.

A (12:29)

And so that'll be a service that you'll offer.

B (12:31)

Yes, I'd say the final thing that I wanted to hit on is for years and I told my CEO flat out that we would never do it, but now we are. So we have been SaaS since we've come out. It did a lot for us. It also does a lot for our customers. It's just we take on the management of the SaaS backend. But we realize that customers in highly regulated environments, or especially like defense organizations, cannot use a cloud backend no matter who it is or where it's hosted. Right. It doesn't matter that we have instances in Australia or Germany or whatever. It doesn't matter.

A (13:07)

Yep.

B (13:08)

So now we, we can support on prem deployments of Bloodhound, which is. Is really nice. I mean, there's a lot of people that we've wanted to support for some time. A lot of us over here are like veterans. So it's kind of cool that we can like meet our defense counterparts again and say, hey, we can support you. Or just, you know, highly regulated financial institutions are another like big, big user of those. So.

A (13:29)

Yeah, that sounds like. Well, I don't know why you ever said no, because it, to me it totally makes sense that something would.

B (13:37)

I think early on it was it. It's a. Early on. It's a lot easier with a smaller team to, you know, we have one version of the application and we just maintain that one version of the application and updates go out to all of them. Similarly, on the customer side, it's a lot easier because you're not having to break network rules internally to get things connected. So it was more of a we can do this faster, but now we're at the point where we can support both.

A (14:05)

Justin Kohler I always find it very interesting to talk to you and learn about these things because it sort of seems like a microcosm of the real world. Things are really complex and it's hard to know what to do. So thanks very much.

B (14:17)

Yes, pleasure to be here. Thank you.