The Audit Binder Is Not a Security Strategy

Hello, everybody, and welcome to our webinar today. I'm John Tolbert from KuppingerCole, and today I'm joined by Chris Fields, who's Senior Vice President of Solutions and Advisory Services at Simeio.

Hello, Chris. Hello, John. Thanks for having me today. Thank you for being here. Our topic today is The Audit Binder Is Not a Security Strategy. So a little bit of logistics info before we get going here. Everybody's muted centrally, so there's no need to try to mute or unmute yourself. We're going to do two poll questions, and we'll talk about the results at the end. There's a Q&A box in the Livestorm Control Panel, and you can submit questions at any time, and we will be happy to take those toward the end as well.

And then lastly, we're recording this, so both the slides and the recording should be available in a few days. So why don't we start with a poll question? Since we're going to be talking about audits, we're curious to find out, how does your organization get identity audit evidence today? We've got a few choices here for you, so please feel free to jump in and select whichever one represents what you all are doing today, and we will take a look at the results a little later on.

So we're going to start by talking about where audits fall short, and I thought it might be good to sort of come up with a generic example. So let's say we have a contractor named Dana, and her contract expires in January. Now maybe everything seems to happen right. The manager inside the company submitted a ticket through the ITSM system that indicates that she should no longer have access, but for whatever reason, maybe the ITSM doesn't talk to HR, doesn't integrate with identity systems, it may not have actually happened.

So even months later, her account might still have access, even in fact, if she's working in finance, be able to approve payments. So I think we can all sort of see what the risk there might be. So we've all been doing audits for many years, but we've also said that audit is not exactly security in and of itself. Compliance is not security, but I think we also often find that the need for compliance can, at the very least, drive security budgets.

So we often rely on needing to produce audit evidence as a reason for, you know, needing money to put in new and different kinds of identity management systems. What's your take on that, Chris, and where do you think the gap is between what gets documented and what's really going on inside most organizations that you've been working with?

Yeah, I would say, John, that unfortunately the gap normally starts shortly after some state that we think we know is documented, say an audit or an access certification, et cetera, because, you know, these activities, identities, I mean, it's a living breathing system. So, you know, a lot of times soon after an audit, the administrator may go in and, you know, maybe user has an issue and they say, hey, I can't log in, it's critical for a meeting, this MFA thing is hanging me up, can you disable it just for, you know, just one time.

They do it, they get in, and then, you know, you don't catch until the next audit cycle that that type of thing has happened. So, unfortunately, it's very common shortly after a documented event that the state of identities change.

Yeah, I mean, in our examples here, we've got an orphan account, we've got admin rights that are granted for, you know, theoretically a short period of time that might linger on for quite a while, that MFA exception you just talked about, and then maybe service accounts that don't have a human owner attached to them. Which of those do you think are the types that you see most often?

I would say the one we see most often is that the person, and typically it's a contractor or a type of identity that may not be as tightly tracked by the organization, you know, the SOW contract ends, the, you know, the time period or the thing that the reason that person had access to the system has kind of come and passed, and the system just don't take the proactive action to catch that and remediate it until we get to some type of audit where we're going through systematically and catching those things.

Yeah, and, you know, we'll be talking a bit more about different frameworks and regulations and how they should drive security policies as we go today, but I think it's also good to keep in mind that for those that are trying to get or keep their SOC 2 Type 2 or ISO 27001 or NIST 853, it's important to not only be able to produce this evidence at audit time, but to keep these things going in between audits as well.

So, you know, we often like to say things are the tip of the iceberg, and most identity management systems that we've been using since the, probably the late 80s or 90s, were designed with human identities in mind, so we know how they work, what they should look like. But, you know, with mentioning service accounts a minute ago, we have had a proliferation of other kinds of non-human identities like service accounts, keys, workloads, different things like that.

And we've seen a variety of different statistics that kind of run the gamut from, you know, 10 times to 100 times the number of human identities there are for these NHIs. And you see that in many cases, these NHIs are probably not centrally managed, particularly, let's say, SaaS accounts. We see that many times business units within an organization might go out and procure different SaaS services, and IT may be unaware of what they're even using.

You know, this is a shadow IT problem. But, Chris, would you agree that the human accounts are sort of the tip of the iceberg and there's all sorts of other accounts that we need to be concerned about, particularly when it comes to audit time?

