Risky Business - Snake Oilers: Authentik, Dropzone and SlashID

Episode Date: September 6, 2024

In this edition of Snake Oilers Patrick Gray gets pitches from three cybersecurity companies: Authentik, an open source identity provider that a lot of large organisations are deploying on prem as an alternative to cloud-based IDPs Dropzone AI, an LLM-based agent that can do the work of a Tier 1 SOC analyst SlashID, an identity security company that can crunch your logs to find attackers You can watch this edition of Snake Oilers on YouTube here. Show notes Welcome | authentik Dropzone AI: Reinforce your SOC with AI Analysts The identity stack to protect users and non-human identities | SlashID

Hey everyone and welcome to another edition of the Risky Business Snake Oilers podcast series. I'm Patrick Gray. Snake Oilers is the cheekily named podcast we do here at Risky Biz HQ where we sit down with three vendors and they tell us what it is they actually do. They of course paid to be here so all these interviews are sponsored and in addition I'm also doing advisory work with Authentic and Dropzone, two of the sponsors you'll be hearing from today. So today we're hearing from Authentic and Dropzone as I mentioned and also SlashID. The first one we're going to go with is Authentic, an open source identity provider that is gaining a heap of traction. Large organizations are all over the idea of being able to manage their own IDP, which sounds kind of crazy. But once you've heard or seen this interview,

you'll absolutely understand why it's a trend. Our second vendor today is going to be DropZone AI. And DropZone makes an AI SOC agent, basically an LLM-based tier one SOC analyst. And I've seen this thing in action. and it's really good at taking over some of the repetitive work that tier ones normally have to do. You can give it all of the crap work basically, like chasing down those alerts that seldom amount to anything,

but need to be investigated anyway. Some of you watching and listening to this might think AI based tech like this is bonkers, but it is the future and we all have to get on board eventually. And our third and final snake oiler this week is SlashID, an identity threat detection and response company. They ingest logs from all of your IDPs, cloud providers, and your major SaaS apps. They put all of those logs into a cauldron, stir them up, run some detection logic over them and presto, they detect identities doing funny stuff.

Slash ID is popular with large enterprises where they've tried to instrument this sort of logging themselves and just discovered it's too much work. So they've wound up with Slash ID. But let's start off by talking with Fletcher Heisler, the CEO of Authentic, that's Authentic with a K. And here he is explaining why large organizations

are choosing to roll their own IDP using Authentic, either self-hosting or running it on-prem. So why are people doing this? Here's Fletcher. Well, I think what we've seen is at scale, something like Authentic is actually easier for teams to run. They're often left with running a whole team, duct taping together integrations and solutions for legacy SaaS providers.

Whereas IAM as a service was supposed to be cost effective, flexible, secure. You're getting the opposite of that over time. You're getting changes, unreliability, hitting rate limits, and it's not really customized to your use case and your needs. It's also in many ways much easier to secure and lock down your own self-hosted identity provider when you have the right tools for the job, because you're not sharing that infrastructure and you're not sharing that attack surface with every other customer of a cloud-based identity provider. So is there a consistent theme of the sort of customers

that are choosing to do this? I mean, I'm guessing they're less likely to be ma and pa sort of operations, more likely to be large enterprise. I'd say that, you know, obviously SaaS isn't entirely going away, but the tail ends are getting thicker. And we're serving both of those where either a company at scale with many 1000s or more of employees is already running its own private cloud, they're used to running things in Kubernetes. That's where the rest of their infrastructure already is. So it's easier to run another pod to, you know, whatever that infrastructure looks like, run Terraform and automate everything and own it and understand how things will auto scale and be provisioned versus throw things off to a SaaS provider and hope that it works. tail end, I think it's a lot of specialized use cases. We can go into very challenging environments where you might even need to be air gapped. You might need a lot of resiliency. We're working with, for instance, one of our early customers is the 911 center for a state. And so

