EP182 ITDR: The Missing Piece in Your Security Puzzle or Yet Another Tool to Buy?

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Timothy Peacock, the PM for Risk Analytics and Cloud Threat in Google SecOps, and Anton Chuvakin, a reformed analyst and senior staff in Google Cloud's Office of the CISO. You can find, subscribe to this podcast wherever you get your podcasts, as well as at our website. cloud.google.com/podcasts. If you enjoy our content and want it delivered to you piping hot every Monday, please do hit that subscribe button. You can follow the show, argue with us and the rest of our Cloud Security Podcast listeners all on our community page. Today, super fun episode, Anton. You and I both showed up like ready to rumble, and then we met the most wonderful, structured, thoughtful guest who wasn't having any of our nonsense and had these fascinating answers about why we were both wrong.

It was a little less extreme in terms of like we were probably more skeptical.

No, it was an all-out brawl, a slugfest, bullets were flying.

We were not like quantum, like remember the quantum episode where we were like—

That's true.

What the hell is this stuff? Take it back, take it to your time machine to 2040. Don't bother us for another 20 years. And then she basically convinced us that, yeah, sorry guys, you have to worry about this now. I think here we were more skeptical, but ultimately I guess delivered on the insight. At least that's my impression.

Yes. And this has been a topic internal at Google. This has been a topic external at Google. So I think it's timely, it's interesting, and very cloud. So maybe without any further ado, let's turn things over to today's guest. Today we are joined by Adam Bateman, co-founder and CEO of Push Security. Adam, we've got a fun topic today, which is ITDR. And while I could spend my time reading yet another Gartner paper that no doubt will define the term, could you tell us how you think about ITDR and maybe start with what it stands for?

Yeah, absolutely. So it stands for Identity Threat Detection and Response. So, of course, some parallels to identity, but I just think of it as detecting, responding to identity attacks in the same ways that EDR is kind of detecting, responding to endpoint attacks. That's why I see it as a parallel.

Okay. And did we have something before this? We had AV before EDR. So do we have a predecessor we can look at for ITDR?

I don't think that's comparable, though I do think that ITDR is evolving slightly. So if you look at the official definition for ITDR, it's actually about protecting identity systems. And I think that's centered around when Active Directory was the focus, particularly on-premises attacks directly against the directory itself. The reason I think it's evolving, and it definitely should evolve, is because if you think about it, the attacks against the identity systems is kind of important, but it's not just that. Like, phishing attack, for example, that happens technically inside the browser. And if that happens at the browser, it's sort of on the other end of the identity system. And so that should be included as well. So, I mean, certainly the thing I've been advocating is Pulling more, I mean, certainly ITDR being much more of a focus on cloud identities at minimum, right? Because that's where the big attack surface is. Identities are being spread out across the cloud as everyone's migrating that way. And so it should at least be not just on-prem, and it should be very much that kind of cloud focus.

But also, I think rather than just pulling logs from those cloud systems, actually pulling telemetry directly from browsers, which is the other end of the attack surface, So when we used to think about like EDR versus network defense versus email security or mobile security, the security was kind of centered conceptually on where you deployed your sensor. Identity, by contrast, feels like you're going to need sensors all over the place and to integrate that. Does that mean this isn't a thing the way that other kinds of things were things? That just occurred to me, listeners. That's not in the question, so don't feel bad if Adam thinks I'm a jerk.

Yeah, no, that's actually a really good question. I was about to offer some kind of copious praise to Tim's insightfulness because I was just thinking that E and N and even C are domains, but IT is not. Well, IT is not.

But identity doesn't have a home. It spans everything. So, how do we do ITDR?

Yeah, but that's why I think it's a sort of paradigm shift, right? Because it's funny, I think about categories. They're my bugbear, which I know there are a lot of people as well, but I think of them a little bit like a bit like job titles, right? Everyone knows that they're silly. We all wish we didn't have them. What matters is the job you do and the kind of mission inside the company, but they're necessary because they kind of set expectation very, very quickly about what you do.

Yeah.