And if so, which one do you think is the most common? Absolutely, John. I would say it's, unfortunately, the NHIs and now as we're in the kind of age of AI and agents, that they're by far the biggest visibility gap in today's enterprises.

And, you know, what we see is we've kind of grown up from the world of, you know, hey, it's an employee, there's an HR system, there's kind of a defined sequence to how things occur. Whereas with, you know, NHIs and typically some, it's more of a natural activity that's happening either out in the business units and departments or kind of out in the wild, if you will. And a lot of times they're just not the controls to engage, to kind of keep folks in the reins.

A lot of times administrators, you know, they have rights to do these things unless there's a framework and a process in place to actually capture these things and gate it when it happens. It, you know, would just end up with the wild, wild west. So that really is our, and we'll talk about this obviously a little further on in the discussion, is why we really are urging organizations to move more towards the identity, posture, and governance framework to capture these things and get ahead of it. Yeah. Yeah.

I think you're hinting at the question that I have here is, you know, if a lot of these accounts are sort of under the purview of business units themselves and not directly managed by IT, then how does IT ever even find them? And I think that the identity, security, posture management is a good possibility for that. Absolutely. So now that we've introduced the term, what do we really mean by identity posture management? I like to think of it as, you know, it's what the current state is. And you can use an audit or trying to keep things in compliance by grading the posture itself.

So it begins, of course, with visibility. And, you know, we've seen the use of that term quite a bit lately, visibility and observability, looking at all the different types of accounts and entitlements and policies. But then what do you do with the simple fact that you have visibility into these things, if you have visibility into all the different parts of your identity environment? You need to be able to transform that into intelligence and then ultimately act on that.

So what do you see is how posture management is different from just the access certifications and IGA reports that, you know, we've been familiar with for decades? Yeah, I would say that look at posture management as basically rising up and seeing the forest instead of all the trees, you know, the day-to-day activities in our IGA PAM, access management tools is really the, I mean, it's blocking and tackling. You must have those things to have a chance at really being secure and having the right foundation.

But posture management is looking at, you know, kind of rising above that, looking at all those things across the entire ecosystem and having the ability to actually focus on the that are important, which in this case, you know, when it's out of the compliance, it's what are the things that are actually providing the most risk based on our controls and frameworks that we're trying to stay within compliance for? Yeah, which of the three layers here would you say is the weakest in most organizations that encounter?

I mean, I think most people have at least the ability to see things thanks to logging and SIM solutions and things like that. But where do you think that the biggest weaknesses lie here? It's normally in that intelligence layer. And I'll say, even with visibility, we're finding that unfortunately, a lot of organizations are still having a visibility gap with their agentic AI activities. But intelligence is by far the biggest area of weakness.

And it simply is because a lot of times when we look at the our SIM tools and our, you know, network intelligence tools and all of that, that there's no lack of data and events. We just lack the ability to really tie that into which things are important as we relate them back to our controls and our compliance frameworks that we're trying to stay compliant against.

Yeah, I agree. I think there's good capabilities on the action side, but intelligence is, you know, when you think about all the disparate systems that most organizations have, what does it mean to have, let's say, an excessive entitlement in one particular system? And what does that really mean to your overall environment? And I think being able to right size and figure out what to do with that is a gap that a lot of organizations still have today. Yep.

So again, thinking about audits, what are the things that you really need to see and understand when you're doing an audit? You know, we've got a couple of examples here, identities, you know, who has access, what controls exist, the events, you know, the stuff in the logs, and then the applications and infrastructure where access actually happens. So which one of these sources do you think is the hardest to collect and why?

No, the, it's really the, I'd say the controls are the hardest thing to kind of keep in context to compare to all the things that are happening within the environment, you know, all the authentication, authorization, you know, granting of access, et cetera. Those are all events or what we call signals. But they really, they don't have meaning unless you can relate those back to the controls and understand, hey, this thing just happened. I just saw an authentication event, for example, on what we consider a financially significant application.

And through the, you know, that visibility of the actual authentication stream, we can tell that there was no MFA tied to it, and that's supposed to be mandatory for that app. So again, it's that ability of what are the controls and how can we relate that to the actual events that I see as the biggest gap today. And it's unfortunately what keeps us in more of a manual point in time audit posture as opposed to more of a proactive identity security posture.

You know, another question here I think is sort of organizational, and it's thinking about, say, for enterprises that have fully developed SOCs, and maybe SOCs are responsible for monitoring identity events, or, you know, there are some organizations that have a dedicated identity team, maybe an identity SOC. What do you see in the field? Are there who's responsible for the identity-related events and remediation? Is it the SOC, or do you often see that there are, you know, dedicated teams for identity events only?

