Performing a Service Account Review to Reduce Cyber Risk

First of all, thanks everyone for joining.

Today’s talk, what we’re going to talk about today is essentially technical and service account reviews.

So we’ll do a brief introduction to this.

There’s an agenda coming up in two slides, but first, I’d like to introduce Khadeeja and myself.

So Khadeeja, you can go ahead and start if you’d like to.

Yes. So hi, everybody.

My name is Khadeeja, and I’m a senior technical enablement specialist over at Radiant Logic.

I’ve been with Radiant for about four years.

I’ve worked there as a consultant.

I’ve assisted multiple clients in the implementation and maintenance of our solutions, especially our identity analytics platform.

And I’m cohosting this webinar with JR.

So you can introduce yourself.

Alright. Thank you.

Yep. So my name is JR, short for John Ross.

I’m a senior solutions architect with Radiant, currently based in Europe.

I’ve worked for Radiant for about seven years now.

I did quite a bit of work in the US before moving to Europe, with both the public and private sectors.

And so I’ve been here for about two years now in Germany, helping the European team with technical presales and technical implementation.

So we’ll move on to the next slide, and I’ll start first by giving an introduction to Radiant, who we are, what we do.

Radiant has been in business in IAM for over twenty-nine years now.

Essentially, our platform is built around in-depth identity analytics, which is a big component of what we do.

We specialize in working with companies that have either large complexity or a large number of users within their infrastructure, oftentimes within the scope of consolidation projects, mergers and acquisitions, security projects, and getting an understanding of what’s going on within the enterprise.

The scale and scope of the customers we work with can go from a few thousand users to almost three hundred million objects managed within a single deployment.

Essentially, what we do is we empower organizations by acting as a central identity hub that helps to strengthen the cybersecurity posture of our customers.

We turn identity data into a strategic asset for three main goals: operational efficiency, enhanced security, and automating governance and compliance tasks.

This is what we’ll be talking about today within the scope of technical accounts specifically.

So we can move on here and talk briefly about what the agenda is for today.

Yes, so for today, we will introduce you to technical accounts: what they are, the stakes behind them, and the challenges that many corporations can be facing around managing technical accounts’ access rights.

Then we’ll delve into a recommended approach that we’ve seen with our customers and that we’ve helped our customers with over the past few years around managing service account reviews and reducing their risks.

And if we have a little bit of time left before time’s up, then we can take a couple of questions.

All right.

So I’ll hand it over to JR to introduce us to technical accounts.

Thank you.

So first things first, we’ll define the problem statement.

We’ll define what it is we mean by technical accounts, and then I’ll go into detail around why these technical accounts matter and why it’s important to get a handle on them.

Technical accounts encompass three different types of accounts.

As a group, they are essentially accounts that aren’t attached to a specific named user, generally.

These could be service accounts traditionally, which are high-risk, high-impact accounts for machine-to-machine interaction, for controlling network resources or getting information from them, interacting with APIs, infrastructure configuration, and things like that.

One of the main issues with these accounts is that their credentials—passwords or keys—are rarely rotated.

A compromised service account can take a while to detect because a lot of the time, they fall outside the scope of management and observability procedures that we’ll talk about in a second.

Additionally, compromised accounts, specifically service accounts, can lead to lateral movement by bad actors within organizations.

The second type is administrator accounts.

These are oftentimes shared accounts which provide access to critical infrastructure, specifically for configuration and management of computational resources.

They’re often difficult to audit.

Say, for example, you have a PAM solution in place like CyberArk.

It’s an excellent tool for managing access to critical resources, but a lot of the time, implementing a PAM solution still results in critical blind spots within the account review and audit process.

You end up with difficulty in identifying gaps in the administration or the account lifecycle for these technical accounts.

The third category is “anything else,” essentially.

These can be shared accounts, temporary access accounts, shadow IT accounts, training accounts, test accounts, and similar.

In short, any under-managed or unmanaged account that falls outside the traditional lifecycle process for users within the organization.

On the next slide, we’ll talk about why it’s important to take another look at these accounts and why the current processes that we have in place for lifecycle management are often not adequate.

The old approach that we used to take to cybersecurity in general is perimeter defense.

More and more, it’s no longer fit for purpose in today’s work-from-anywhere world, where we have multiple locations where users are working.

Resources are hybrid—on-premise and in the cloud.

Each user has potentially many different accounts that they use to perform their role.

They connect to these systems with a variety of devices, some of which are not actually controlled by the organization, in the case of Bring Your Own Device (BYOD), and so on.

Despite the fact that companies have invested in a growing set of technologies to resolve these issues, there are still a lot of gaps in the existing approach.

Two statistics quickly.

From a 2022 study, over the course of 2021, eighty-four percent of organizations experienced an identity-related breach.

More recently, Fast Company published an article stating that data breach victims were up almost five hundred percent in the first half of 2024.

So this is a big, growing problem.

The main cause behind it is that bad actors only need access to a single compromised account to get access to sensitive data within critical systems.

