Radio LogicReducing the Identity Attack Surface

Anders Askasen: Welcome to Radio Logic, the monthly podcast where we break down identity into something that you can take away and actually use within your enterprise. Today, I’m joined by Tom from FSP. Tom, welcome to the podcast.

Tom Hebbron: Thanks for having me.

Anders Askasen: Tell me a little bit about who Tom is and who’s FSP?

Tom Hebbron: So let’s start with FSP. We are a digital transformation, cloud engineering, data and AI and cybersecurity firm based here in the UK, but we’ve now got branches all over the world.

Growing really fast, lots of acquisition. Last two, recently last year, Intuitar, which was a data and AI firm, and Hoop Cyber, which does a lot in the AWS ecosystem and, you know, that sort of data logging. So really sort of, you know, lots of focus on security data, what we do with it, making intelligent decisions with it.

Anders Askasen: And there’s no secret. And just for full disclosure, you’re a partner of Radiant Logic, so we work closely together with customers. And and the main field there is always the identity. And the way that we see identity is is, at least from Radiant Logic’s point of view, we see identity moving more and more into or closer to security, and and that rhymes well with with what you guys are doing.

Tom Hebbron: Absolutely. So at FSP, I lead the identity and security architecture practice. In a previous life, I’ve been a customer of Radiant Logic when we were at Refinitiv and then becoming part of London Stock Exchange.

Think really saw the benefits there of using that kind of virtualisation, of bringing the data into one place and just being able to use it, slice and dice it whilst organisations are going through those sort of big changes and having to see people through different lenses.

Anders Askasen: I’ve been in this space for twenty five plus years and and one thing that always strikes me is that it feels like we’re sometimes battling the same type of problems over and over again. The flavor changes slightly, but it’s still the same drink, if that makes sense.

A lot of the customers that we’ve been dealing with, they have a built up, you know, legacy depth of of old technology. It’s just difficult to get rid of that. Is that is that how you see your clients also?

Tom Hebbron: Yeah. Definitely. You know, there’s there’s lots of factors that mean you end up with identity data and things that would be really useful if you could just make good use of it, siloed all over the place. You know, there’s things like applications where there’s only five users in the business so you don’t pay the SSO tax.

It’s extremely frustrating. The user experience is worse and the governance of managing that silo just becomes much more difficult. But when you take little incidents like that multiply them out, you can see why we end up in this kind of identity data debt. And and it just makes governance and the user experience, you know, worse and and more difficult.

Anders Askasen: And I guess that’s the first part that you look at as a consultant when you try to guide and and steer and help customers to get some kind of sense and maturity of of this type of landscape is to reel everything in and to create that unified layer of identity data. Is that right?

Tom Hebbron: Yeah. Mean, it’s it’s it’s kind of boring, isn’t it? Banging the old drum. But if you if you don’t know what you’ve got, can’t protect it.

You can’t secure it. You can’t make it better. So it comes down to kind of asset management, doesn’t it? But if you, you know, if you can bring the data into one place, you can start to look at the risks, you can start to manage that down, track it over time.

I think we’ve had some really interesting conversations with organisations of all shapes and sizes, different industries over the years. They’re doing good things around data management, Good master data management looking at financial data, medical data and the benefits of doing the same things that we talk about in identity data, bringing it into one place, cleaning it up, de duplicating it, making sure it’s available to different people with good governance models around it so people don’t shadow data and do their own thing.

So all of those good positive traits around data management certainly we can apply to identity data as well.

I think what’s interesting in the identity and security space is thinking about the different speeds at which we need to do things with that data. So sometimes an access decision needs to be made right at the edge when something bad happens on an endpoint. Sometimes it’s months later it’s forensics. You know, we need to look at it and go, what what went wrong there? And can we learn lessons from it so it doesn’t happen again?

Anders Askasen: And and to that point of lessons learned, I mean, we see every year several reports comes out from Verizon with their breach report and from IBM and other players. And they’re they’re interesting reading, but they all send the same signals that identity is is the cause of a lot of these problems. Typically, it starts with some kind of trigger that is social engineering, but ultimately there’s the identity that is being at the culprit of everything, right?