Yeah, the most common setup that we see that there's obviously a SOC that's responsible for, you know, kind of looking at the glass, looking at the dashboard, the events to come through.

But it's a partnership with the identity team to say, how do we tie those kind of SOC alerts and events into identity tools that can actually, you know, number one, take actions to just limit the blast radius if it is something that we know is potentially very bad, but number two, actually go further and automate kind of the whole remediation chain, you know, going back to, you know, does that identity need to be deleted in the source system if there's an identity tied to it, or if that account was on a particular system, going and actually looking for that account on all other systems before attempted events happen on other systems.

So, it's really a combination of the SOC working with the identity team to make sure all the identity tools and things within the infrastructure are being used. Yeah, and I think here the notion of when do we do these things is kind of interesting too, because if, again, we're sort of trying to comply and have audits to prove compliance, then you may see things like access certifications on a quarterly or maybe even annual basis.

Then there are other things that sort of need to be looked at daily, and this is definitely where automation can be helpful, configuration changes, and then even real time, and this is where, you know, authentication, failed authentication attempts, changes to credentials and profiles, those are things that, you know, should trigger somebody to look at them and see if they were legitimate or not as soon as they happen.

One other thing I'll add on this one, John, is kind of in the whole spectrum, you know, we'll call it a maturity curve of moving from, you know, manual point in time to more kind of automated continuous compliance, is really looking at all of the different types of actions or think of them as signals and making sure that that ties into some control.

For example, if there's a signal through, you know, an admin say granting a user privileged access on a particular app, that should actually be, you know, registered and noted so that at the point that that access is supposed to expire and no longer be needed, we know that that's going back and being remediated, and that's, again, kind of put in the, we'll call it the virtual audit binders, this event happened, here's the proof and evidence that we closed it off via our PAM tool, just as an example.

Yeah, I think it's really good to mention that I'm working on leadership compass for identity fabrics right now, and I've been asking questions around shared single signals framework and CAPE, and it's good to see that some vendors are starting to support that. I think those identity signals do need to be passed between different systems, sometimes not just within an organization, but in, you know, federated or collaborative environments, it certainly would be good to be able to share key risk indicators in between different parts of the supply chain, for example.

So, and what that's doing, really, I think is, if you look here, we're bringing that down from something that happens periodically, maybe, you know, long periods of time pass between those kinds of notifications to a more real-time way of providing information to connected systems or even collaboration partners. Yep, yep, absolutely.

So, it's a little informal quiz, I thought I'd put together a couple of things that look like what you might see in an audit, and we've got our example here, Dana, the contractor, her contract ended in January, but, and you see that last sign-in was nine months ago, but the reviewer might have said, hey, keep this person by mistake, because I think we've all seen this where we work, too, over the years, that managers may or may not have good information about who's actually working for them, or they may err on the side of caution and just say, yes, keep access to things that maybe they shouldn't allow access to still.

But then, you know, you look here, you can see where some of the problems are that we've been talking about, and it might not be obvious until you really dig into the data. I mean, a case here with a service account that doesn't have an owner, another case of dormant access, does this person really even need access anymore, somebody who probably has too many privileges, and, of course, the orphan account.

So, I mean, would you say these are kind of typical of what you and your clients have seen out in the world? Yeah, I would say by far the three most common are the orphan accounts, the unowned identities, and dormant access. And ironically, that they're actually three of the orphans and dormant. It's not that difficult to stay on top of if you got the right kind of posture and framework in place.

So, yeah, I'd say those are definitely the top three for sure. So, yeah, a few other examples, you know, we've mentioned a few of these, but, you know, there's also weak policies, stale credentials, you know, and again, there are tools that can kind of help us look for things like that, the keys and certificates that never seem to get rotated, those unowned identities, service accounts are a great example.

You know, when you have encountered things like dormant accounts or orphan accounts, what would you say is a typical age on them, you know, last time since login, how bad has it gotten or what have you seen?

You know, unfortunately, John, I've seen some horror stories, but actually just last year that there was a client where there was an orphan account that had been on the system for over two years, you know, still active, the contractor long left, and that, you know, it was just one of those things that that particular system wasn't tied into the IAM tooling that they were using to drive it, and I'll talk about that in one of our slides upcoming here about just how important it is to try to get connected all the systems that are critical for your compliance and audit so that those things don't get, you know, kind of left out by mistake.