And I think that's the thing. So the reason that I think ITDR is good is because identity is a big deal now. Like, in particular, as the attack surface has just all shifted online, it's become really big. Like, you look at any of the big vendors and they're all talking about I know 74% and 80% of attacks are happening there. So I think the fact that it's being named a thing, that's the positive side of it, is it's saying to everyone, look, we need to focus on this and think about it. But yeah, absolutely, you can draw parallels. If you put an EDR agent on a domain controller, is that identity or is it still endpoint? It's not an endpoint, it all blurs together. So I think about it as the attacks are now happening with identity, They're moving off of the endpoint in the network. You can now compromise an entire company without touching the endpoint network at all. And this is something we should focus on. And therefore, let's think about the identity aspect. And then very much, if you take a parallel to traditional detection response, then you would use network and you would use logs and you would use EDR. And I think the same thing's true for identity now. You should absolutely pull logs from an identity provider. But if you did that just on its own, that would be like just doing log monitoring in the traditional network world. And that's why I think that pulling telemetry directly from browsers as well, like a kind of EDR equivalent, is really important as well to give you the full picture. So yeah, it's kind of indirect answer to your question, but—

No, I think it's a great answer to the question, and I'm sorry to surprise you with a question at 9:00 AM, at least in our time zone.

Yeah.

Actually, it's worse than that though, Tim.

Oh, no.

I have to uncloset myself as a closet ITDR hater who thought initially then the analyst who created this just made a mistake. It should not exist. And then later on, I argued with him and with a few others about like this space shouldn't exist. And of course, their counterpoint was, ah, no, no, no, Anton, don't freak out. It's not a space; it's a technology domain. We don't mean it as a market space. We can achieve it with other technologies like Sim and Uber. And then I said, but dude, you weren't born yesterday. You know that when you describe a technology domain, all the vendors immediately say it's a market space. And you poor analysts say, no, no, no, it's not a market space. And they all say. Yes, it is. And then you lose. But with this short rant about why I didn't like ITDR, Adam's line actually almost convinced me that ITDR should exist. And that was really subtle and maybe not profound. I wouldn't quite push it to profound. But the point is that it has reasons for existence, which are robust enough rather than rename a couple of UBA modules as ITDR or What do we call them? IGA, Identity Governance Analytics, the previous iteration of something similar. I think ITDR as a way to detect and respond in the new domain of identity as an overall system is—

Credible?

Okay. Credible.

Yeah. Adam, welcome to the show. You've got 2 guys who think your company shouldn't exist. Good luck. Thanks for joining us.

No, but I mean, honestly though, it's funny. We literally just published an article ourselves on the fact that we were skeptical about ITDR, right? And I think that—

Really?

Yeah, yeah. And the blog post, you can look at it, it sort of says that we've been trying to, because we don't, I mean, we didn't care about categories. We're like, we've been practitioners our whole lives. We're here to solve a problem. And then it's like, as I said, for us, a category is like a job title. It's like, if you want to quickly say to someone, what do you do? Where are you going to live? And you sort of pick that. So anyway, ITDR, the reason we were skeptical about it is because we sort of felt a little bit like UEBA, right? It was kind of, it existed and it came out of CIM, but should it have done? It was kind of like CIM fell asleep at the wheel and like it was needed because it was internal and everything.

Yeah.

And then lo and behold, all these companies got bought up for relatively small amounts of money and brought back into that. And it was kind of, was it a feature of SIEM? And I think the original ITDR, A, it was centered around identity. And then as you were saying previously, identity has always existed. Should that have happened? But the second big thing I think is even if you shift ITDR to the cloud and you just draw logs from identities, then there's a parallel to UBA there. It's like, should ITDR actually exist outside of the IDPs in the first place? Right. If you are dependent on IDP logs, and you're doing detections on those, sure, it's focused detection around identity attacks like impossible travel, like MFA fatigue, but could you do that in your SIEM? Should it really exist? And so I think the reason my argument for why RTTR should exist is because what we're now seeing is generating or having browser plugins inside the browser, and that generates a net new telemetry, something different. So actually detecting phishing attacks inside the browser, like pulling telemetry from the browser and it adds something new to the picture. And that's where I start to feel like it does justify having something different. I can give you some examples of what that telemetry is, but that adding something new that you could put into your sim is where I think that actually has got some potential.