Tom Hebbron: Yeah, it’s kind of a difficult position, isn’t it? When the area that you are helping clients with is always the number one sort of category in these reports and why haven’t we fixed it yet. I guess the reason we haven’t fixed it yet is because it’s a wicked problem. It gets harder all the time.

And talking about that sort of identity debt, do we mean? Why is it not fixed? So I think over the last couple of decades we’ve made some real improvements in security and in the sort of the usability of what we now call sort of identity security tool sets and controls. So if you think about ten, fifteen, twenty years ago people having hundreds of different usernames and passwords and writing things moving to more centralised authentication, so single sign on and then securing that using things like MFA so we can stop some of those attack paths.

We’ve made some real improvements and I think even MFA which was maybe not always the most user friendly thing, the constant pop ups hundreds of times a day, even that’s getting better and we’re more context aware when we use things like MFA and using the intelligence we’ve got about what’s going on in the environment, not to pester the user if we don’t need to.

Anders Askasen: Do you have a pattern where you when you go in and advise clients, they they have some kind of identity project that they wanna embark on? And and where do you start?

And how do you progress? How do you make sure that that project actually succeed? Because in my experience, a lot of these projects have a tendency of failing. You you scope it incorrectly. You focus your attention on the wrong things. And at some point, it just it becomes that never ending project that doesn’t deliver the value that it was set out to do. What do you say to clients when you scope projects?

Tom Hebbron: I think, yeah, I mean, it depends why you’re coming in and where you’re starting. But again, having that inventory, having that asset database, whether it exists or whether it’s something you have to start creating or at least labeling something you already have and being able to track that over time so you can see, here’s what we have, here are the risks. It’s not going be a complete picture. I think we’ve had this discussion internally so many times about how do you start projects when everything is not perfect. Well it never will be perfect, you’ll never get there. So you have to start with the data, the systems that you’ve got and start to prioritise risks. So with what we’ve got we can’t know everything.

If you think about a bunch of accounts, whether that’s humans or machines, what do we know about them? And if that inventory of accounts and so on is incomplete, well the fact that it’s incomplete is itself a risk. So we can start to look at how do we get better insights into what these accounts are, how they’re behaving. You might not always have the tooling for that or the data but you can start to track that as a risk itself.

The other thing is a lot of these operational technologies like directories and so on that we’ve been living with for years, they are operational technologies. They are in the moment. They don’t always have that good audit trail and ability to go and look back and understand how we’ve improved over time. So again being able to capture that data and look at it over time and show improvements and understand where changes perhaps haven’t materialized, improvements that you were hoping for is really important.

So, yeah, it’s

Anders Askasen: But it sounds like you have a pattern that Yeah.

Tom Hebbron: Yeah.

It’s it’s data gathering.

Anders Askasen: Start with the data, make sure that that’s under control, Clean it up. And and once you have done that, that’s where you can start evolving that that program. And and that’s where you start seeing some of the benefits as well. And it to me, when you explain this, it kinda rhymes with the big security frameworks where you need to have that inventory of, you know, devices, servers, machines, network equipment, etcetera. Same thing applies to identity, doesn’t it?

Tom Hebbron: Yeah. Absolutely. It doesn’t matter which framework you’re using. You’ll find a control in there that says build inventory and look at privileged accounts or look at standard accounts, look at is MFA deployed everywhere. There’s always that step of know what you’ve got and then start to apply the controls in a risk prioritised way to it. Which is really hard when you don’t have the inventory or when you’re going back to an auditor or a regulator and saying well we’ve got one hundred percent of our accounts with MFA enabled’ then they come in with a pen test.

Anders Askasen: Is that the case though that reach one hundred?

Tom Hebbron: Well, no one ever reaches one hundred percent, but the problem is we start to gain the stats, right? So you say, well, one hundred percent on these systems in scope, but all of those systems that you know, there’s five people in marketing use our system. It’s too small. We didn’t pay the SSO tax.

So we don’t know if it’s got MFA or not. We don’t know if the people that had access to it that left last year have still got access because we have no insight to what’s going on in that silo. So it’s a back to that identity deck. We will try and do the right thing really hard when you don’t have visibility and that observability of what’s going on across the whole estate.