they have four different internet providers, but they can't rely on there being internet when they need identity for their center. And so with these very challenging environments having everything set up just the way you need it in in very uh resilient ways is also you know a big differentiator this is one of these businesses yours where and we've seen a few of these right like sublime security is the other one that comes to mind where they're trying to take the whole, you know, product around email security and turn it into something that's more sort of programmable, something that's more inspectable,

something that's less of a black box. I'm guessing that's one of the key advantages, right? For the customers with Authentic is, you know, if there's something they don't like about the product, they can actually get in there and change it. They can commit code to it. They can just, you know, I'm guessing it's more configurable as well. So I guess that's the idea here is that there seems to be a bit of a movement towards taking some of these black box SaaS things and making them, yeah, just much more configurable.

Absolutely. And what I mentioned, saving the time and money of now you have to duct tape other solutions from scratch to talk to your legacy services. Instead, everything is built in Django on the back end of Authentic. And so you can write your own Python snippets to reach out to somewhere. Everything you can do in our UI is also available as an API. And so there's nothing closed off to you. You set whatever rate limits you'd like. Similarly, you can use Terraform and automate everything. So infrastructure is code. Everything is replicatable. It's as customizable as you'd like. Similar to Django, we kind of do

the batteries included. And so you don't have to program a bunch of stuff in order to start using it. There are sensible defaults, but you can go as deep as you like to fully customize Authentic to your needs. Now, the guts of Authentic are open source, right? So it's like what you describe as open core, but you do have some commercial offerings around this. I'm guessing that is, well, I know that that's at this stage, mostly around things like, you know, compliance and logging modules and things like that. Is that about right?

Yeah, you can think of really anything that an enterprise at scale would need out of its IDP. We have additional logging. We have some additional integrations that are more likely for someone at an enterprise to use where, for instance, if you have multiple IDPs in different scenarios, you could reach out to Okta or Ping or Entra or your own active directory as part of a flow in Authentic in order to dynamically migrate something over, or maybe you just have a service you can't touch, but you still need to interact with. Those sorts of things are features of the enterprise plan, along with support from us, obviously, that you get the experts on call to help you out. That's the classic open source model, right? That's the old school open source model.

Yeah. And we try to, actually, a lot of our enterprise calls start with, oh, well, we use you in our home labs. And so we're already very familiar with Authentic. Then it's just about scaling it up and figuring out the needs at the size of a company. We have, I think, nearly 300,000 installations across the community. So it's fun to have some experts come in already rather than having to sort of educate folks about what we do and then take it to the enterprise. Now, one thing I find really interesting

about where you are at the moment is I know that you were planning on building out sort of managed hosted, right, for customers and probably eventually some sort of cloud-based, SaaS-based thing, right? But, you know, more observable, more configurable, more programmable, whatever, right? So, cool. That's the direction. That's the obvious direction for a company like yours. But at the moment, you are so busy servicing the demand for self-hosted that that's just what you're focused on right now,

right? So, I mean, I got to admit, I'm surprised there's such a big market for self-hosted IDP. I mean, was that also surprising to you? Because I'm guessing, I mean, it's just, it is a bit counterintuitive that there are this many people that want to pull a function like this in-house. It's been surprising to me, the variety of folks who've come to us and said, we've had enough of IAM as a service, we're ready to stand this up. I think the difference is, from thinking about it 10, even five years ago, it's much easier with the right tools to stand that up on your own relative to where we're seeing SaaS headed. It's also a matter of cost. That's, you know, it actually becomes much more predictable to stand that up on your own in terms of the cost measures relative to what SaaS might

do to you down the line. Obviously we will, we do want to get into hosted managed offerings and so forth, but we've just seen a lot of inbound interest from folks who are ready to take this in-house, also not have to send their PII out to a SaaS provider. So we've seen a lot of interest from folks in Europe who were maybe not as eager to send all their employee records over to a US SaaS solution. So we plan very much to, regardless of whatever else, continue to focus on the self-hosted side and drive people there wherever it makes sense for them to be able to stand that up. Now, you've mentioned cost a couple of times. And one area where I know that

