Transforming Your Identity Management

Transforming Your Identity Management

March 26, 2024 | Code Comments Team

Automation and management

Partners

Professional development

Code Comments • • Transforming Your Identity Management | Code Comments

Transforming Your Identity Management | Code Comments

About the episode

Modern IT systems have a lot of components—components people have to use, and components who need to talk to each other. That’s a lot of traffic and exchanging of sensitive information. How do you sort the legitimate users from the potential intruders?

Niels Van Bennekom shares how CyberArk helps organizations set up identity management systems that can keep up with expansive, ever-changing IT systems.

Code Comments Team Red Hat original show

Subscribe here:

Transcript

Digital transformation, it can mean so many things that it's hard to pin down. IT modernization, moving to the cloud, adopting an agile workflow, all of these apply. But not every one of those applies to every company's journey. That can make it hard to understand the what, the why, and the how. And more importantly, it makes it hard to prepare for the secondary considerations these transformations need.

Welcome to Season 3 of Code Comments. We're investigating the promise of digital transformation and talking through the less considered aspects of the process. When it comes to IT modernization, there are many more moving parts to keep track of than with traditional infrastructure, literally. Cloud deployments, containerized environments, and all the microservices add up to a whole slew of components to manage. And because they're all interconnected and hosted in the cloud, they increase the potential avenues for nefarious intrusion.

In this episode, Product Manager Niels van Bennekom of CyberArk walks us through the importance of identity management and how, without a proper plan, things can quickly get out of hand.

Maybe if a malicious user get access to it, it gets access to that application.

Every day, Niels van Bennekom is concerned with making sure malicious users don't get access to his client's applications, because there's a whole lot of harm people can do when they get access to things they shouldn't. We've all seen the headlines. Sometimes those breaches are the result of outside actors getting access in ways they shouldn't have been able to. Digital identities play a central role, as do the access they're given.

And what we've learned is that there are not only the system administrators anymore, or your Windows administrator. But it could also be you and I, or it could be your Salesforce administrator that needs to change or make or to make changes in Salesforce.

A sysdmin will need different levels of access than a Salesforce administrator, who will need different levels of access than a developer, and so on and so forth. What does this have to do with digital transformation? People need access to their applications' components to work. To do so, they use a digital identity to identify themselves, log in, and gain access to applications, files, and data. But only relevant people should have access to the internal components of an application. And they should only have access to the degree that they need in order to do their job. Any more than that is an increased security risk. That's nothing new. It's called the principle of least privilege.

What's interesting about digital transformation though is the sheer scale required by distributed cloud environments. It can throw any unprepared security team into an unmanageable situation. Why is that? Well, people aren't the only identities who need privileged access to applications.

So, think of humans as you and I that need to have access to business applications every day. And when we're talking about non-human identities, we're talking about applications. So as an application sometimes needs to connect to a database, we see those applications as a non-human identity. But you can still identify it as an identity, but it's not a human, of course.

So you have humans and non-humans, people, and robots. In distributed applications, each component works as its own application, but it needs access to the other components to complete its tasks and pass on information to the next component. Those components need to identify themselves to each other to get the privileges they need, because we can't just blanket allow all requests. Doing that would be an open door for the foxes to get into the henhouse.

When applications are simple and teams are small, managing permissions and identities manually is possible, if tedious. But when you start scaling that application, you'll find it quickly becomes unwieldy to keep track of everything by hand.

But what we've learned over time is that with the growing number of identities in your environments, a growing number of systems, the growing number of people, the growing... Everything is changing and dynamically growing. And what we've learned is that traditionally when we looked at privilege access management, which are the users that are high risk, have high number of privileges in your environment and therefore exposing higher risk...

Your system grows. It uses more components, your team grows. The required number of identities increases too, and probably not in a linear fashion. And if you're doing things right, they'll have varying levels of privileged access. It's really complex to manage all of that. And there are rightfully a lot of new terms used to describe the approaches organizations can take to better manage their users' identities and privileges.

So, what we've learned is that instead of just saying it's identity access management or privilege access management, you can take it from a holistic view saying it's identity security. We want to protect those identities across your environment. And whenever they need some sort of privilege access, we make sure that their privilege controls applied to which could be an additional security layer.

Establish identities, assign privileges, and adjust as needed. Easier said than done. Niels is going to walk us through what it takes to get started.

You start with your workforce identities. That's you and I getting access to Salesforce, getting access to SharePoint, or wherever we need to have access to.