Anders Askasen: But tell me, Tom, why are we still stuffing around with these old legacy systems that, you know, they’re difficult to integrate with, They have proprietary protocols and they’re just a nightmare to integrate into a modern solution. Why are we still having that same problem?

Tom Hebbron: I think all organizations have legacy. Think if you go in to help an organization and with an expectation that we’re going to do greenfield, and it does happen, we do have those rare gems where we start, you know, real greenfield, everything’s brand new, cloud based, but they’re pretty rare. Most organisations, especially ones with interesting, chewy technical identity.

Anders Askasen: The complex environments, if you will.

Tom Hebbron: Exactly, yeah. You know, they have that legacy. And I think if you pretend that they don’t and just say, well, you know, we’re only going to work with this stuff, we’re going to put the scope around the new things because we know how to fix that and the tools work with it.

You just you can’t ignore the legacy. You know, that might be the systems that are running on extended support and not getting patched. And if they get breached, need to be able to contain that blast radius and make sure that, you know, the the access from that doesn’t spread to other systems.

So you really need to make sure that your strategy and then your tooling is able to cope with the legacy systems that may talk old protocols, may not integrate very well. Because if you leave them behind, you know, you’re accumulating more debt.

Anders Askasen: Right? But how much is tooling versus strategy? I mean, the the the tooling can solve so much and Yeah. And and the processes and the people, they obviously need to adapt to that as well and there needs to be a long term vision of where do we want to be, right?

Tom Hebbron: Yeah and I think we always talk about this, know, even the best technologies and we work with lots of vendors and some great technologies, even the best don’t do everything that the marketing teams say or that the client really needs them to do. So there’s always that process of taking the tooling that’s the best fit for the client problem and making it work to actually solve the problem. So that involves a lot of glue and putting good process around it, good governance. Again, this is one of those areas where the data and the observability is critical because you can see the gaps where the tooling doesn’t work or where there’s that silo of users who aren’t included. So we can at least see the risk and manage it in other ways. I think if you just ignore it and focus on just, you know, the technology that works well together, we end up leaving a lot of people out in the cold and that’s where risk breeds.

Anders Askasen: And, obviously, Radiant Logic is an identity data company ultimately where we we do exactly what you’re saying. We’re unifying all these different identity silos across all different types of identities. And and today, we have, you know, we have human identities, which is a problem that I believe we have solved and then we have some patterns on how to tackle it. But then we have machine identities and we have the the emerging category of agentic AI identities with with whole different set of problems and that ephemeral nature of of just in time access that is needed, etcetera.

But being able to unify that and getting those controls, which rhymes well with the security frameworks, right, that always stipulate that you need to know what what’s out there in order to control and see and secure and protect it. And then once you have that, that’s where I think, and to your point, you can mature your identity program and add that observability layer where the if there is a nominee, if there is some kind of breach of trust and and and things starts happening, you need to have that insight into what’s going on in real time. Not only these static point in time, you know, here here’s October first, and this is how the access looked at at that time, which serves well for the auditor.

But from a security point of view, it doesn’t really you you need something that’s faster, more agile than that. And once you have that observability layer, then you can make decisive actions and act on that data and and, you know, shut access down instantly or send a signal to to other security vendors like Okta or CrowdStrike, what have you, to do something decisive.

Tom Hebbron: Yeah. I mean, that that that you know, the context is king. Right? You you can’t make good decisions with very stale data.

And I think, you know, going back to why we built up this identity debt is a lot of the data that we relied on, even when we had good processes which were at the limits of what was acceptable organisationally, technologically to put in place, an annual recertification, is fine. But when we look at that in reality, what actually happens is it happens once a year. So at best it’s this week. At worst it’s eleven and a half months old.

And also once you’ve done it once, the tendency is for line managers, system owners and so on not to stop the bus is to say yes, they still need it.

So again, we’re really good at giving access out because we want to give people agency to do the things that are economically valuable in that business. Very bad at taking it back again.

Anders Askasen: Is is there a is there a mechanism to do that? Because, I mean, if we’re talking about least privilege, which is popular within zero trust philosophy, and and that seems to be the way for the future to actually be able to secure some of these different identity problems, is there a pattern on how to reach that?

Is there something that you want to pass to the There