you are just like where the savings are outrageous is not so much on the authenticating internal users. I mean, there is a cost advantage there as well. But when it comes to authenticating external users, a la sort of like Auth0 style authentication. Of course, Auth0 was bought by Okta and is now a part of Okta. And for a substantial user base, that starts getting pretty pricey pretty quickly. Is that one of the things that's driving adoption here is more on the external user side? Because I'd imagine, I mean, I know people who after some price changes there, they were just scrambling for solutions, right? Because it just became kind of untenable. Yeah. Yeah. We're seeing both. We've built in what we call sort of internal and external users, similar to your employees or customers of your customers, Auth0 side.

From the very beginning, I think maybe Okta is having some challenges with two very different companies and code bases and so forth. But companies want a single place to manage this kind of solution. The really nice part about self-hosting is you know a bit more about your demand, your user spikes and so forth, and you're really paying for what you use there rather than the SaaS-based model of we have all of these pass-through costs at scale and shared across customers that we would then have to pass to our users. So absolutely, it can be a much more effective and cost-effective solution for an off-zero replacement or something like that.

So there's something a little bit ironic that I just realized too which is you were saying that for some european customers they might want to you know go with something like this self-hosted due to concerns over things like you know 702 collection by the us intelligence community or whatever you know obviously when there was the big snowden lake 11 years ago um you know this was a this was a big concern in europe which is oh my god the americans are you know sp this was a big concern in Europe, which is, oh my God, the Americans are, you know, spying on everything. The reason I'm saying there's a bit of irony here is I imagine another area where this is going to be a popular product is actually in the intelligence community, right? Because you can do, you can run an IDP in an air gap network. Yeah. There are a lot of big zero trust initiatives on the agency sides of things.

Obviously, can't get into too many details, but there's been a lot of interest in being able to run flexible identity provider for even an air-gapped or very challenging environment where you still need that kind of flexibility. You see why I say there's some irony at play here, though, right? For sure. I think, fortunately fortunately we're also in a business where I think everybody deserves to have a good identity provider and be able to own that and secure that well. And so we can,

I think in very good conscious serve all sides of all parties involved with a quality product. All right. Well, Fletcher Heisler, thank you so much for joining me to walk through Authentic, what it's all about, who's using it, kind of where it's going. Fascinating stuff. We're going to be doing some stuff with you next year as well. So welcome aboard. And yeah, we'll talk to you again soon.

Looking forward to it. Thanks for having me. That was Fletcher Heisler there from Authentic, and you can find them at goauthentic.io. It's time for our second snake oiler today, and we're going to hear from Edward Wu from Dropzone. Edward used to work at ExtraHop Networks and did a lot of the work there on the machine learning side of things.

But these days he's running his own startup, Dropzone. Dropzone is a large language model-based tier one SOC analyst. And the idea is you can plug this AI agent into your environment and it'll do work that is normally performed by a junior SOC analyst. And let's face it, tier one analysts do miss a lot of stuff,

partly because the staff tend to be junior and partly because the work is just often mind-numbing and repetitive. And that's where AI agents really shine. You can get this thing to handle a whole bunch of alert types that you do need to investigate but turn out to be nothing most of the time like log4j is a great example of that and Dropzone isn't promising to be some sort of incredible all-seeing AI system. It aims to be just more thorough than a human doing that tier one work. It's also cheaper

and can free up your people to do higher value work. So here's Edward Wu explaining what DropZone actually does. We have built a software system that ingests security alerts as input, autonomously perform investigations and generate decision ready reports as output. And the idea is to, with our technology, to offload tier one alert investigations from your security teams so the human defenders can focus only on the real threats as well as tier two, tier three, and other proactive projects.

So it's a way to use LLMs to take away some of the tedium of sock work some of the stuff that might be low priority but still has to be done and isn't that complicated i mean that's essentially the pitch here right yeah exactly and we're seeing you know with large language models um different people are building like these kind of ai assistants ai AI agents, right, to offload, you know, the boring, mundane, repetitive tasks within every single white-collar industry. And we're kind of looking at SOC specifically. And because, to be frank, nobody grew up, you know,