I like that. I think that SimYuba analogy— I don't want to say that it's immediately something that I've said in the past, but I think the sleep at the wheel argument is there. And But I want to switch it to a bit more of practical matters. And I think Tim had a very useful frame for a question, which I'm going to kind of borrow in this case. So imagine that you do have ITDR tech. So what gets better once it's deployed? So once you— if you buy the ITDR in a box and you plop it in your environment and turn it on, what gets better?

I think because of the fact that ITDR category is a little fuzzy, it depends what you deploy. It'd be a bit like saying, if you deploy log monitoring versus you deploying EDR, what would get better? I think if you deployed like the classic ITDR and you don't ingest your logs in, what you get is effectively out-of-the-box rules. So visibility into different identity-based attacks. And like I said before, possible travel, MFA fatigue, you know, some action occurred that shouldn't have done, multiple sessions exist and that kind of thing. But generally it's visibility into identity-based attacks straight out of the box where you don't have to go and write the rules into the SIEM. That's what I would say. If you are thinking more browser-based telemetry, then you're starting to see stuff that, like, for example, unmanaged identities can be picked up by the browser, right? You don't— the logs you would pull from your IDP that you know about, but what about all the hundreds of applications that people are signing up to, shadow AWS workloads you didn't know existed?

Well, now you sound like a CASB.

You sound a little bit like a CASB. That's a very astute observation, I think.

Yeah, I think the thing with the CASB is that, I mean, that again comes from the perimeter where it's network orientated and you are sort of tunneling everyone out through a proxy and you're pulling information up from there.

No, no, no. That's CASB 2004. That's 2000. Oh, no, no, no. Didn't exist. No, that didn't exist. 2012. No, sorry. The 4 is me being too enthusiastic. No, 2014 maybe when it was proxy-based.

But I buy this about browser telemetry being valuable. That I believe.

Yes. But CASB's job is to capture the access to SaaS and other stuff that isn't—

Let me ask you a different question. Let me, let me, let me poke at something else here, which is not just— it sounded like CASB. It also sounded a bit like identity security posture management.

Yeah.

Everything's in SPM these days. We got CSPM, DSPM, KSPM. Is this ISPM? And is ISPM different from KIM?

Yeah. So it gets confusing, right? So I think of— yes, I think of KIM. I think, I think KIM I didn't invent these categories, so I don't know. My understanding is that KIM is a subset of ISPM, right? So KIM is more entitlement management on cloud specifically, whereas ISPM, you're talking about the entire identity security posture across all of SaaS and everything that might exist altogether. I also don't think ISPM is really as established as like ITDR is an official category. I think ISPM might have been pushed harder by vendors than it has done by someone like Gartner.

Hmm.

But it does sort of say, okay, I'm going to map out the identity attack surface and understand what that looks like, both managed and unmanaged identities, and which ones are vulnerable so you can get control of it. And it's the whole spectrum. And I think, yeah, that's why doing that. The CASB argument, I hear that a lot. I'll tell you why I think it's different, right? CASBs tend to be focused on whether you do it on the endpoint or you do it on the network perimeter, it tends to be focused on network traffic. And so what you would get is that unless you're doing something dirty like TLS interception and you're going into that whole world, Really what you're seeing is someone visited an app, right? And so you can't tell if they did it through personal use. You can't tell if they've done it for work use. It's hard to sort of tell the difference between someone visiting the homepage or actually logging in. When you're in the browser, you're inside the stream, right? So there's a ton of stuff you can do. One of the things you can do is like, for a start, actually see the identity. You can observe if they've hit the MFA login screen. You can determine what MFA methods were used. You can query the application. downstream using the employee session to actually pull back information in there and find out what privileges they've got. You can do stuff like, for example, as the employee logs into the IDP, you can take a hash and fingerprint it and pin it to the SSO login screen, which means the employee then cannot physically enter that anywhere else, right? You can't do any of that stuff with a CASB because CASB is kind of out around the outside of that, whereas you're inside the browser. So—

But I agree that popping TLS is dirty and that you have a vantage point, which is Less dirty. I agree with that. That makes sense. I'm sorry we dragged you into this Casby rabbit hole.