I think it was one of those cases where it just wasn't known that that system was not part of the ecosystem that was going through the IGA engine and driving the reporting. Yeah, I think one of the hardest ones probably to fix would be the service account that doesn't have a human associated with it because people are going to be somewhat hesitant to turn off a service account because you never know what actually depends on it, but if you can't find the owner for that account, I think that can be a really sticky situation.

Yep, absolutely. I'll actually say it underscores that the importance of having there's some new tools in the market that really hit on finding the account, but also kind of putting a governance framework in place for, you know, who's the owner, integrating with the network and other tools in the environment to find out that the last time that it was actually used and really given our IT and business users that the information they to make the right decisions.

I think a lot of times we forget that the business users are not security experts and it's kind of on us to give them the right tools and visibility and make it easy to keep the enterprise secure. Agreed.

So, before we move on, we'll have another poll question next, but the results on the organization produce identity audit evidence today. 50% say that they're doing automated collection on a periodic schedule, so that's good at least. At least some collections happening, but only about a third are doing continuous collection, map to controls. About 17% are still doing manual collection with the dreaded spreadsheet, so lots of room for improvement.

Unfortunately, there are some products out there that can can help us move toward that more continuous and automated collection and interpretation of identity conditions. So, let's drill down a little bit more on this. We've been talking about orphan accounts, so when was the last time that you found an orphan account outside of an audit?

So, please feel free to give us your answer and we'll discuss it a little later. You know, John, I'll interject a funny story, but during one of our global rollouts of an IGA tool, it was the first time the organization was really using an enterprise IGA tool to manage all the key systems and applications.

So, before we went live, we actually did a just a kind of a numbers in a hat, you know, just say, hey, put the number in that you think it is going to be after we do all the reconciliations and bring all the accounts in tied to, you know, the identities from the source systems. How many orphan accounts were going to fall out of that? And we ended up, it was a global company, probably, gosh, 25,000 employees and other 10,000 contractors and other types of accounts. And what those are, the identities, the accounts were close to a million.

And there were about 40,000 orphans that came out of that first pool. The highest guess was 5,000.

So, it just kind of gives you, it kind of gave the organization a way to understand, you know, what an orphan is and kind of give visibility, but make it fun and also make them realize that, man, that the numbers were way bigger than what they could have ever imagined. Yeah, that's huge. Wow. Seems like that would take quite a while to even get started on remediating all those.

So, we've been talking about, you know, things that can percolate up and become a business risk, but how does this actually happen? You know, once you have a finding, like, you know, our example, Dana, with an account that's still active months after she left, obviously that means a control failed somewhere, but you have to figure out where that happens.

You know, and in this case, the, maybe ITSM didn't pass along the fact that this account should have been terminated and privileges removed from the payment system. So, obviously, this leaves a risk. There's an account, if a malicious actor was able to get in and take control of that account, not even necessarily directly, let's say, by logging in and staying in, but finding this account in the accounts payable system, then they'd be able to approve payments and nobody would even be aware of that.

So, you know, obviously this maps to different kinds of controls and hopefully security policies within every organization, too. If you've got accounts that may not be tied to the master account that a user or a contractor might be using, there's still a lot of risk, and the fact that it's disconnected from other systems, I think, increases the risk. And in this case, you can see that there's a financial risk. It's clear if it's something like an accounts payable system, it may be a little less clear for other kinds of systems.

Chris, what do you think about that? I mean, how would you, how have you tried to quantify the risk for, let's say, CFOs or others who are interested in the numbers?

Yes, I would say normally we look at, you know, once you know you have, you know, some type of compliance gap, the first thing we look at, okay, is it, was it in a financially significant system? Because those are the ones that tend to kind of lead to the biggest compliance risk. And then once we determine that, we then look at, okay, was it a business or IT privilege account that that potential failure was tied to? Because that then obviously raises the blast radius.

And I will say we, most companies do a pretty good job of looking at IT privileged access, you know, from the infrastructure side. But where we still see a decent amount of gaps is actually in business privilege.

So, users that can actually log into the app and have access within the app that you would consider, but, you know, privilege allows them to do things that are pretty impactful to the company from a, you know, expenditure standpoint, etc. So, that's how we typically then narrow down and then we look at, okay, what is the, you know, what is the potential dollar value we can put on that based on that kind of going down that triangle? But then when we look at, okay, who do you blame?