aspiring to be a tier one security analyst. I think everybody wants to be a tier two, tier three, a red teamer, a pen tester, right, a security architect. But unfortunately, right now, the world needs a lot of tier one analysts for necessity. And we saw an opportunity to leverage the latest technology to further automate those. So, I mean, you know, when we think about SIEM projects and SIEM teams and SOCs, you know, such a big part of having a successful SIEM and SOC program is, you know, what we call the alert tuning, right? So it almost feels like this is just the next phase of what that alert tuning looks like, which is there are some that you really would be nice to keep, but that otherwise just due to

resource constraints, people might tune out or whatever. So, I mean, that sort of seems like the thinking here. Is that about right? Yeah. From what we have seen, like alert tuning obviously has been one of the key tools that security teams have utilized to make the alerts manageable. But I would say, but if you look at alert tuning specifically, technically, it is actually not a great solution because every time you tune out alerts, you're also tuning out signals. So it's very easy to end up at a place where you tune out so many alerts that your, you know, detection fabric is full of gigantic holes and you're not even really realizing that. So for us, our approach and solution

to the alert overload and fatigue problem is not to really tune out alerts, but to simply leverage AI and software to 10x the analytical alert investigation capacity of the security team. Yeah, now it was some months ago you actually gave me a one-on-one demo. This was way back. God, when was that?

Like May, April, something like that. Yeah, around the RSA. And you showed me how that thing worked. And what I found really interesting about it is the example that you chose to demo to me was log4j, right? And people are getting so many log4j alerts and chasing every one of them down is just, you know, it's a pain. So the demo that you showed me was your agent seeing a log4j alert and then going and collecting various other bits of telemetry to figure out whether it was real or not. And I think the one case, one of the cases you showed me is

where it found, you know, a log4j alert and then a new jar file spun up and was running. And it's like, okay, well, that's something. And, you know, at every step of the way, what the agent had done was very, very, excuse me, it was was very very simple um but also at the same time like kind of work that needed to be done that you can't just tune out i think what i like about what you've built here is that you're not claiming that this is some super ai cyber you know genius or whatever that can that can solve all of your problems it really is just about handling that grunt work, right? Yeah, exactly. We have built our system in a way that is really replicating what a typical human analyst will have done. Compared to a lot of other data science or AI ML-based solutions, where they are making statistical guesses or educated guesses on what an alert actually is, our system does

not really make any guess. Because what we found is the best way to triage and prioritize and get to the nosy alert itself is by actually investigating it. So we have trained our system to replicate the investigative process and the mindset that a typical human analyst looking to as a result of that for every investigation performed by our system you know the steps of enrichment the additional data sources we pulled in should not be a surprise for anybody who worked worked at the stock so why don't we talk a moment about what the sort of technology stack you can support is right because at the moment we're about this, it's a bit of an abstract concept. Like, you know, do you plug into Splunk? Do you plug into EDR platforms? Like, you know, tell us how all that works.

Yeah, so so far, we have built around 50 built-in integrations with a variety of different security products. And we have pre-trained our AI security analyst on six categories of security alerts. So those are phishing emails, malware endpoint, network exploitation, cloud workload alerts like AWS GCP, as well as identity. So that's Okta, Entry ID, and Google Workspace. And then finally, insider threat alerts. And those alerts are mostly like SaaS alerts, like Office 365. So where are people seeing the most value out of this, right?

Like what are the types of alerts where people like universally, when they deploy this thing, they just feed it this particular task to do? You know, is there anything, are there any sort of clear winning clearly winner use cases here yeah i would say what we have definitely seen a lot of traction and a lot of good i would say feedback and excitement around like cloud alerts

endpoint alerts and identity identity alerts and this is where partially because our technology is a SaaS, it deploys by making API integrations. It's much easier to integrate with cloud alerts or cloud security products and endpoint security products nowadays. So essentially, the customers can configure us and deploy us and set the hosting up within 15 minutes. And then after that, they are able to immediately see our AI analysts investigating different alerts coming to their environment. So why don't you walk us through, if you're the SOC analyst, right?