No, it's fine, man.

Yeah, but it was natural also, right? It was a natural rabbit hole.

Absolutely.

With natural rabbits, I'm sure, residing inside.

Yeah, absolutely.

Can we get full rabbit out of it now?

And I think it's a fair point. Like, I think you just— it's the level of granularity, right? That's the thing. And the thing is, I'm not just— I haven't like gone off and built a product and then trying to make a case for it, right? It's like, I saw a problem and said, okay, attackers are shifting off of the endpoint. I want to go and solve this problem. And then we looked into all the different technological ways that this could happen. And we started off by looking at CASB and then sort of said, okay, well, let's have a look at the logs. Let's see what's possible. And it's through hitting the limits of the visibility that we ended up deciding that we're going to advocate for browser telemetry. And there's a really simple example that I use to people. This is a simple example. You get much better ones, but an employee gets phished, right? It's an identity attack. Yeah. Someone steals the Okta credentials or the Google Workspace credential, whatever it might be. And you look at your EDR network and log data and it tells you 50 people visited a phishing site. Then what? What do you actually do? But whereas you're in the browser, you can say 50 people submitted their SSO credentials into this phishing site and it's shared with these 12 other apps. And by the way, none of those apps have MFA, and so they could also be vulnerable to password spraying. So now the attacker's stolen those credentials, they can do password spraying out and across everything else. It's a bit just tougher to do that. You don't have that level of detail with a CASB.

That's another really convincing argument to me, by the way, that it's the type of visibility that you almost have to have for some of the modern threats. And I guess the other devil's advocate or maybe contrarian question would be, doesn't it belong— well, I guess I know the answer. The question was, Doesn't it belong as part of browser? But I think that's how much of the tech you can ask, does antivirus belong as part of OS or something? I can see where, does it belong in a browser as a module built by a browser maker? The answer is yes, but when, right?

Yeah, it's interesting as well. I was just thinking about before, if you look at traditional network detection and response, you've got log monitoring, network monitoring, and EDR. In the identity world, you've got log monitoring by pulling logs from IDPs and Active Directory. You kind of got the EDR equivalent, which is what we're talking about inside the browser. Is CASB the kind of network traffic monitoring equivalent? I haven't really thought through the analogy there, but what I'm saying is you're kind of looking at that, whether it's endpoint or not, you're sort of looking at the metadata around the outside of the network like you would with a network traffic thing. So I don't know. I'm just thinking if you think about it that way. You can't really say that one is better or worse than the other. They all work together and combine, and each of them have their pros and cons, right? The problem with EDR is you've got to deploy it everywhere and you might not have full coverage across everything. Much easier if you've got network and log monitoring in a central location, you can get unmanaged devices. But my argument here is that I think that they all have pros and cons and they work together to give you the full visibility, and you have to pick which one you want to prioritize.

Adam, are you telling our listeners there are no silver bullets in security?

That's got to be the core message of the— yeah.

Wait a second. That must be really controversial, right? We all thought that we were going to buy a firewall and we are done. Oh, it sucks.

No, but I think that's a very important and nuanced thing to reflect on. Like, truly, when you're making a decision about what technology you're going to use, everything has trade-offs. And some trade-offs for a given org might be better or worse. And I think that's really important.

Yeah, totally.

Yeah.

Let me jump somewhere in our questions because lately I've been kind of obsessing about the detection using a dedicated technology versus detection using, say, a SIEM. So can I basically get the browser logs, shove them into traditional SIEM and/or Yuba, and hope for the same results? Like, I think that's the question we asked the CDR guy a few episodes back when we said, well, can't we just have cloud logs into a SIEM and replicate CDR? So can we get browser logs into a SIEM and replicate your technology?

So I don't know how you get browser logs full stop back into a SIEM, if that's possible.

That's good.