You know, is it IT? Is it business? A lot of just often a lot of finger pointing when you get into this type of scenario.

And, you know, our model is it really business and IT have an implied shared agreement where it's IT and security's responsibility to provide the systems, the platform, the visibility, and kind of put in security and context. And then it's the business's responsibility to understand the data and the users and what that information means in terms of their application and the risks to the enterprise.

Yeah, I think that's very well said. You know, and I think there's a lot, organizational dynamics have a lot to do with that too, because it's not only when things go wrong that you might have business unit pointing to IT saying, well, you know, you should have let us know that there's a problem there. But at the same time, if IT's saying, look, business systems, business units should be responsible, financially responsible for their own business systems.

So, you know, maybe IT says, we don't have the budget to cover you with all the latest and greatest identity management tools, unless you can, you know, contribute to the budget. So, I mean, I've seen it happen on both sides, you know, before an event happens. And then of course, obviously afterwards, trying to figure out who's responsible for it, but certainly being able to produce evidence and solve problems before they become problems would be ideal.

Yep, absolutely. Well, the good news, I think, is, you know, you can have multiple frameworks that you might need to comply with. They might drive your internal security policies, depending on what business you're in and where you are in the world. There's probably regulations that apply and have controls that are required. But you can get a lot of mileage out of controls that span multiple frameworks, multiple regulations and policies. And I think this is maybe a good way to look at how to implement the right controls.

If you sort of synthesize what it is that you need to comply with, what are the specific elements of each of these, and then, you know, build your controls in such a way as to satisfy multiple frameworks, multiple regulations, and hopefully your security policies that align with that. Would you say that auditors accept this system generated evidence at face value, or do they need to see how it was produced? And what are your thoughts on the controls, wanting control to be able to satisfy multiple frameworks?

Yeah, John, I would say, I mean, auditors, they're obviously going to accept the system generated event, events and data, the more that they kind of prove to them that it's reliable, you know, not tamper proof, etc.

So, what we found in general is, it's more of establishing a good relationship with your auditor, so they understand, hey, here's what our business is today, here's where we're going, you know, here are the changes we want to make to try to simplify the workload on the internal audit and IT staff, and kind of just having that more as a partnership, if you will, to say, hey, here are the changes we're making, but do you see any issues with these?

And unfortunately, you know, one auditor may see things a little differently than another auditor, which is why this really requires, you know, your particular relationship with the audit firm you have, but more so than not, they accept that system generated evidence, especially as it continues cycle over cycle. So, for the first time, there may be a little bit more scrutiny on, you know, how do we know the logs weren't tampered with, you know, how do we know that it's all the logs, etc., but as you continue that and mature it over time, that tends to not be scrutinized as heavily.

You know, you said something really interesting there, tamper proof. You know, I think it used to be more theoretical that attackers might get into a system and wipe logs to cover their tracks, but now that's, you know, pretty much their standard operating procedures.

So, making sure that your logs are tamper proof, that you get them in a secure area, you're using methods to keep that pristine, I think is really important. Yep.

Yeah, and another thing I'll add to that is, you know, the auditors are going to, obviously, your system generated evidence is going to say one thing, but they're obviously always going to look at the current state of the data, and again, the more that that system evidence matches the current state of the data, and there's not any drift or gaps, you know, obviously, the more that they trust that over time. Agreed.

So, we've talked about, you know, visibility, intelligence, and action earlier on. Now, we're kind of at the point where we're talking about action and whether or not things should be automatically remediated, and, you know, I think back to, like, on the endpoint side, you know, endpoint security, we have the ability and have had the ability for many years now to detect malware, terminate processes, and even do a full rollback of a node to a known good state.

You know, with things like ITDR, we have similar capabilities on the identity side now, but just like with endpoint, I think that many organizations are still somewhat reticent to allow severe, we'll call them severe consequences when, you know, you do full automated remediation, like cutting off service accounts or, you know, terminating access. I mean, you might be able to get away with terminating a suspicious session, but, I mean, the question here is what should we allow to happen automatically, and what are the things that still should require a human decision?

What are your thoughts on that, Chris? Yeah, I would say this is definitely a crawl, walk, run type evolution.

So, you know, if we look here on the slide, the things that are easy to automate are the ones where we know, hey, we've got evidence that it's an orphan account, it's a dormant account, the credentials are expired, that there are certain things that we know, hey, there's just not really any doubt on what action should be taken. That's on the left end of the spectrum. Automate that, we're really without much concern.