A great example is one of the largest mobile providers in Asia that was recently found leaking two-factor SMS codes via an unsecured database.

They had a single service account that was compromised, and then the whole two-factor authentication system was no longer useful.

Even those of us in the identity market suffer from these same challenges.

A few more stats to finish up this part.

From a 2023 Microsoft study, specifically around cloud (but these findings also apply to on-premise):

There is a ratio of one to ten user accounts to technical accounts, so each organization has many technical accounts on average.

Over eighty percent of these technical accounts have an inactive status, meaning they haven’t been used for a long time—maybe the person who used to own that account has left and it hasn’t been deactivated.

Additionally, fewer than five percent of the permissions that are granted to these accounts are actually in use, which means they have more access than they should.

Finally, over forty percent of super admin accounts are technical accounts.

So we see a large population of technical accounts with access to critical resources, with permissions that haven’t been reviewed, and accesses that haven’t been reviewed, holding a large amount of admin privileges on different resources.

Let’s move on to the next slide.

Here’s the core of the issue: all of this creates critical blind spots within the organization.

We need a way to bring technical accounts into the lifecycle management of accounts in general, even when they’re not linked directly to an identity.

Things that prevent us from doing this include:

Disparate repositories within organizations, where these accounts are spread across many different resources, databases, directories, and applications.

Difficulty identifying account owners or holders and understanding what these accounts are built for.

Often, accounts are not tagged with metadata or descriptions of what they’re used for.

You might have an API account that nobody touches because they’re not really sure what it does.

So there’s a need to understand what each account is doing.

Additionally, we have a high volume of these accounts.

With a ratio of one to ten, there can be potentially hundreds or thousands of technical accounts that we don’t understand.

This means there’s a lack of account cleaning; there are no cleanup tasks in place, which is an issue because these are often privileged accounts.

Finally, there is no process to enforce proof of compliance.

If you don’t have data about the account, if you don’t know who the owner is, and you don’t have the proper information, you can’t put in place a process to review them periodically and ensure the security posture around these accounts is correct.

Now that I’ve presented the problem statement, Khadeeja will explain the recommended approach that we generally propose to our customers to help them get a handle on this.

All right. Thank you for your introduction, JR.

That was very insightful.

Knowing all this, we recommend the following five steps to take back control of your technical accounts.

The preliminary step is to define the rules and processes for technical accounts: how to handle their lifecycle, and how to identify the people responsible or accountable for these technical or service accounts.

Once these governance rules and principles are designed, the next steps mostly rely on features or software—such as our offerings—that will help you automate these initiatives.

First, we recommend creating a comprehensive inventory of technical accounts and providing classification on these technical accounts.

We’ll see that in a couple of minutes.

Second, we recommend identifying technical account owners and figuring out who is actually using them.

Once we have this knowledge, we can implement compliance review campaigns targeting these technical account owners, requesting them to approve or revoke these technical accounts.

Once you kick-start the inventory of technical accounts, the identification of technical account owners, and the first compliance review campaign, you will be in a better place to manage your technical accounts.

You will also be able to enforce continuous monitoring and risk mitigation on the technical accounts and their privileged or high-level access rights.

If I focus on the first step—the inventory of technical accounts—what we help our customers do is gather all their data sources that include both identity data (for example, from HR systems) and account data from any account repository.

That could be your Active Directory, your LDAP directories, your local server accounts and groups, or any other account repository for on-premise or cloud-based applications.

Once you gather all these data sources and feeds, you can use software like ours to collect and correlate all the data.

We can then provide a classification of your accounts, especially if you can collect naming conventions around account logins, account IDs, and other attributes, depending on the data model of each source.

We can sort all these accounts into the following five buckets:

The first bucket is named accounts (user accounts).

These are accounts reconciled with an individual user, whether active or a leaver, but at least we can say that “this account belongs to John Smith.”

The second bucket is service accounts.

Any accounts tagged as service accounts—whether in their description, their naming conventions, their logins or usernames, or other attributes—fall here.

The other buckets include admin accounts, if naming conventions help categorize and identify them, and other technical accounts such as training, testing, or qualification accounts in your on-premise or cloud applications.

The last bucket includes all accounts that you cannot classify into the first four buckets.

These are your orphan or unknown accounts.

The list of orphan accounts is a list you will have to work on to improve their classification and identify their technical account owners.

The next step will also apply to the other buckets: service accounts, admin accounts, and other technical accounts.

Once you have your extensive and comprehensive inventory of technical accounts, the main challenge is to identify technical account owners, especially when you don’t have naming conventions, typing, or reconciliation rules to help.

One approach we recommend is to use our workflow engine to design a preliminary review campaign targeted at technical users.

For example, you could target any user from the IT department or division, or a specific company of contractors that handle hosting or administration services.

You would submit to them the list of service and technical accounts identified and ask them to declare any knowledge they have about these accounts.

They could declare themselves as the user or owner of any technical account in the list, and they could also fill any description fields you make available in that preliminary review campaign.

We recommend using the results of this preliminary campaign to make your inventory of service and technical accounts more reliable, enrich your data, and then proceed with the next step: compliance reviews.