Yeah, I'm not sure actually how you do. I mean, certainly some things you can get equivalent of, like, I mean, you could inside a browser look at telemetry like file upload, file downloads, you know, things like extension installed, extension uninstalled. And with the enterprise browser movement, there may be some more visibility and things that you could feed back in there, and that's certainly possible. But then when you start going into detecting phishing frameworks like EvilJinx, that stuff certainly doesn't exist yet, and that's really useful telemetry to be able to shift back. So I think that there is something, there's enough scope inside the browser to do lots of unique and clever things that I think it adds something new to the picture, which is why I advocate for that. When it comes to logs from an IDP, into a SIEM, I think it really comes down to, yes, you could build a lot of that stuff, to be honest. You could get really far by just pulling IDP logs into a SIEM and writing rules and doing everything else. But it depends on the type of organization, right? For some people, maintaining all those rules and everything else is really a lot of effort. Whereas if you have on a traditional ITDR, it's effectively like a little mini SIEM that sits like a SIEM, like the UEBA. argument. And for them, it's like, okay, you pull all the stuff straight into an ITR, boom, you got some out-of-the-box rules, which massively reduces your, your risk to identity-based attacks. And then those consolidated alerts then go back into your SIEM. So I think from a technology perspective, it's like not as valuable, but it's circumstantial. If you're less sophisticated, then maybe it gives you a quick level up.

Okay, so then let's make things concrete for a minute and talk about what those alerts are. What are some of the things that we catch this leg? What are the threats we're worried about here?

So when are you talking about when it comes to the log monitoring side or—

Or just what does an ITDR detect concretely? What do we look for? What do we catch? How do we help orgs be more secure with it?

So it's anything identity related. So you'd be saying things like, for example, somebody's just signed in. Some of the stuff is ISE-based.

Yeah.

So there was a login from a particular IP address that happened from, you know, a known malicious IP, or there's stuff like, for example, MFA fatigue, or like administrator can perform this other malicious action. The stuff that's inside the browser is a lot more unique. So as I said before, you do have things like, I mean, I can only talk for our kind of what we've been focusing on, but things like cloned site detection.

Mm-hmm.

So an employee logs into a legitimate application, like a legitimate SaaS application extension, takes a fingerprint of that and says, Hey, here's a hash for what this should look like. And then when it hits and sees a cloned one, it goes, whoa, no, this doesn't look right, blocks that, and then sends back an alert saying someone did this. Or someone just entered their Okta credentials into another site. If it's on a known app, then it's corporate password reuse and you get a good notification for that. If it's, you know, not a known app, then it's probably a phishing site and then that's being notified as well. And those kinds of things as well. Also stuff like session hijacking. So That's obviously become a big problem. So one of the things that we thought was super interesting there is like the browser extension will go in and inject a one-time token into the browser. And then that appears then in the, in the kind of header in the IDP logs. And then you can pull the IDP logs and you can say, find me 2 HTTP payloads with matching session IDs where only one has been stamped with this one-time token.

Ah.

So effectively what you're doing then is stamping and authenticating each session. If an attacker then steals it, you know that's session hijacking, right? So I'm giving you a mix of stuff there because some of the first ones I mentioned are, they're like, whoa, haven't we done those sorts of things before? We kind of have.

But that one you just described is really cool to catch. Yeah, that's nice.

Exactly. But some of them are net new, right? Yeah.

That's super tricky to find through other means also. Not that we are trying to tell you that you have a good business, but you have a good— we don't know, but it actually makes sense as a threat that's super hard to deal with through other means.

Yeah, exactly.

Yeah.

And there's a ton of these sorts of things, right? I mean, it's— and that's why I think it's interesting. But anyway, I'm sort of— what I'm trying to share here of the insights is that, remember, I came from a position of being skeptical about ITDR to going, actually, there's more to it. And so the first examples I'm talking about is like, haven't we always done identity? Okay, it shifted to the cloud and the attack surface is more prominent and things are more important, so we should give it more attention. But is it a category? I don't know. Could you do this with a SIEM? Even that's the case, yeah, and there's a few more novel things, but when you add something new, session hijacking detection example, then yeah, okay, maybe it's got some legs. Maybe there's something that should actually be called that. And that's where I am now as I'm thinking, okay, as an industry, if we start getting creative about it, there's probably a need here. And this is a parallel. I still think we should drop the T though and call it IDR, but we've had that discussion.