Like at a tier two or above, right? Like how are you actually day-to-day actually using this, right? Because I've seen it in action and really it will just take an alert that otherwise would have flown by in some console somewhere, turns it into a more detailed report.

But walk us through that process. Like what's the workflow like for someone actually working at a SOC who's hands-on with Drop Zone? Yeah, so there are a couple of ways we have seen in terms of actual deployment, but the most common way is essentially the alerts will, they connect DropZone with a variety of their security system where we pull in alerts and then perform investigations. After the investigation is completed, Drop Zone will post its analytical findings to the existing case management system

or sometimes even a Slack channel where the human analyst can consume the output of our analysis. So a lot of times what it feels like as a tier two or even a tier one, right? You kind of log into your case management system, you see a new alert, and you open up the alert. Now, instead of spending 30 minutes or an hour looking to the alert, there is essentially an additional analysis in the comment below that has all the relevant metadata and contacts put together on a silver platter. So now it's also written in plain English, right? Which is, I investigated this

alert and I found this and then I looked at this and I found this and this means that XYZ. So you do get that plain English stuff. And I guessing if it uh if an alert goes nowhere that's just never surfaced to the analyst right yeah so if an alert goes nowhere obviously we have the detailed analysis but at the same time we will also when we have the case management system we will also adjust the priority of the alert um so this is where as like obviously when a new customer first start to use drop zone, similar to, you know, when somebody hires a net new tier one security analyst, there will be more oversight. Right. What that means is like even if Drop Zone says an alert is a false positive or benign, see tier two and tier three might still want to take a quick look just to, you know, double check and make sure. But as time goes on, the amount of oversight, you know, will start to reduce. And this is where we have seen a couple customers and early adopters of us actually do not investigate and manually review any alerts that has been analyzed by DropZone and concluded to be a false positive.

Now, we should point out too that, and again, this is one thing I really appreciate about the way that you present your technology, is you're not claiming that it'll never make a mistake, but you are claiming that it will, on the balance of probabilities, make fewer mistakes than a human tier one analyst who are not known for being, you know, you don't put the best trained people in that tier one seat, right? So what you're saying is that it will still give you an increase in accuracy, even if it's not perfect. Like, you know, don't let perfect be the enemy of better, I think is the approach here, right?

Yeah, yeah, absolutely. Like we have been, you know, obviously developing our system and measuring it in a number of different production environments with our early adopters and customers. And yeah, I would say for us, like from our perspective, our goal is to make sure our AI tier one security analyst is as good, if not better than an average human tier one security analyst. Because in addition to accuracy, the cost of having an AI security analyst and the latency or the investigation velocity of an AI security analyst is far superior than an average tier one human analyst. So this is where our technology has been proven

to offer a lot of value, even though it's not 100% perfect. Edward Wu from Dropzone.ai, thank you so much for joining us on Risky Business to pitch your stuff. Really appreciate it. Thank you. That was Edward Wu from Dropzone there, and you can head over to Dropzone.ai to request a demo. Go check it out and tell me what you think. I'm Risbusiness at infosec.exchange on Mastodon. It's time for our third and final snake oiler today, SlashID. SlashID is an identity threat detection and response company founded by our next guest, Vincenzo Iozzo. And as you'll hear, the basic idea is they ingest logs from your IDPs, your cloud services and your SaaS providers, and then run detections on that data. This is particularly useful to large companies running

multi-cloud environments. And Vincenzo says most of his customers are currently large orgs that have tried to pull together these types of detections themselves and have just realized it's so much work that it doesn't make sense to do it in-house. So here is Vincenzo explaining exactly what Slash ID actually is. So Slash ID is a platform to stop identity-based attacks, primarily in cloud environments, although we're adding support for Active Directory as well. And we do that by ingesting identity data and log data from cloud environments, selected SaaS apps, and your IDPs. We do that by ingesting identity data and log data