Niels is classifying identities and the general levels of access they should have. And he gives us four groups. Group 1, which he's talking about here, needs the least amount of privileges. They're the general workforce doing non-technical work, but who need access to files and data. Subdivide them as needed. Group 2 is going to need more extensive access to the guts of the machine.

And second, we have what we call, extended IT, but it's a combination of a group. So it could be your traditional IT, it could be your third parties, or cloud operations that need to have access to change the data or get access to the infrastructure.

Group 2 handles IT work. Infrastructure, help desk, operations, etc. They need elevated privileges, but few need access to everything. That's also true of the next group, but they're going to need even more.

Then the third category would be developers, which not only need to have access to the data or need to have access to an infrastructure, they also need to have access to the code itself. They're actually developing the code themselves.

Group 3 includes the developers building the systems. Many of them need access to a wide swath of the environment. These first 3 groups should include all of the human users in an organization, which leaves the rest to group 4, non-human users.

The last one is those non-human identities, which requires similar level of access as developers, which is getting access or change the data or infrastructure while they also need to have access to the code. But the only difference is that for non-human identities, they outpace human identities by 45 times. So there are 45 times more non-human identities than there are human identities in your environment.

Holy cow, that's a lot of non-human users. Those first 3 groups alone sound like a handful. Add in the computers and keeping track of them all becomes what optimists would call a logistical challenge.

Let's take a straightforward example to put that into perspective. Let's say you have a company with about a thousand employees. That's already a lot of identities to manage. Assuming your setup looks like a typical CyberArk clients, that's 45,000 non-human identities. And they're not static either. Modern applications often spin up and shut down components that aren't needed.

So we have our 4 groups: workforce users, extended IT, developers, and the robots. And each of them is assigned a certain level of privileges. Keep in mind that just because they're in the same group, these users don't need the exact same levels of privileges. And keeping track of non-human users is more difficult than the rest.

If a non-human identity has the same level of access as a human identity of like a developer, the difference is that a non-human identity is harder to identify. Because as a non-human identity, I don't have biometrics or I don't have a hardware token that I can use to identify. So, I'm going to leverage existing information in my environment to identify non-human identity.

It's more difficult, but it's not impossible. So you use what you have at your disposal. We've classified our users into different groups. This helps organize the chaos and reduces the risk of someone getting access to sensitive infrastructure and leaking information. Nobody wants that. But it also sets up your organization for easier onboarding as it grows.

The other challenge is that there are way more applications. And what we all know is when something scales or when something's growing and is dynamically changing every day, it becomes harder to manage and maintain over time.

Applications grow and shrink to meet the demands of its users. In times of high traffic, deployment scale up. When demand goes down, unneeded components get shut down. Building these systems is complex, as is adjusting them in the face of new features, bugs, and of course, needing to be flexible at scale. Developers feel pressure to release updates to meet those needs. And they can't always deploy their latest updates as quickly as they'd like.

The challenge that we, as a security vendor, typically see is that we're talking to two different teams. You've got the developers building the applications and you've got the security team trying to protect the environment. And both of them need to work together. Whereas although they both have the same end goal of helping the organization grow, typically, they're still two different teams and they have to work together. And what we typically see is that developers or in the developer community, they're not driven by security. So they're challenged with the security measures, and sometimes they feel like they're disruptive. So, it's hard to get to a point where they work together.

It's the elephant in the room. Security teams often clash with the rest of the organization. Their priorities are different, but in the ideal scenario, everyone understands each other and works in harmony. After the break, Niels walks us through some possible avenues to this utopian unity.

Security is most effective when everybody does their part. With so many organizations moving to the cloud and deployments including so many components, the potential attack vectors have done nothing but increase.

The number of attacks are growing and the number of attacks that are coming in the news or reaching the news is growing as well. And we've seen some of the most advanced attacks in the last couple of years. And that raises a lot of awareness.

Big breaches make headlines. And changing your infrastructure without changing your security strategy is a recipe for disaster.

Niels is going to give us some advice for what to do and why. To help us understand the what, Niels pointed out that one of the biggest differences between older, more traditional infrastructure and newer infrastructure is the pace of change. Older styled infrastructure, like virtual machines or physical servers, stay online for long periods of time. Newer environments change quickly. They require different types of controls and processes to maintain them. That includes processes to manage digital identities. This is where access management comes in.