Tom Hebbron: is and I’m going get the terminology wrong.

So for the biologists tuning in, nature, where anything, any sort of anabolic, builds up and catabolic breaks down. So most processes are pretty good at self recycling. We are really bad at building processes that give access out and there is no kind of termination date or criteria for when that gets taken back again. So naturally, and this has been written out a lot in the last few years, you you just run that process and naturally access stacks up.

What we need to do as a real fundamental principle is almost no access is given out without an end criteria. So at some point, we know it’s going to be recycled and taken away. And whether that’s just in time and it lasts for an hour or context dependent, when you shift context, it’s taken away.

You’ve got to have that, you know, there always has to be an endpoint in criteria.

Anders Askasen: Where do you see that responsibility falls? Is that, you know, I represent a vendor or you represent system integrator or the customer? Where does that responsibility sit? Who’s gonna who’s gonna be most successful in in actually putting this out there?

Tom Hebbron: It’s it’s a huge it’s a combination of efforts, isn’t it? Because I think you can’t take access away when it’s hard for people to get the access in the first place because you’re adding friction so the business won’t tolerate it.

And system owners and so on, if you don’t make it easy to administer this and make it easy for a user to get the access, it should almost be friction free, right? The context and the business purpose of what am I doing, what am I supposed to be doing, what are the bounds of the resources and assets that I can use to do that.

If you’ve got that data in context, you can make smart decisions without necessarily needing a human in the loop to go and say, absolutely can have that group to share to that Is as

Anders Askasen: as simple as you have no privileges, no birthrights, and when you request access, that is always time predicated.

So you’ll you’ll have that access for a certain amount of time, and then it automatically, you know, gets removed. Is is that the solution?

Tom Hebbron: Yeah. And I think we we we’ve of been there in the best cases for a while, haven’t we? So where single sign on works really well is there’s a lever event and that lever event cuts your account and that cuts access to everything. But as we’ve sort of moved to that patchwork quilt of SaaS apps and things that didn’t quite integrate with single sign on, that’s where you end up with these silos at risk where that that end event doesn’t happen.

Equally, as attackers have started to use access and so on as the way that they move around the the network, steal your resources, cause economic damage, benefit to themselves.

That access is there as a birthright that lasts forever isn’t appropriate anymore. We need to dish it out, take it back and, you know, it shouldn’t be static access. It should be, again, it’s back to the context. It’s fine for me to be doing something in the finance system if I’m a finance manager at two o’clock on the first of the month closing the last month off, but if I’m doing it from an unknown location at three o’clock in the morning, that’s weird.

Anders Askasen: So it sounds like a little bit like you’re in in that paradigm shift between operational problems versus security, and they don’t necessarily solve the same or address the same things the same way and that we need to think more about security. So if if we’re if we’re wrapping up our conversation and and and we kinda wanna, you know, face the audience and and give them some kind of recommendation on how to address the problem and how to go forward with this, what would you say?

Tom Hebbron: So I think one of the things we’ve talked about is that sort of security identity data debt. I think one of the worst cases that we see is people who’ve got the scars from doing like a big RBAC project. So they tried to define birthright and kind of ahead of time what this job role should do and therefore what it needs access to do throughout its lifetime. And we know what happened.

Without an awful lot of maintenance, they proliferate and we create new roles for this new roles for that and new roles for the project and people end up with very composite roles but you end up with more roles than people and that’s just not manageable. Again it’s because that static role that says this for this isn’t taking into account any of that sort of dynamic context that’s needed. So I think role based approaches may be for some of your true static entitlements like you have a Microsoft Office license for your entire duration because it’s needed to do everything else.

But for most things thinking about what’s the business purpose and can we do that in a dynamic and policy driven way so we know that if you are having access to something, it’s within that remit but we don’t have to specify it so granularly. And of course you need the tools that are able to take that information and make those smart decisions that has that balance between is this risky and does this enable the user to do what they need to do.

Anders Askasen: Tom, thanks for bringing your wisdom to the podcast and thanks for joining.

As we can tell, Tom has battle scars from doing complicated RBAC projects where defining roles have led into a big explosion. And I think we all listening to this podcast can appreciate the problem with that. And with that, we thank Tom for his insights and over and out.