from cloud environments, selected SaaS apps, and your IDPs. We run a set of detections on those identities, and these identities can be non-human identities, so like service accounts, they could be human identities. We don't discriminate between the two because ultimately we're trying to stop an attacker from breaking in. We run the detection pipeline and then depending if any of the detections trigger on your identities, you can either have

manual remediation actions, which could be something like suspend a user, block a user, rotate a credential, revoke a session, or have automated workflows that automatically perform these actions on your behalf when the detection triggers. So that's at a high level what we do. Okay, so what sort of users is this keeping an eye on? Because you're mentioning stuff where there's a lot of sort of highly privileged like admin accounts, right?

In cloud environments and whatnot and selected apps. I know one of the ones that you support is like you know snowflake which okay it's sass but it's also kind of something that admins and dbas and whatever touch right so you know is this for every day like sally in accounts or is this for admin users or is it just for everything so i mean because we keep track of all of the identities you have in your IDP and in your cloud provider, in principle, we run detections on all your identities. In practice, though, most of the attacks we catch tend to be for either higher privileged identities or service accounts. Yeah, that makes sense. So you mentioned you've got your detection pipeline and then you've got your automated actions. Let's start with the detection stuff first. Like what are you actually detecting on? What sorts of things is your product actually

set up to see, right? So you're pulling down these logs, you know, you've got your Snowflake logs, your AWS logs, your Octa logs, your Entra logs, you know, you put them all in a vat, stir them around, you know, say the incantation. And what sort of detections are you actually running there? Yeah, so we try to focus on two parts of a traditional attack chain. So we try to focus on the discovery part and the privilege escalation part. So on discovery, we monitor for things like credential staffing attempts. We monitor for things like actions that would indicate that somebody is trying to enumerate identities

over entities in a cloud environment. And then on the privilege escalation front, we try to monitor for actions that indicate either some attempt for an identity to create another identity to obtain persistence, or to go from a lower privileged identity to a higher privileged identity. Often we see that identities are overprivileged

because, as you know, it's super complicated to create least privileged policies in some of these cloud environments. And so what can happen is you go from a legitimate identity with overpriv over privileges to the creation of a separate identity or role that has admin privileges that then gets used by the attacker to maintain persistence and do like crypto mining or whatever is their goal. And so we try to focus on those two types of detections. Rightio. Okay, so it's funny, right? Because you mentioned crypto mining

and I'm thinking it's crypto mining if you're lucky, right? That's basically the attack that you actually want. So, I mean, how clear are those sort of detections though, right? So, I mean, you are talking about like, yeah, like that's a pretty typical sort of privilege escalation using a privilege user to create some other user that no one's going to notice you're using, right? That's the attacker's thinking.

But I mean, are you going to flag some false positives doing those sort of detections? Or are there just some very, very clear signs when something's happening that shouldn't be, that you can alert on? We try to keep those to a minimum. And as a customer, you can configure the severity of each detection that triggers but also we we try to have chain of events so that the likelihood the likelihood of each individual event might be sort of like might be higher for like a benign use case but the chain of events tends to be anomalous. So going back to the example of a overprivileged identity creating a

separate identity that then gets used by the attacker, if you start seeing that identity being used from an anomalous IP address at anomalous time of the day performing a series of actions that are not common for that identity. That's generally pretty high signal. Obviously not in all cases, but it's... Look, once you've triggered off like those red flags, like even if it's false positive, you would be mad at a solution like this for throwing you an alert, right? Yeah, so I 100% get where you're coming from.

So, you know, you did mention the SaaS stuff. So you've got, I mean, Snowflake is one. What are some of the other SaaS solutions that you're supporting there? Yeah, so we also support Databricks. Basically, our rationale is we look at what threat actors have done in the past in terms of like where they've breached customers, and we prioritize those. So right now, we support Databricks, Snowflake, Slack, and on kind of like the cloud provider front, we support GCP, Azure, and AWS. And then in terms of IDP, we support Entra, Okta, and Google.