Yeah, that was extra triggering. Thank you for retriggering my triggers because I cannot transcend the fact that it's the detection response of threats to IT. But you know, the person who is the most at fault for this is me because I called EDR ETDR first. And then other— so the original name for EDR was ETDR because I wanted to step away from malware. So, a T was added to say not just malware. And then, other analysts piled on me for saying 4-letter acronyms don't work. Haha. Hi, Kaspi. But I said, okay, fine, take the T back. And it became EDR. And now, the dude who came with ITDR, for some reason, put the T back. So unfortunately, we can blame everybody, but it's my fault.

Do you not think it's your opportunity to get your own back though, Anton? You can go back now and say, hey man, drop the T. Push it back the other way.

Or we could take inspiration from CNAPP and rename it to IDTDR.

Oh, I like it. Go the other way.

Yeah, just go the other way.

No, no, no, no.

To the screaming no, but the voice, the speech volume controls in Meet stopped me from doing this.

All right, well, in your good podcasting host skills, ask the last question, then I'll ask the closing question.

Okay.

So just advice to organizations that are considering the ITDR implementation. Like, you've been dealing with clients, prospects, you're starting deployments. What's your advice? Like, what should they do to succeed with this tech, with your implementation of this tech?

Yeah. I mean, I think it's important to do it. And I'm not saying that because of the fact that I'm in this. Like I said, I thought it was an important problem, therefore went to tackle it. But everywhere you look, people are saying cloud-conscious threat actors, identity attacks are the big main thing. So I think it is worth the focus. And I think that my advice would be to sort of think about what sort of organization you are, right? So if you are genuinely one of those sorts of companies where everything's locked down, everyone is forced through a VPN, everyone goes back and genuinely you can only log into apps if you go via Okta and no one can self-service sign up to apps on the outside. you can probably and probably should prioritize putting the logs from your core IDP and building detections around that. If you have less sophistication, an out-of-the-box ITDR that does log parsing might give you a quick level up. If you have more sophistication, then writing custom SIEM rules is going to give you a lot more power. But it's just the normal, do I build or do I buy argument. I'd say for other organizations, the thing to remember is that there's another— one of the big shifts that's happening here is people shifting stuff to the cloud and shifting things online, which is broadening the attack surface. But the other shift that's happening that people aren't thinking about enough is the fact that identity is becoming decentralized. And so what I mean by this is that people think, oh yeah, my goal is to get everything onto SSO. That's now the last step in the process. Employees just sign up on their own. They sign up to a bunch of applications. They put a load of apps online. And then at some point, IT discover it, and they then add that onto the SSO provider. When you do that, it doesn't delete the local account. So what you end up with is these apps that exist online where you can log in with, you can choose like, I'll log in with password, OIDC, or SAML, and you can just sort of decide. So you end up with these identities that sort of exist and you can still log into and they make up your identity attack surface, right? So I'm just saying that these kind of decentralized, unmanaged identities are also part of the identity attack surface. And those should be considered as well.

Well, Adam, I think that's an excellent note to close on for practical advice. I'll ask our half of a closing question since Anton kind of asked the first half. Do you have recommended reading other than your blog post, which I'm going to go check out after this?

I think any of the big security vendors at the moment, like the EDR vendors, are talking a lot about ITDR in general. And then so those blogs are a good blog. Obviously we publish a lot of research around this as well in terms of the sort of browser orientated. And there are actually then some new school vendors that are starting up that are calling ITDR, but they're specifically cloud focused. And I think to get a good generalized overview of a fairly undefined industry, it's good to look at the AD-focused on-prem type ITDR, the kind of original one, these modern startups that focus more on cloud from logs, and some of the stuff that we're publishing, which is the browser-based. So yeah, that's general reading as opposed to, I can't point you at a specific resource, unfortunately. Hopefully, that helps.

No, that's great. That's really good advice. Adam, I can't thank you enough for joining us. You encountered 2 people who appeared initially very skeptical of your very existence and enjoyed the conversation tremendously. So thank you for joining us.

Glad to hear it. Mission complete.

Thanks.

And now we are at time. Thank you very much for listening and, of course, for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website, cloud.withgoogle.com/cloudsecurity, Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter, @Anton_Chuvakin and @_TimPico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Bye-bye.

Secure running. Secure running.