When Programs Go Rogue: Identity Sprawl in the Grid

Hi, I'm Nick Newell, founder of Rival IT here in Charlotte, North Carolina. And a lot of the work that we do is centered around helping organizations modernize identity and moving from legacy domain environments into centralized identity models, improving authentication, and tightening controls across users, devices, and applications. But before I get into the content, I want to frame how I think about talks like this. When I was early in my career, you know, the places I worked would often send me to conferences, you know, like Defcon or Bides or, you know, others and to try to get a feel for what's happening in the industry, kind of what's going on. And I I really had this kind of idea of how can I provide

value back to my employer. They're paying money to send me here. They, you know, allowed me to be off of work, you know, to attend this conference usually. How can I make sure that they're getting some some value from this experience? So, I always had this idea, what can I bring back? What is like one thing if I if I attend a whole conference even if it's multi-day what is the one thing that I can bring back that's going to actually move the needle something that we can actually do so in 2023 I was at Defcon and I think it was early in the morning I go to this talk and uh this gentleman had done some

really impressive work he was giving this deeply deeply technical talk on an Alexa device that they had reversed engineered, you know, down to the kernel level. He explained, you know, everything he was able to do, manipulate behavior, bypass controls, just incredible stuff. And it was great and interesting, but that wasn't really applicable to my world, right, as a cyber security person or CIS admin. There was nothing that I could do with that information. I couldn't really take that back and apply it to our clients. I couldn't apply it even to our own business. There wasn't anything that I could be doing differently other than saying, "Wow, that was amazing." So that's what this talk is about,

right? Not something flashy, something practical, something you can take back and actually do. The one thing I'd argue that makes the biggest difference in modern environments is this. Whether or not you actually control identity, because identity is where control exists. or it doesn't. So, let's jump in here. When we talk about security incidents, we focus on the moment something goes wrong. It's the fishing event. It's the malware infection. It's ransomware. But these are just symptoms. They're the visible part of this. The failure usually starts much much earlier where control actually breaks down. And identity is one of the first places that happens. That's why I like asking the question, if a user is terminated or

leaves the business on Friday, what still works on Monday? And the reason that question is powerful is because it exposes gaps very quickly. In a lot of environments, the domain access is disabled, let's say. But did we disable all the SAS apps? What about the VPN? What about any local accounts? Right? I know in environments of, you know, implemented domains that used to be all work groups or local accounts, there could still be even user level local accounts sitting around, right? What about that MFA that's not enforced? Uh, and or maybe it's enforced in one place and not another. And what's interesting is thinking about this kind of sprawl is that none of these systems are necessarily broken.

They're just not coordinated. And that's the problem. Identity isn't centralized, so the policy isn't consistent. And once policy isn't consistent, control is already gone, even if everything looks fine on the surface. So what does identity spraw look like? And you know, we've seen this kind of over and over, but I want to emphasize that this this isn't chaos. It's accumulated complexity. No one sets out in their IT career to say let's make this let's design this in a way that's not going to work or be very complex or be very laborious to support it just kind of happens right as we know these things kind of just get layered on over time maybe you start with active

directory and then maybe another domain gets added maybe there's an acquisition or your business gets acquired and you know maybe software as a service, you know, gets introduced, right? And some of those apps are integrated in the ecosystem and some are not. You've got those local admin accounts, you know, that still kind of hang around, right, on user machines or we forget to disable them or we use it that one time to support this one user and we have no check and balance to whether that account is still active or not. Service accounts, right? That was always the worst for us is like we build these kind of service accounts and then eight, nine, 10, 12 years later, right? What

was that for again? Who's using that? And they're just all over the place, right? And at one point they had a purpose and now we're not really so sure what's going on with those. Um VPN access is another one that kind of evolves separately. uh cloud identity right gets added on top of all this and then the bricks just start start getting stacked one on top of the other you know where authentication happens starts being in all these different places so what you end up with is not one identity system but many many many overlapping ones each one has different rules each one has different policies different visibility and you're starting to see that's where control is starting

to fragment in the environment. So let's see some more real world examples of this. Right? These are some patterns that we often see. We walk into an environment and let's say the organization believes they have a really solid offboarding process. Right? They disable the account in Active Directory and from their perspective that user on Friday is gone on Monday. We're safe. You know, we disabled their AD account. We're good to go here. But you start peeling back the onion, you start looking a little deeper, we find that that same user still has access to multiple SAS apps, right? Those applications were never tied into any type of central identity or management. So, it's hard to know. Did

they have access to QuickBooks? Did they have access to, you know, Salesforce? Did they have access to this CRM? Nobody knows, right? Things get messy over time. you know, they were set up independently. A lot of these apps we see in larger organizations, there's very little control or restriction, especially on SAS apps. So, a department may have a company credit card and they just buy an app like a monday.com to use for projects or Trello or whatever the case may be. And sometimes it doesn't even know it exists, that it's even there. So, how can we offboard a product that no one even knows is there, right? So, we've seen this before where users still have access to a CRM system with