Identity access management, or IAM, which Niels mentioned earlier in our episode, is about assigning levels of access based on unique identities. BobSmith42 can read what's at the database, but JaneDoe77 can make changes to the network settings. Privilege access management, or PAM, is a subset of IAM. PAM is about assigning those levels of access to groups of people, like the 4 groups Niels defined for us earlier. There's a lot more to it than that, but that's enough for us to move forward. Niels explains a few more differences.

They're similar, but the difference is that for privilege access management, you look at the more risk... what are the entitlements you're going to give to a certain identity that are risky, that can change your environment. Or maybe they can create other users and expose more risk. Whereas access is kind of the front layer saying, "I'm going to give you access to a certain system and privilege." When it becomes privilege, you actually give some permissions to make some changes.

You look at your groups and at their needs, and decide what to allow each group to access. Niels shared a concrete example on how to determine what a group might need.

Think about an application where you want to store some data and it connects to a database. That application has access to connect and upload data to the database. But typically, it can also remove data or change data in that database because that's part of the application, which gives that application the ability to do things you don't want to do.

In this example, Niels is talking about the non-human users, the ones who typically outnumber human users about 45 to 1. They handle a lot of tasks human users might not want to do or can't do as efficiently, so they need the same level of access that a human user might need.

So we identified, we need to limit access to our application. We've identified that we're going to broadly set privileges by groups based on function and identify those groups, but we're not done yet. How do you then secure those users who now have privileges to retrieve and change data? Who can access other components of your environment to cause havoc?

So the way we look at is, you need to give your development teams a framework that gives them the ability to deliver applications in a secure way from the start. Allows them to specify what type of access is required from the beginning, having a control on it to make sure that only the required access is needed. But to achieve this, to achieve such a framework, it's super important to make sure that you're having a framework for any type of integration, right?

Give people a framework and different teams have a common set of rules to work from. Security teams can codify their priorities, which developers can then implement into their work early. They integrate identity security, rather than append it. We now know what to do, we know why. Next comes the how. Niels laid out some steps to determine how to build that framework for assigning privileges to our groups from earlier.

It's important to understand where the highest risk currently is, right? You want to start at the highest risk and make sure that you mitigate the risk there.

It may sound straightforward, but the first step is to figure out where you could be the most vulnerable. Those users move to the top of the list.

The first thing you got to do is making sure that that user is protected. Once it's protected, and protected means I'm applying multifactor authentication, or I'm applying session isolation to a certain user...

You take those high priority users and then make sure that their sessions are protected from breaches. Use whichever method is appropriate to make it more difficult for a malicious actor to log in as that user or intercept any of its data.

The second step could be of all the privileges that this user has applied, only 50% is being used. So now I can decrease the number of permissions to make sure that least privilege is applied and only the required accesses or permissions are allocated.

Once that user is secured, you analyze whether or not they actually need the levels of access they've been granted. Repeat those steps for the next set of high risk users until your whole organization's users have been assessed and their privileges have been adjusted.

Make sure that if they have a task to fulfill, make sure that they go find the easiest way to the result. And when I look at it from a cyber perspective and the way we approach digital transformation is, as I said earlier, we always try to look at solutions from any type of persona that might be relevant for this solution.

Identity security is only one aspect of digital transformation, but it's an important one that doesn't always get the attention it should until it's too late. Niels walked us through the identity challenges organizations face when building or moving to modern infrastructure. Users have different needs, but being security-minded means only allowing enough access to meet those needs. That's all fine and good with an easily manageable number of users, but the distributed deployments of modern infrastructure have so many more users than the older ones do, too many to manually manage. So to handle all of those users, organizations need a plan and a system. And with constant vigilance and attention to the details of an ever-changing system, they can drastically reduce the chances of someone getting access to their applications, and well, becoming a headline.

You can read more at redhat.com/codecommentspodcast or visit redhat.com to find out more about our guides to digital transformation. Many thanks to Niels van Bennekom for being our guest. Thank you for joining us.

This episode was produced by Johan Philippine, Kim Huang, Caroline Creaghead, and Brent Simoneaux. Our audio engineer is Robyn Edgar. The audio team includes Leigh Day, Stephanie Wonderlick, Mike Esser, Nick Burns, Aaron Williamson, Karen King, Jared Oates, Rachel Ertel, Carrie da Silva, Mira Cyril, Ocean Matthews, Paige Stroud, Alex Traboulsi, Kendall "Boo Boo" Howse, and Victoria Lawton. I'm Jamie Parker, and this has been Code Comments, an original podcast from Red Hat.

About the show

Code Comments

On Code Comments, we speak with experienced professionals on the challenges along the way from whiteboard to deployment.

Transforming Your Identity Management