Compliance Unfiltered is TCT’s tell-it-like-it is podcast, dedicated to making compliance suck less. It’s a fresh, raw, uncut alternative for anyone who needs honest, reliable, compliance expertise with a sprinkling of personality.
Show Notes: Identity is the New Perimeter (Zero Trust)
Quick Take
On this week’s Compliance Unfiltered, discover why identity is the new perimeter in cybersecurity. This episode reveals how zero trust principles can protect your systems by continuously verifying user identity and behavior. Learn about the risks of traditional defenses, the evolution of compliance standards, and practical tactics for implementing context-aware verification. Perfect for IT leaders and security professionals ready to strengthen defenses and build a trustworthy digital environment. Listen now to stay ahead of threats.
Read The Transcript
So let’s face it, managing compliance sucks. It’s complicated, it’s hard to keep organized, and it requires a ton of expertise in order to survive the entire process.
Welcome to Compliance Unfiltered, a podcast dedicated to making compliance suck less. Now, here’s your host, Todd Coshow, with Adam Goslin.
Todd Coshow:
Welcome in to another edition of Compliance Unfiltered. I’m Todd Coshow, alongside the free toppings to your compliance froyo, Mr. Adam Goslin. How the heck are you, sir?
Adam Goslin:
I’m doing good, Todd. How about you?
Todd Coshow:
Not bad, sir, not bad at all.
As always, we like to thank the fine listeners of this podcast for their time. If you have suggestions, thoughts, or show ideas, please let us know. Reach out at [email protected].
Today, Adam, we are going to talk about identity as the new perimeter. That’s right, folks. Zero trust is the topic for today.
Now, Adam, if someone logs into your system with the right username and password, do you automatically trust them?
Adam Goslin:
That’s the issue. Most organizations still do, but today, credentials are one of the easy things for attackers to steal or buy. Just having somebody with a valid login doesn’t necessarily mean that it’s a legitimate user.
The bad guys are taking measures to gather up this information in detail, and they’re not necessarily hacking the system, but they’re just going ahead and logging in, if you will.
Todd Coshow:
Sure. We’ve heard for years that the network perimeter is dying. Now the real question is, is it officially dead?
Adam Goslin:
There’s a couple of different ways to look at it. In a practical sense, yeah.
We’ve got cloud. We’ve got software as a service. We’ve got folks doing remote work. Not only just the general sense of remote work, but also, depending on the roles of the individuals involved, part of their job is literally being on the road all the time.
There’s not a notion in particular of what is inside, just because users, devices, data are being interacted with across a broad scope of geographic spread and all that fun stuff. It’s certainly getting more exciting than getting less, if you will.
Todd Coshow:
Fair enough. I guess the next logical question then is: what replaces it?
Adam Goslin:
Identity is now the perimeter. If you can control and identify the identities properly, then you’ve got the capability for securing the access regardless where the user is.
One of the big elements here is, for a lot of organizations, and the ones that are in the security and compliance space have been used to this for a longer period of time, but you see more and more organizations mandating, requiring multiple factors of connectivity. That certainly has gone a long way to being able to make improvements.
But part of the issues come in when, let’s say that you’ve got a username and a password that’s now been breached or shared amongst bad actors, coupled with attacks on multi-factor organizations, etc., it becomes an issue, if you will.
Todd Coshow:
Absolutely. How big of a problem is credential abuse in modern—
Adam Goslin:
It’s one of the biggest elements because the attackers have a cottage industry of scraping data and information from a wide variety of various breaches.
This could be phishing that they’re doing, or from prior breaches, data and information that they’re pooling up on the dark web. The problem is that the bad guys are sharing a lot of information amongst themselves, which makes it more and more difficult for organizations to have a substantial trust factor in the identities that they’re allowing through the door.
It makes things monumentally more complicated. Think about it. When you’ve got attackers that attacked this site, that site, the other site, and they’re pooling all this information, each of your users, individually, has probably been scraped up into several different data sets from various data breaches from the various vendors that they even use individually.
We’ve talked about this before when we were talking about good password hygiene. If I’ve got a user that has a particular pattern, and the target system that the attackers managed to get authentication data out of in the clear, if I now can see this user’s credentials on this platform and the same user’s credentials on this platform, now I’m sitting and comparing the two.
Now, guess what? When that user has used a pattern for putting their stuff together, now I got a pretty good shot at, “Okay, what would the pattern be for system number three or four or five?” Now they can start using that information elsewhere based on the knowledge that they’ve been gaining and sharing from various sources that they’ve got access to.
Todd Coshow:
So it’s not as much that they’re exploiting systems, it’s more they’re using the front door.
Adam Goslin:
I don’t want to say, “No, they’re not exploiting systems,” because they absolutely are. Whenever it becomes known that there’s a new opportunity, a new style of attack, a new vulnerability in a system, yeah, they’re all still using those just like they always have.
But when it comes to the easy button, being able to just leverage them and log in, the biggest problem is that when they do come in using that front door, they look like normal users. It makes detection unbelievably difficult, which is part of the problem.
Where you’ve got passwords and even if you do have MFA involved, like I said before, there’ve been MFA breaches and whatnot included too. It’s not enough to be able to really protect the organization in its entirety.
Todd Coshow:
What does zero trust actually mean in practice?
Adam Goslin:
At the root of it, it’s never trust, always verify. Just because somebody logged in, you don’t, “Okay, that must be Bob,” and close your eyes, put your fingers in your ears, and repeat la, la, la.
What you need to do is continuously validate the user themselves so that you can tell, are they truly supposed to be doing what they’re doing?
Todd Coshow:
So it’s not a product, it’s like a mindset.
Adam Goslin:
Yeah. When it comes down to it, each of the access requests needs to be evaluated based on the ID, the context of the usage of that ID, the relative risk that’s perceived from whatever it is that they’re doing.
You look at it from a security and compliance perspective, that’s an important distinction because regulators more and more are expecting proof that the access is controlled and continuously verified.
They’re looking for that. That’s the direction that they’re heading in terms of the information that they’re seeking out of an organization that is doing a top-notch job of being able to control access to the environment.
Todd Coshow:
What are continuous authentication and context-aware access?
Adam Goslin:
It means that what you’re doing is you’re always validating those users. You’re not just checking them at login and then assuming that all is well.
It’s actually looking at a deeper level, monitoring various points that you’ve got about the user activity. Where are they making this connection from? What location are they in and/or what location are they going to? What device is it that they’re leveraging? Are they coming off of the MAC address of their existing known good asset? Or are they now coming in from some new device that the system has never seen before?
Looking at the user and their behavior as they’re authenticated to the platform, what exactly is it that they’re doing? As an example, I’ve got a user that’s normally in IT and normally in certain locations within the environment or in certain directories within file server, SharePoint, things along those lines. Now, all of a sudden, this user is doing something unusual, heading somewhere where they wouldn’t normally go, etc. Now that can become alert.
What they’re doing, what types of behavior they’re performing within the assets is one. Mirrored or married up to that is activity patterns from the traffic that we’re seeing out of them. That way, if I’m looking at the user, looking at all of these various inputs that are coming in to my authentication system, if something changes, then now I can establish some rules for either tightening or adjusting access or revoking access in real time.
You’re moving into a direction where the access decisions have the capability to be dynamic. If the user is exhibiting what is deemed to be low-risk behaviors in terms of how they’re doing and what they’re doing, then it’s not going to impact their access.
However, if all of a sudden this user moves from what’s perceived by the system to be low-risk behavior into an arena of high-risk behavior, then you can do a couple of different things. You can just flat deny the traffic. You could have increased authentication validation steps that would come into play. It just depends on how you want to configure it.
At the end of the day, it’s really about getting the right level of trust applied to that user behavior at the right time.
To underscore this, I know there’s a lot of folks that will really pitch a fit. There’s nothing that pisses anybody off more than, “Everything was working fine yesterday, and all of a sudden we dial this thing on, and it’s absolutely jacking up my capability to do my job.” There’s little else in this world, especially for the IT crew, that’s going to piss them off more. But done appropriately, done correctly, it definitely should not materially impact the actual usability of the systems. That’s the goal, at least.
Todd Coshow:
Yeah, that makes sense. How does zero trust change compliance? And what’s the risk of not adopting?
Adam Goslin:
I go back to the more prescriptive standards that exist out there. There are these, whatever it may be, 30 to 55 different controls that I’ve got in place, and poof, we’ve got all the right controls dialed in for user access.
But when it comes to the notion of compliance direction, they’re looking to prove out several things: who is it that has access? Why do they have that access? And how exactly are we doing continuous monitoring of this notion?
It’s almost like, I guess the best way I would put it, we’ve had this premise in the security and compliance world for a really long time, the notions of role-based access control, etc., where my person in IT and the things that they need access to is going to be different than the person in accounting, is going to be different than the person in HR.
We’ve had this premise of ensuring that. We also have another premise in the security and compliance arena, which is modifications to access control as you’re provisioning users, as users are leaving the system, whether they left of their own volition or were terminated, etc.
But the one that I’ve seen historically that a lot of companies have typically struggled with is when you have people shifting positions. In today’s day and age, especially where you’ve got a lot of people coming and going, every time that a hole is opened up within the organization, then what do the uppity-ups do? “Let’s move Mary over here and Brian over there and Bob, he’s going to backfill this person.”
That’s really where, even from a traditional sense, the user management struggles. I’ve got this person that used to be in this department, that’s now moving over to this function. There are various struggles with that because that particular user, there may be a transition period. Frank’s going to continue to do his existing function while he’s getting up to speed on this new function, and that transition period is going to go over the course of the next eight weeks or whatever it may be.
That’s really where a lot of the organizations I’ve seen struggle, just how to navigate that temporary period where there’s continued need for the existing access while I need to gather and gain some new access and then actually shutting off the old access. It’s been a challenge, but as you move through this arena, those are some of the historical issues that I’ve seen with the companies going through the security and compliance arena.
Todd Coshow:
Now, is over-permissioning a risk, and what is the biggest mistake companies are still making?
Adam Goslin:
To follow on to what I was just saying, certainly making sure that you are doing the deprovisioning of things no longer needed within a reasonable period of time in a sane fashion, so you’re not screwing up day-by-day operations.
But yeah, certainly over-permissioning is a big problem. One of the nice parts about the notion of zero trust: we talked earlier about monitoring for user behaviors. So let’s go back to this example of we got Frank, who is going to continue doing the existing job while he’s showing somebody else, meanwhile picking up some new responsibilities.
Guess what? Before, I would hope most of the time what happens is they typically just grant the new permissions to the new stuff. They will have a notion that, “By the way, in eight weeks or whatever, we’re going to go ahead and dial off the old permissions because they’ll be no longer needed.” That’s what they say to themselves as they start the process.
However, what typically happens is somebody forgets the reminder to dial off these permissions. For Frank, it is bypassed, ignored, never logged in the first place. When the reminder comes up, then something blows up in that person’s world. They meant to move the reminder, but now it’s just gotten buried under a sea of reminders. There’s a billion reasons why this stuff happens.
But the cool part is that you’ve got the capability once you get into this zero trust arena. Now I can see permissions that the user used to take advantage of that they no longer do. Depending on your capabilities within the configuration of your settings, you could put in various rules, such as if the user hasn’t leveraged their permissions within a 90-day span, then I want to move them into an arena where those doing the monitoring will get an alert if all of a sudden the user goes back to it. That way, I can do some digging.
I could set another thing in, which says if the user hasn’t used these permissions in six months, then I can flip a switch to straight deny it, and I’ve got to come and explain why they need these again. You’ve got all sorts of choices about what you go in and do.
You definitely want to make sure that you’re locking it down as best you can. I can tell you that that approach is a balancing act. You go down this path. One of the big arenas where I’ve seen users go ballistic is when somebody that’s in the IT or authentication arena starts getting overly aggressive with the lockdowns. Now, all of a sudden, I need to be able to get to this, but now I can’t. I’ve got to go ask mommy may I to be able to get back in there, etc. It really is something that will absolutely fundamentally cheese off the users.
So it’s a balancing act. You want to get it dialed in, dialed down, and locked down as best you can from the perspective of trying to protect the organization. But in dialing that way up, you’re also running the risk that you are dialing it up too much, that you’re not allowing users access to things that they, in all reality, need just in order to do their job.
The other thing that I was thinking about as I was talking this through with you is that there will be certain systems that only require periodic access. Yes, I absolutely need this access, but I only need it once a year, every year and a half, whatever it may be. There’s a lot that needs to go into the consideration bucket of the approach.
I would take it slow. But when you’re going through and you’ve got a continuous stream of validation and whatnot, then you’ve got a much better capability to be able to help protect the organization.
One of the biggest problems is if you just flat give people more access than they need, what easier way can we give the bad actor the capability to get to stuff that they shouldn’t? That’s probably an easier way for folks to go in and look at it, if you will.
Todd Coshow:
Parting shots and thoughts for the folks this week, Adam.
Adam Goslin:
Identity isn’t proof of trust. It’s a starting point.
It is good to move into this arena where trust is earned. We were talking about trying not to piss the users off, etc. My suggestion would certainly be when I go in and try to roll out systems like this, I will always start with the gearheads and the folks in the IT arena. That way, it’s real easy for them to go over, talk to the administrator, “Hey, I’m having this problem,” and you work out the kinks.
Go in and get the kinks worked out with a subset of IT. When I would do that, I would do it across a number of different roles within the IT arena. Get devs, get IT managers, get database folks, get network administrators, and all the way down to the day-by-day PC support and things along those lines. Grab people from each of the various factions and do it with a subset testing pool of users.
That way, as you’re running into walls, you’re doing the experimentation on the IT group. Once you get through that, and not to say that testing will reveal a lot in terms of getting it dialed in and giving you a sense of when you’re ready to move on, grab a subset of users that you fold into this arena, but do it across number one, depending on the size of the organization, but ultimately rolling out your testing against maybe department by department.
Pick singular individuals within the department to become part of the beta testing pool. Grab people, I’m just going to use accounting, grab one person in each of the roles within accounting. Let that run in a testing mode for a little bit, then roll that out to the rest of accounting, then move to the next department.
If you’re a small to mid-sized organization, maybe we just grab representatives from each of the roles within all the departments and do that as the testing pool, and then do the rollout to the remainder of the organization.
It’s going to be different for different organizations, but take it slow. Don’t rush into it because I’m telling you, you go dial up the pain factor to 11, you’re going to end up with a group of people with flaming torches and pitchforks coming to whoever did that to them’s desk, that’s for sure.
Todd Coshow:
That’s all the time we have for this episode of Compliance Unfiltered. I’m Todd Coshow.
Adam Goslin:
And I’m Adam Goslin.
Todd Coshow:
Hope we helped to get you fired up to make your compliance suck less.