all the company data in it after supposedly getting offboarded. We've seen they still have access to internal admin dashboards with financial metrics. We've seen access to file sharing platforms like share sync and or share file all these things, right? and nobody realized it and that was the key issue from a process perspective to the business. Everything was done correctly. They they thought that they had it under control. We disabled the domain account or we disabled the primary access. We turned their email off. We're all good here. But access still exists. And that's where the gap in this risk lives right in that kind of gray area. The organization believe that access is removed but it isn't and

that's identity sprawl. It's not about missing controls. It's about disconnected controls. So legacy identity systems weren't built wrong. I know what you're thinking. It's like why would anybody have anything set up like that? Well, the world was different like 10 years ago, right? Earlier in my career, it's funny. I would go to these conferences when I was young and you know the person talking is like well back in my day we did this thing like this and it's like well I'm that guy now right because back in the day right everyone went to an office and they were behind a firewall they all authenticated to an on-prim domain and things were easy we deployed all the

applications to users directly there was no SAS right like we knew everything that was on the network the network was trusted all the devices stayed behind that firewall and connected to AD with all of our policies and group policies and life was good. But that's that's not the world we live in today, right? The world's changed. Users are remote environments are hybrid. Most applications, you know, live in the cloud. People take devices everywhere. Most access happens over the internet. Now very rarely is a business functioning fully in office these days. So the environment has invol evolved but identity often didn't evolve at the same pace and that's where this mismatch starts happening where identity systems

are still operating on assumptions that no longer exist. This is that fragmentation. And since we're at a cyber security conference, if you look at this from the uh malicious actors perspective, identity sprawl is incredibly valuable to them, right? It creates options. If identity is centralized, there's one control point. If it's fragmented, these these attackers get to choose wherever they want to enter, right? It's pretty easy to figure out what apps the business is using. It's not that hard, right? and they have kind of their pick to choose the the path of least resistance. They can find out if MFA is inconsistent. They can find out if credentials are reused. They capture credentials for one app. If there's no

centralized identity, maybe users are reusing credentials, right? We all know that happens. They can test them everywhere. It's very easy to do. If uh users happen to have multiple identities, they'll try them all, right? They can get their hands on them. And this identity sprawl creates privilege escalation opportunities that I'm describing here because access isn't always visible or consistent across all these systems. So from an IT perspective or an operations perspective, an account that may look low risk in one system may have elevated access somewhere else, right? And detection becomes harder. Authentication logs across these systems are scattered. Different formats, different visibility, different tools. You know, even with Seam or some of these log aggregation tools, it's still

difficult to get all this in one place. So instead of one clear signal, you're getting fragmented visibility and that's going to slow down response. That's going to increase the dwell time for these malicious actors. We might not even know an account is ever compromised, right? We see that happen all the time with these breaches. So identity has become such a critical control plane in businesses and enterprises today because if the identity is fragmented, everything else becomes reactive instead of preventative. So hopefully I've uh thoroughly scared everyone, right? and they're thinking about how their identity is managed where they work or their business and uh you're asking like how do I Nick how do I get a how do I get a hold of this

right like how do I how do I get in front of it and I'll say the solution isn't just moving identity to a cloud or to a place right it's it's more about centralizing control and what that means to me is one authoritative identity source that means SSO across applications. It means M MFA as a baseline. It means deviceaware access policies, conditional access policies, centralized logging. And in many environments, this is something like intra ID. Maybe that fits the bill for your environment or maybe it's octa or maybe it's something else. Right? The key idea is the pattern matters much more than the product, right? You're not just changing how users log in. You're not just changing how they authenticate.

You're changing where control lives, where policy lives, where visibility lives. That's the important piece here. So now we're talking about how do we get into modernizing these environments? what does this actually look like? You know, where do you start? Uh I think this is where a lot of these identity projects go wrong in our experience because people think of this like a like a synchronous project. They think we'll connect Active Directory to the cloud and we're done, right? But that doesn't fix the problem. The problem isn't where the identity exists. It's where control exists. And I know you guys are probably tired of hearing me say control, but that's the key theme here. And speaking of control, when we're

moving to modernize our environment, if you don't clean up users and access first, right, you're just going to migrate complexity. If you don't centralize authentication, you're just adding more and more layers. If you enable SSO without the right policies, you improve convenience, not security. So, in our experience, the right approach here is inventory first. Make a plan. Understand the landscape intimately and know what you're up against, right? Where does the identity live? Figure that out. Make a plan and then start cleaning it cleaning it up after that. So then we look to establish a primary identity platform. See the platform doesn't matter right like a lot of people start there they see oh I got

octa or intro they kind of start with the platform it begins way before that right but once you have a platform in mind start bringing the applications under that control then reduce the legacy authentication and this is not a migration right I'm going to say the word again it's a shift in control this is the mindset that we need to have. How can we have control? So when you start doing something like this, what are all the bad things that happen? Right? We've seen it all. So this is where the uncomfortable part of this starts and a lot of these identity projects can kind of fall flat on their face because when you start trying to