For compliance review campaigns over your technical and service accounts, we suggest two different campaigns that you can run either simultaneously or one after the other.

The first compliance review campaign is a review of technical accounts for which you have technical account owners or identified users.

In this case, the purpose is to submit all technical accounts with an identified owner to that owner and ask them to assess whether the account should be kept, updated, or revoked, or whether some permissions should be removed while keeping the account active.

The second compliance review campaign deals with service accounts or any other technical accounts for which you don’t have an end user.

This review targets repository managers.

These could be your Active Directory owners, LDAP owners, local server owners, or database managers.

This campaign asks them to assess whether an account should be kept or revoked and to enrich any information they can provide for these accounts if the first identification review didn’t produce results.

After performing these first steps, you can move into a continuous monitoring approach and enforce a plan–do–check–act cycle, continuously improving your security and lifecycle policies around technical accounts.

You can enrich your mapping and inventory of technical accounts, for example by gradually adding more repositories.

You can implement automated controls refreshed on a continuous basis—for example, identifying leaver and orphan accounts every week each time you refresh your data and inputs.

This step also includes enforcing periodic compliance reviews on an annual or quarterly basis, depending on your auditors’ requirements.

This leads to continuous improvement and continuous risk mitigation, both in terms of remediating accounts for which revocation has been requested and managing these accounts in a privileged access management tool if you decide to implement one.

In terms of key success factors we’ve identified with our customers, the three biggest are:

First, come up with a comprehensive cartography of technical accounts on your critical systems and ensure this inventory is gradually enriched and increased—both with new data helpful for qualifying your technical accounts and with periodic scope extensions where you add more data sources over time.

It typically does not work well to start an identity analytics or access rights governance project by importing all data sources at once.

We’ve seen customers try and be underwhelmed by the results.

The approach we’ve seen work best is to start building the inventory with two or three of the most critical systems (for example, Active Directory or any privileged access repository), then gradually increase the scope with more repositories and applications, little by little each year.

The second factor is making sure you have identified and available reviewers and that you can identify high-level sponsors who will mobilize those reviewers.

You need people motivated to perform the campaign and to declare any information they have in their heads about technical accounts identified within your systems.

Combining automated, permanent controls refreshed on a regular basis with periodic review campaigns gives you the opportunity to gather requests for remediation or risk mitigation relevant for your technical and service accounts.

This is the end of our presentation for today.

I would like to thank you for your attention.

If there are any questions, we have a couple more minutes left to take a few.

There’s one that I see in our chat section, and I guess that question would be for you, JR.

“What if we already have an IAM solution in place that has not solved the issue of technical and service account management for us? What do you say?”

That’s a good question.

The first thing to say is that traditional IAM or IGA solutions are generally geared towards managing user accounts and user account lifecycles.

That comes back to the original problem statement: a lot of the time, technical accounts are not included within this traditional IGA lifecycle.

We recommend finding something—whether it’s through us or another solution—that can attach owners to technical accounts.

First, identify who is responsible for managing the lifecycle or making sure it’s properly taken care of once somebody leaves the enterprise or changes roles.

The next part is bringing in data that traditional IGA solutions wouldn’t necessarily look at, such as local accounts and non-structured data access rights.

There are many types of accounts or resources that these technical accounts might access that wouldn’t traditionally be integrated in the user lifecycle.

What we’re talking about here is a specific review that addresses technical accounts to make sure we can fill those gaps.

I see.

Okay.

There’s a second question that we can take: “How can I identify an application that has been accessed by a service account?”

I’ll take this one.

There are many instances where it may not be easy to identify the target application accessed by a service account.

In some cases, we recommend using additional sources of knowledge to enrich your mapping of technical accounts.

One example is using the history of ITSM tickets, incidents, or service requests to get the history behind a specific service account.

You might look for who requested the account creation, who filed incidents on that account, and which teams or application groups they belong to.

That could be a way to answer the question, but it requires a lot of data correlation and investigation.

Another possible solution is to include these accounts in a dedicated identification review—the preliminary review we mentioned—where you have the list of all service accounts for which you’re still looking for the name of the target application, and you submit that list to all the application managers in your enterprise.

You ask each application manager if they recognize any service account that their applications are leveraging.

We recommend including both functional (business) and technical application owners in this identification review for service accounts.

Depending on the application, sometimes the business owner has more knowledge, sometimes the technical owner does.

If you want to maximize your chances of gathering as much intel as possible, add both audiences to your identification review to maximize sorting of accounts into known buckets: service accounts with identified owners, technical accounts, admin accounts, or other types.

We’re getting to the end of our webinar.

Thank you, everybody, for joining us.

If you have any more questions or requests for a demo of our software offerings, please reach us on our website or using the email address [email protected].

We’ll get back in touch with you in a few days to send you the link to the webinar replay if you want to watch it again.

Thanks, everybody, for joining us, and thank you, JR, for cohosting this webinar with me.

Thank you. Thanks everyone for joining. Bye bye.