And we are constantly adding sort of like new data sources. But because we are a startup, we try to take a principle approach where we look at past campaigns, see what they've compromised, and then go after those tools first. Yeah, you put the rocks in the jar before you fill it with sand, right?

Like that old thing. It's interesting too, what you said about alerting on like an IP that's weird, right? Because I think some people misunderstand that, okay, you know, you might be able to instrument that through your IDP, but that's only going to show you people coming in through the IDP. So for like admin sessions in Okta now, I think you can pin it either to an ASN or to an IP, which is great unless someone's stolen that admin's session token into another app, and then off they go and the IDP doesn't know anything about it, right?

So I guess that's one thing that you're able to do here is to get that weird sort of, you know, the funny IP signal and actually apply that to SaaS apps. And then from there, I'm guessing you can either alert or you can trigger an action like de-auth the user or step up auth them or things like that. I'm guessing though that that's a little bit, that needs to be implemented sort of case by case, depending on the SaaS app. Yeah. So, I mean, two things here, right? So one is when you look at past breaches, you see three high level trends. One is unfederated apps where people run credential stuffing attacks.

The second one is some form of phishing. And the third one is effectively lost or stolen API keys and NHI credentials that then get used in the target environment. When you think about what an IDP can do, they can help with the second bucket, but they can't really help with the first or the third. And we actually have coverage across definitely the second and the third, and sometimes the first as well, depending on how we're deployed.

And then to your point, one of the complexities, especially when it comes to the actions, is the underlying applications have very different behaviors and very different implementation of their auth stack and authorization stack. The type of actions you can perform depend on the provider. In some cases, you can, for instance, re-book a session and log out the user or rotate the access key, but that's not a given in all cases. So a lot of the work we put into the product is how do we standardize these actions across all providers so that the end customer has a simple API and we take care of

the details underneath. Now, I'm guessing your typical customer is multi-cloud or is using a lot of these sort of SaaS apps, as well as, yeah, probably multi-cloud as well. Do they tend to be on the bigger side with security teams or smaller side? I'm guessing bigger side with people with detection teams who've tried to instrument this themselves and have wound up banging their heads into walls, right?

Yes. I mean, we find that the smaller teams don't yet feel this as a pain point. It ends up being more of a large company kind of issue. And for large companies, what we see often is they might have detection teams and they are very good detection teams, but they can't respond quickly enough.

And then two, they can have detections for their CSP, but they don't have detections for their CSP, but they don't have detections across the whole spectrum of other applications. And so that's where the value proposition really shines, I think. I should mention too, because we spoke about this another time, but one of the ways that you help

with the unfederated apps is you've got essentially like an ID aware proxy that can sit in front of that, but you also have an SDK that allows you to actually get those things under the umbrella of your IDP as well. So that's something where you're sort of, I'm guessing, working a little bit more closely with the customers to get them set up there.

Yeah, that's right. So like the initial setup is very simple. This is the same way you would set up like a Synapse tool. So you just give us credentials and we can collect data and logs. But if you have unfederated apps and that's one of your core concerns, then we work with your team to either deploy our identity, our proxy, in cases where you can modify the app, or we can deploy our SDK in case where you do have access to the code,

to the source code, and you can add support for authentication. And then both the proxy and the SDK allow you to enforce MFA, conditional access policies, and so on. Excellent. Alrighty. Well, I think that's about going to do it. Vincenzo Iozzo, thank you so much for joining me to talk all about that. Slash ID, great stuff. Very interesting. And I wish you all the best do it. Vincenzo Iozzo, thank you so much for joining me to talk all about that. Slash ID, great stuff. Very interesting. And I wish you all the best with it. Thank you. Thank you so much. That was Vincenzo Iozzo from Slash ID there. And you can find them at SlashID.dev. And that is it for this edition of Snake Oilers. As usual, you can send me some feedback via Mastodon. I'm just riskybusiness at infosec.exchange. But yeah, that's it for today's edition of Snake Oilers. I'll be back with more security news and analysis soon. But until then, thanks for listening and

watching. Thank you.