centralize identity, you start revealing problems in the environment. I'm going to list a few here that we've seen. We've seen legacy applications that don't support modern authentication. Yes, they're out there. They're out there all over the place, right? If you work in a legacy type business, especially like manufacturing or even healthcare, you see a lot of this, right? You see those service accounts that nobody wants to touch, right? you that account had been running for the last 15 years and Mike that was here before the last guy that was here before the last guy was here says that you know it was doing this and nobody wants to touch it because it's this critical account that's in production we leave it

alone right we're going to have to learn the hard way what that account does if we're moving to this strategy another thing that pops up that seems silly but it happens all the time is MFA exceptions especially from leaders like why am I get these MFA popups. It's annoying. Why do I have to log in every 24 hours? Why do I keep having to reauthenticate? What is all this? Right? I'm just trying to get work done and they're not fully bought in to the process. Right? Conditional access breaking workflows. Man, I have I have done that a few times myself. Right? You build what you think is a condition perfect conditional access policy only to flip it on and you know kind of do

the screen test, right? everything breaks. We've seen apps that only work with legacy authentication, hybrid devices with trust issues. Um, you can see that this is where identity work becomes less technical and more operational, right? That that's when you when you think about implementation, that's really what we're talking about. And for anyone that's ever worked closely with me, a lot of people get annoyed when I say this, especially engineers. The technical part of anything in it is the easy part. And I I hate to be the one to tell you that, but it is. Especially speaking to a group of technical folks, the technical, the engineering is easy. Operations and doing business are hard. Right? And what

I mean by that is this identity project is not how do I design or engineer the perfect system. How do I get how do I get buyin from the business that this needs to be done. How do I get the executive team on board to understand how important these security policies are and not just to check a box or to fill in a compliance form for their cyber security insurance or whatever the case may be. How do they understand that this could really affect their business and their money, right, and their reputation in the business community and get that executive sponsorship? They need to understand risk tolerance, right? And I've I've described this before in this way. It's like think of a

slide scale, right? You have maximum security all the way over to the right and you have super convenience all the way over to the left. And our job as cyber security professionals, right, our consultants is to work with a business and let them understand the risk, right? On both ways. We can go super secure and make it so no one can do any work ever, but hey, you're never going to get breached, right? That's great. But they're not going to be able to make money either, which is the primary function of the of the business or the corporation or the client in this case. Or the other extreme, right? we go, hey, everything's super easy and convenient,

but it's not secure at all. Everybody has full admin permissions to everything and everybody can share whatever they want. And that's not going to work either. So often our job is to balance this kind of uh a system of being the consultant, being the engineer, and understanding the business that we're making these recommendations for. So that slide scale we have to make it fit in a place that they're willing to accept the risk of tolerance and they understand what the implications are that for this right the business impact they understand that this is where decisions have to be made what level of risk are they willing to accept what are they willing to fix what are they

willing to change and I'll say doing this a long time it's not always everything that you want them to fix that doesn't always happen unfortunately right unless it's your company uh you don't always get the most secure solution or the best right it usually lands somewhere in between and this isn't because you know all these problems isn't because the technology is difficult as I described I think the technology is the easy part here it's because it forces alignment and it's forcing people to make decisions about business operations the practical roll out here the biggest mistake is trying to do everything at once, right? This is where projects fail. A better approach is phased, right? And I I found success with doing

like privilege identities first. Start looking there, then thinking about critical applications and then think about the broader SAS apps and things like that, endpoints, and then start tracking your exceptions. Exceptions are how identity sprawl quietly kind of creeps back in. So be careful with those, right? They can stack up pretty quick. And you're not going to eliminate everything at once. You're not going to solve the world's problems here, right? You're not going to be Pepe Sylvia from my always sunny meme, but it's a continuous process, right? You manage it continuously. So incident response, right? One of the benefits here of centralized identity is if um you know where logs and systems are, you don't have to chase these

across systems if there's ever a problem. If you have central identity, the privilege class are clear. Uh you can disable accounts instantly. You can kill SAS sessions globally. You can see authentication activity in one place. And this turns a distributed problem into a centralized one. And that alone can dramatically reduce response times for incidents, right? If you have one place to look instead of 37. And all of this works, security becomes simpler, right? You have one login model. You have consistent MFA. You have faster onboarding. You have faster offboarding. You have clear control. I said the C word again, control. And that is my favorite way to describe it. Security gets simpler when identity gets boring

because boring means predictable and predictable means controllable. And key takeaways here. I want to kind of circle us back to how we started this talk. When I used to go to conferences, I was looking for the one thing I could take back and apply. Something practical, something that could actually improve how we operate or move the needle for my clients. If there's one thing I'd leave you with is this. If you don't control identity, you don't control your environment. And if you centralize identity, everything else gets easier. It gets simpler. It gets more predictable. It gets boring. And that's actually the goal. I really appreciate everyone's time. Again, I'm I'm Nick Newell from Rival it

here in Charlotte. Feel free to reach out on X or send us an email uh rival IT onx nicholas a new uh hello rivalit.ai. Give us a shout. I'd love to chat.