When we get in the middle of the spectrum, you know, where we can actually potentially do things that would affect accounts that are still valid, that that's where we tend to, again, this is kind of in that walk state where we want to do that with some level of approval. It could be automated, you know, we still may decide that some level of human approval here, but again, it's kind of like that audit scenario that the you do that from cycle to cycle and get more confidence, but the further that you shift the line to the right with automation.

And then obviously in the far right, where we know that there's a pretty significant impact to the things we do, that's where we want a lot more, you know, approval, kind of human in the loop type scenarios. And I'll say that this is where you want to make sure you've got a sound backup and recovery strategy, and not just, you know, kind of full recovery, but what we call, you know, specific recovery, where maybe it's not going to have to restore the entire AD domain, but I need the ability to restore a particular account or identity back to a prior state.

We see that that need is a lot more necessary when we get into these automated IEM type things than to, you know, have to do a whole restore back to the whole system. And, you know, unfortunately, anyone who's lived with, you know, any type of enterprise-wide IGA deployment, where you're trying to push the envelope, kind of shift as much as you can to the right, you probably dealt with some type of, you know, blast radius event that required, you know, rolling things back or trying to figure out how to remediate it quickly.

So, I think, you know, again, having a sound, you know, backup recovery foundation in place is critical when you get on the right end of that spectrum. Have you ever seen a case where, let's say, an organization has some automated remediation processes in place, and it's been activated and caused some sort of damage?

And if so, what was the outcome of that? Yes, unfortunately, it's more common than probably any of us would care to admit. And the probably one that I saw within the last year or so was actually the IGA tool went in and updated all of the, and obviously, there's mapping to say, the department and job title, these certain attributes in AD need to be certain values.

Those values weren't, the data was not, you know, looked at maybe as closely as it was on the intake side, and it resulted in, you know, really wiping out a lot of departments that drove downstream application access, you know, based on those department values. And again, in that case, you know, was able to go back and kind of reinstate the prior state of the directory at that point.

But yeah, there's, unfortunately, way more common than probably any of us care to admit. And that's probably why some organizations are a little bit scared of putting these automated remediations in place then. Yeah. Let's see. So where do you think posture management fits in with the tools that we already own? I kind of exaggerated ISPM's spot here and where I think the architecture really is.

I mean, I think things like IGA, PAM, access management, feed into ISPM. But ISPM in a way, in my mind, at least, is part of a lot of ITDR solutions.

I mean, I think you need the ability to understand the posture before you can do the detection and response. So I'm just really curious, where do you think ISPM fits? Do you think it's a good valid category of its own? Or do you think it belongs in ITDR? Or maybe even in different parts of all the tools that we see listed here?

You know, we really see it as its own product category. Going back to the example of being able to see the forest for the trees. Those underlying tools are definitely, I mean, environment. But what we're finding now is this has become more common as a foundation across enterprises and they're dealing with all the activities, events, data that gets generated with these systems.

It revealed the need to really have something that kind of sits above and actually is able to tie posture across all of those different IEM and security domains into something that can actually drive day-to-day activities based on risk. Unfortunately, we see too much that the squeaky wheel gets the attention, you know, whether it's the user that's saying, I need my access yesterday, I'm waiting too long, or the administrator says, I need a full admin account, I can't wait to kind of go through the PAM system.

That a lot of times pulls the focus away from, you know, what are the real risky events? So, if you had an ISCM dashboard that actually showed you, hey, we've got, you know, three authentications on a SOX critical app that happened in the last hour and they didn't have MFA, that's where I'd want to direct my limited staff and funding.

But, enough money to be 100% secure and compliant across all areas, but what we do want to do is make sure we're spending that time and money on the risks that are most important to the organization. So, I think we're obligated to talk about AI agents.

So, what does posture mean when we are considering AI agents? Yeah, this is kind of the talk of the town, so to speak.

And, you know, I use the example, anyone that has kids, you know, once you get over two, you move from the man coverage to zone coverage, parenting. What we found with the agentic AI agents is we can't keep up. They're kind of showing up too fast, replicating too fast, being created kind of all parts of the enterprise.

