Well, hello, everyone. Thanks for staying around this afternoon.
So, yeah, I do want to talk about ITDR a little bit and really what is driving the need for it in the market today. So we'll start off by looking at the threat landscape, kind of give an overview of what ITDR is, at least the way we see it, some notions of its architecture, and then what we think will be the future for ITDR. So the threat landscape is not just attacks on accounts but on IAM systems.
You know, we've all heard probably for at least 10 or 15 years identity is the new perimeter. I mean, this isn't even a new saying anymore. But the truth is it's been a perimeter for a very long time. It's just nice that it's being acknowledged as a security control today. Account takeovers are going up. I know typically we think of account takeover in the consumer world, but, you know, guess what? Employee accounts are getting taken over too. Employees are in some cases selling access to their accounts to brokers on the dark web.
And, of course, identity is in the middle of all of it because all cyber attacks have some element of identity in them. I mean, you can't get in, move around systems, and exfiltrate data without that account. And they can buy these things on the dark web. Ransomware attackers these days sometimes don't even bother with malware.
You know, that leads to a new saying. Attackers don't break in, they log in. So what are we dealing with?
Well, those account takeovers. There's still APT, advanced persistent threat, ransomware, and malware-less ransomware, and insider threats of different kinds.
You know, I read just a few days ago about they found a guy in the U.S. who had, like, 20 laptops. He'd rented out his identity, and they had 20 different VPN sessions to countries probably where he shouldn't.
But, I mean, this guy was, you know, working for 20 companies and giving access to who knows what, you know, state intelligence agencies. So it's not just the disgruntled employee that we have to worry about anymore.
Now, I know this isn't really readable, but with this, what I wanted to express was, you know, in the cybersecurity world, they've developed the MITRE attack matrix. And it was looking at all the different tactics, techniques, and procedures that attackers use to get in and then eventually exfiltrate data.
So, you know, it starts on the left with recon. You know, phishing, smishing, vishing, all these different ishings that can be used to get credentials. Then you'll see that they, you know, move to the right. They will take over machines, take over accounts. And then most of the damage is done, you know, through the middle and to the right. But what is important to note, and you can look at this when you get these in the notes tomorrow, everything from initial access on over depends on a valid account.
Now, it might be a compromised credential, or it might be an account that the bad guys go ahead and create after they get on there, but it all comes from a valid identity credential. That's why identity is very important in cybersecurity. So just to drill down a little bit on some of these columns in the MITRE attack matrix, you know, credential harvesting, we're all probably pretty familiar with how these work, you know, password spring, for example.
But this is a good example, too, because, you know, it's not necessarily going to set off an alarm in your security, you know, blank DR program because one failed login doesn't lock an account out. So, you know, there's these under-the-radar kinds of attacks that unless you're operating with a higher level of intelligence and applying logic to the data that's coming in, you know, signs like this might be missed. Same thing, you know, brute force password attacks against offline databases, MFA fatigue.
I mean, I won't read through the whole list, but there are several that are notable, like DC sync. Once an attacker gets in and they're on the right workstation, for example, then they can, you know, start a domain controller sync operation and pull in all the information that would be contained in an Active Directory domain.
With DC Shadow, they can actually set up rogue domain controllers and not only pull in information, get all the information they need about how to move around a victim domain, but also push out changes about, you know, adding accounts, changing permissions, adding people to groups and whatnot.
And then things like the golden ticket forging, I mean, a few years ago with the SolarWinds incident, you know, the golden SAML ticket was used, and that was a way to perpetrate a supply chain attack, and that's one reason why we've been talking about supply chain compromise quite a bit in the last few years. Lastly, we have session hijacking.
I mean, I think this is really worth calling out because it has become so prevalent, you know, with everybody. So many organizations using many different SAS applications getting access to a valid cookie or token can give you an enormous amount of access, and depending on how you have those policies set to time out, if somebody does a man-in-the-middle attack, grabs a valid token, I mean, these too are for sale on the dark web.
If the policies are set for 30 or 60 days validity on those cookies or tokens, then that's still an awful lot of damage that can be done inside one SAS application, which then might be used to, you know, move on to other applications that you're using too. Once the malicious actors get in, of course they're going to want to do discovery.
You know, they'll do DNS recon, find out where the domain controllers are. They'll use Bloodhound. Bloodhound is one of those tools that can be used for good or for ill. It can help you, you know, visualize what your AD structure is like, and actually for an attacker, get a really good idea of what they would want to attack, what the optimal pathway for, you know, compromising an entire enterprise would be. There's other tools that they can use, like Security Account Manager Remote, to just remotely query and get, you know, local group and user information as well.
Persistence, once they're in, they're going to want to stay in, you know, so that you've got the trust ticket forging again, Skeleton Key Attack, which is, you know, corrupting an LSAS, good old ACL editing, you know, access control lists, and you can be sure that the thing they're going to do the most of is to avoid getting kicked out, they're going to create more accounts, and that will be in Active Directory, maybe on local machines, but also in all the cloud instances, both Infrastructure as a Service and SAS applications, and they typically tend to, you know, make sure that they create accounts of various types, including admins, and again, this is to conceal and make sure that if someday one account gets found out to be, you know, being used for malicious activity, they still have others to fall back on.
And, of course, they can do, you know, old-fashioned techniques like log-on script changes and, you know, changing things in the registry to make sure maybe the malware loads every time, or, you know, add devices for MFA so that, you know, when an automatic notification goes out for should this person have access, it gets redirected to a device that they control. Lateral movement. In order to find out what you've got, what they might be interested in stealing, then they move on to lateral movement. So if they're inside, they've got access to your directory, your email directory.
It's certainly easy for them then to craft an email that not only looks like it's coming from the right person, but in effect would be coming from the right person. And, again, thinking kind of like that CFO fraud story that we all heard about probably last year now.
You know, they could find RDP that's still in use. That certainly makes it easier for them to move around an enterprise. They can use built-in tools like Windows Remote Management or Group Policy Objects.
Of course, with Group Policy Objects, you can use that even to push malware or scripts. And then cross-domain Kerberos ticket forging.
So, again, another example of supply chain compromise. They get in, they can start, you know, pushing out, gaining access to domains beyond the one that they have initially compromised. So ITDR.
You know, it's been a thing that we've been talking about for a couple of years. I will say it's a tool like many others. When the term gets invented, we don't know what ever the vendors who claim to be in that space currently have in their portfolio. So there's a lot of variety in what you see in terms of capabilities with ITDR. So I thought, you know, for our purposes, I'll try to define it. This is at least what we're looking for. We did do a leadership compass on it last year.
We're going to do another one on it this year to update it because there's more vendors and certainly a lot more interest in it. But I think we need to focus on the enterprise-wide telemetry collection part because many of us do have Active Directory on-prem. We may have LDAP on-prem, but we also have, you know, infrastructures and service instances that we're using and many SaaS applications. So all this is generating information that if you could pull it together and correlate it, you might find signs of, you know, low-level, quiet, or sophisticated attacks.
But these are not things that, you know, a traditional security tool like even XDR is really built to do because a lot of the things like, okay, say the bad guy's broken in, he's taken over an admin account and successfully authenticating, escalating privilege on here, there, and everywhere. None of those things set off alerts because it's allowed activity. But there's an opportunity if, you know, with organizational domain knowledge to know what is right, what's in the baseline of activity that should be considered normal and what's not.
And I think that abstraction layer is something that ITDR can help with. So it also requires that, you know, cross-domain event correlation. So all those different systems you need to get information from. It needs to have a good investigative interface for your SOC. And then the R part of ITDR is about response.
And, you know, the responses are fairly basic, but, you know, they kind of cover two types. It's either disabling accounts or revoking credentials or revoking tokens, terminating sessions, or, you know, maybe use this as an opportunity to do some sort of step-up authentication and make sure maybe this is a valid person on the other end of the session. The question I think most organizations have is, are you ready to trust the vendor and the logic that they've built around automation, or is this something you want a human to still make a decision about?
So, you know, manual versus automated responses, I think that's an individual organization decision that needs to be made. So where does it fit? Admittedly, I probably should have put ITDR in the center because, really, it is kind of in the center of all the things here in the picture.
You know, over on your left, you've got all your traditional IAM tools, your LDAP, your Active Directory, IDAS services that you're using, and you're probably using multiple. Then you've got identity fabric services because, well, nobody can just switch out their whole IAM system every year or two, but yet you need to change, you know, what you're doing. Maybe you need to offer passwordless authentication so you have, you know, an authentication service that you've added on in the identity fabric model.
Both of these two generic classes provide a lot of good telemetry that needs to be evaluated by ITDR solutions. Same thing goes for SAS. You need to get information from that, on-prem applications. Think about those applications that maybe they have their own LDAP or maybe they have some sort of, you know, proprietary authorization system. You need that information, too, and it would be great if it could be fed by your endpoint security, network security, XDR. And CTI over here on the side is Cyber Threat Intelligence.
It's always important to have up-to-date, you know, external sources of information about what the current threats are, whether that's coming from open source or curated subscriptions. You know, we're all still using SIMS. It's kind of like the data lake, the identity plus security data lake. Many people have SOAR, Automation and Response, but again, you see right now, at least, ITDR is kind of outside of all of that. The use cases that we see are pretty straightforward.
You want to protect your LDAP, protect your Active Directory, your on-prem stuff, protect your IDAS services that you're using, SAS applications that are depending on those, prevent workforce ATO because it is a problem, and then stop this APT stuff from going on where it's happening.
And, you know, just like the kill chain of old, the farther to the left that you can, you know, intervene in a cyber attack, the better off you are because as they move across, do lateral movement discovery and start exfiltration, it gets, you know, exponentially harder to, you know, root them out and restore to a working state. So, again, another reason why I think ITDR is advantageous is it can give you an earlier view of these nefarious activities than maybe just the cybersecurity tools that we have today.
It also, you know, needs to be able to deter those insider threats of various types that we talked about and enforce MFA, and, of course, look for those MFA bypass attempts where they're, you know, pinging your people in the sock at 3 o'clock on Saturday morning and just hoping that eventually they say yes so they get access. Again, that's another thing that ITDR can help look for. On the technical requirements side, you know, we go to the question of how is this implemented?
APIs, of course, are important for everything these days, REST APIs in particular, and hopefully they enforce secure authentication mechanisms. But agents, you know, some of the XDR-focused vendors who are entering, or not just entering, but are in the ITDR business today will have you install software agents, like their endpoint agents, on domain controllers.
You know, this makes sense because a lot of those, like the database for Active Directory, you know, lives on these machines, so having that level, you know, down at the operating system level view of what's going on with those components can provide you, you know, a degree of observability that you won't get anywhere else. So agent-based deployment is not a bad thing in this case.
Of course, you need to collect the credentials, the cyber threat intelligence I mentioned. Another thing about ITDR is I think it's kind of like next-gen UBA. So in order to, it's next-gen UBA and access analytics. So finding these baselines, these patterns of what's normal and what's not, and then being able to alert upon that and get something done before damage happens.
Again, the investigations and the responses, those are key features you should look for in an ITDR solution. I'll briefly mention Deception. This is not in many ITDR products today, but there are a few that have this. I think it's a really interesting alternative, at least. This is kind of like a new version of the honeypot.
You know, these vendors will allow you to define and easily manage fake accounts of all different kinds, or even other kinds of fake credentials or certificates or things like that. And the idea there is you have these living in your directory, and you know nobody legitimate is using them. And you can set an alert for any activity on this account. You get an alert on that, you know more than likely it's a bad actor. So you've got bad actors in your system.
Again, it's not widely implemented, but I think it's at least interesting and somewhat innovative. What are the challenges with ITDR?
Well, I think you probably already have the picture. This is complex.
You know, if you've got AD, LDAP, you've got multiple IDAS and a whole bunch of SAS applications. How do you connect into all those things? Just the deployment itself could be difficult. Maybe that's why it's increasingly paired with things like XDR or other cloud-based security solutions.
But then, at least for now, you've got to integrate with all these other tools that you have in your security architecture. So, future of ITDR. What do we see here?
Well, there's some good work going on in OpenID Foundation around the Shared Signals framework. And there's two related protocol here, CAPE, Continuous Access Evaluation Protocol, you know, quickly define that. It allows for streaming information from the transmitter to the receiver about events, about subjects that they're interested in.
And really, just to boil it down, this is a way for us to, like, transmit between different domains information about sessions that have been revoked or token claims that have been changed or assurance level, authentication or identity assurance levels that have changed. And the risk part here, the risk incident sharing and coordination, will allow you to then also send compromised credential intelligence. Do they need a credential change? Should you force a password reset? Is this actually coming from an account that's been disabled or deleted?
So, this kind of information, once we can send this, I think will be very, very valuable. There's a lot of good compromised credential intelligence capabilities that are, right now, only in the network of the providers that are offering it.
So, the idea of expanding that, I think, will be great. In the interest of time, I'll just say the newer architecture, at least one possible future for ITDR, is it becomes very closely aligned, if not completely taken over by XDR. It will run, you know, right in parallel with it. We'll have a cape hub that kind of mediates the various intelligence sources that front end the input into ITDR. The only other really noteworthy thing here is we're losing SOAR, because XDR should be able to do what SOAR does.
But we'll keep SIEM, because most organizations say they still need a SIEM to collect information for compliance. And lastly, ITDR is already a big market, you know, closing in on three billion. I think the shared signals framework stuff will be advantageous. There have been a lot of acquisitions already, and I'm sure the startup size companies that are out there will probably be acquired in the next two years or so.
And again, yeah, we'll have a new leadership compass on ITDR coming out this autumn. So, thank you. APPLAUSE Great.
Thanks, John. Your presentation was annoyingly comprehensive, so I'm being very challenged to find a question here, and I think it's true for the audience as well, because we don't have any questions here. But the one thing you did mention was the idea of session hijacking as being a leading sort of attack vector.
So, besides ITDR, what can organizations do? Well, I think probably the two best things, to make it quick, would be keep your session policy timeout as low as users will accept it, you know, if you're a consumer-facing site. And secondly, use mutual TLS. Do some TLS binding. That gives you a little bit more resilience against those kinds of attacks. Great. Thanks. John Talbot. Thank you. APPLAUSE