And so, we really, this almost mandates posture to say, okay, we can't always be ahead of it, but we can have a framework in place that's going to discover it when it happens, looks at the activity, put it in the appropriate governance model where we say, hey, now we know about it, who owns it, you know, what should it be able to do, and actually manage and monitor that, and actually be able to cut it off if those things, you know, are not kept in line. So, to be able to stay on top of the agentic AI explosion.

Yeah, we're seeing sort of proliferation of tools that are directed to AI agent discovery, AI agent governance, you know, we even see categories sort of evolving out of that. It's sort of ISPN for AI agents, especially.

So, definitely a lot of very good work going on this area for the reasons I think you listed, that they're everywhere and increasing. Absolutely.

So, we'll wrap up here and say, you know, what does replace the audit binder? And I think our goal has been to say that there are tools such as ISPN, ITDR, that can not only help facilitate audits, but also help keep on top of your posture and provide you with ways to automate, once you learn to trust the automation, to keep your identity security posture at its tip top. What are your thoughts on this, Chris?

No, I agree. But we definitely have seen that the need for a tool to give you that visibility, intelligence, and automation framework that sits on top of all your different IAM systems, your access management, IGA, PAM, et cetera. It's just a necessity now, and it's really the thing that allows us to move from a, you know, kind of manual audit-based compliance posture in the more continuous automated compliance.

So, we actually think this is going to be the wave of the future here. Agreed. Thank you.

Well, that last poll question, when did you last find an orphan account outside of an audit? About two-thirds say within the last year, and only about 17 percent said within the last month.

So, I think many of us are in the state where it would be good if we had tools like this. You know, going back to our opening example of Dana, the finance contractor, if ISPN had been in place, hopefully it would have been able to uncover the fact that there were dormant accounts out there that could have been cleaned up.

So, we do have some research on this topic. So, here are a few links to that. We did get a couple of questions here. Let me pull that up.

So, the question is, when a material signal changes an identity's or AI agent's risk or operating context, can that signal invalidate or restrict its existing authorization before the next action executes, requiring reauthorization, or is the primary model still detection followed by remediation? Well, I guess my interpretation of that is, unfortunately, we're probably still looking at detection and remediation, but I would think most of our goals would be to ask for that explicit reauthorization before any damage can be done. What's your take on that, Chris?

Yeah, that's actually a great question, and if you look at the authentication authorization chain of a typical agent, especially operating in the context of a human interaction, that last mile where the agent, you know, actually updates a database or calls a service that's taking some action, we can absolutely, again, with the right access management and runtime authorization tools in place, kill that session, require reauthorization that then minimizes, and that typically would require checking out a different ephemeral token before that next action is taken.

So, that's still on the, I'd say, the bleeding edge of, I think, where companies are with their abilities to do that, but I've absolutely seen some modeling with some of our partners in labs, and we're there today. It's just a matter of folks being able to roll it out on a broader basis. And another question there, for AI agents and other NHIs, what should cause a previously valid authorization to become invalid? Identity change, privilege change, context change, control failure, or some combination, and how should that be enforced in real time?

What experiences have you had with that already, Chris? I think that's similar to that last answer I gave.

So, I'd say any and all of those could drive that same cycle where it said, you know, based on that signal, kill the current token that the agent is using for that last mile connection, and cause it to have to re-authenticate, you know, check out a new ephemeral token with that reduced access. And there's a topic that I recommend everybody look at called token exchange, and that's where the human is using an app that they log in, they have, let's say, a federated token.

But then at some point, the agent is kind of taking the reins in the end chain, and so that human token now gets tied into the token that the agent uses for that last mile connection to make the database update, the service call, etc. That whole process, if you've got an access management tool that supports token exchange, with the ability to do ephemeral tokens, this is all well within our ability to execute today. True.

Lenny, any parting thoughts, Chris? You know, I just remind folks that, again, the evolution that we're, the journey we're on is moving from, you know, manual to automated, continuous compliance, and I really urge you to look into ISPM. A lot of the IAM tools are trying to bake ISPM capabilities within their tools. There's also kind of purpose-built ISPM tools that are, you know, that's kind of the whole thing they were built for.

But definitely, you know, look at those types of tools, look at how you can use them to kind of sit above the freight, be signal-based, and let's all get into the top of that maturity curve on automated continuous compliance. Sounds good. I second that.

Well, thanks, everyone, for joining us today, and thanks, Chris, for being here and contributing to this good discussion. Really enjoyed doing this with you. Same here.

Thank you, John. Thanks, everyone, for attending.

So, yeah, please join us for our next one, and have a good rest of your day.