Service Accounts: The Secret That Hackers Don’t Want You To Know About

We’re going to go ahead and get started here.

I’m sure there’ll be some more folks joining and there will be, again, as we’ve mentioned before, a recording session today and a full set of slides available to everyone that’s registered.

Before we get started, I want to do a little bit of housekeeping.

Just go through a couple notes here to let you know that everyone’s mics will be muted throughout the webinar.

Should you have any questions, please place them in the chat.

We have two of our experts in the identity management platforms of Radiant Logic that are standing by to answer those in line as we go along.

If there are any questions left over at the end of the session that we cannot get to, we’ll definitely respond back to you directly with answers to anything you have.

Now without further ado, I would like to introduce this week’s honored presenter, Akshay Srinivas Rajanbabu.

Akshay is the vice president, solution consultants with Radiant Logic.

Akshay is a forward thinking IT strategist with a deep passion for revolutionizing identity and access management with an extensive experience in designing and implementing large scale identity ecosystems.

His expertise is holistic, as you’ll see today, spanning identity management, modern authorization solutions, robust identity verification processes, and dynamic risk detection.

By leveraging cutting edge technologies within the ecosystem, Akshay has strengthened organizations’ structural frameworks while driving innovation at some of the largest organizations in the world.

I am your host, Wade Ellery, the field technology officer at Radiant Logic, where I have been taking my three decades of experience in identity security management to support the efforts of our customers to improve the overall security of their identity infrastructure and business efficiency.

So today’s focus is on a very hot topic.

As you noticed from the title, The Secret Hackers Do Not Want You to Know: Service Accounts.

This runs across every industry vertical that we work with.

Actually, the title of today’s webinar is intriguing.

So why don’t hackers want us to know about service accounts?

What’s the big deal, and why should our audience care?

No, thank you.

First of all, thank you so much for having me here, Wade, and thank you for the introduction as well.

In conversations with customers in my block for the past five years, in every vertical that I’m seeing, this becomes a common pattern or a conversation that is becoming more and more important within every organization that I talk to.

Right?

And the big deal, as you asked, is that organizations have organically grown over the years, either through M and A, which is mergers and acquisitions, or they’ve just been divesting into different streams of business.

But with all of that comes IT needs.

And IT needs require a lot of systems, hundreds of operating accounts within an ecosystem.

Now, threat actors at the same time are also becoming extremely efficient, right?

So their landscape is also expanding.

And thanks to AI, every common man can now learn something from the dark web and become a bad actor or an attacker within a matter of days or months, right?

So what we are seeing, and this is an interesting stat, right, is that ninety percent of the breaches in the past one year have directly been because of an identity breach that exists within your ecosystem or an identity blind spot.

So threat actors are becoming a lot more efficient in not attacking the middleware like your single sign-on service or your IGA platform.

They’re going directly to the source, the vulnerable accounts that exist within your ecosystem that you’re not looking into, you’re not managing efficiently because there’s been years of growing population of those service accounts.

So that’s why this is becoming a very, very important topic of conversation.

And it’s becoming very important that we need to start looking at these blind spots around service accounts, local admin accounts, shadow admin accounts, and legacy accounts.

Because if you think about it, Wade, these are keys to the kingdom, right?

They are overprivileged, which means they have a lot more access than what they should do, and the potential damage to your environment is extremely big.

So it’s critical that we start looking at these local accounts that exist with highly privileged access.

All right, I understand.

So this is basically like I spent all this money on building this burglar-proof door on the front of my house, but I have a screen door on my back porch that I didn’t even think about.

I’ve got blind spots here.

I don’t see the vulnerabilities in my organization.

So this can be a very real risk.

But how bad can this get?

What can go wrong in a scenario where I really am not paying attention to maybe half or more of my security vulnerabilities?

That’s a great question, Wade.

So what we’ve been seeing in this space, through conversations with our existing customers and the space by itself, is that there are a couple of direct risks and there are indirect risks.

The direct risk is more impactful because it’s an account compromise.

So think about it as a large organization’s service account getting impacted, which gives them keys to the kingdom to the customer management system, which means all of the customers’ identities are now compromised, including passwords and all of the HIPAA-related information or PII-related information.

So account compromise is your direct risk.

Having accounts that are not managed just becomes a low hanging fruit for the bad actors to get access to.

Once that is compromised, there’s always a lateral movement of the bad actor to make more damage within the same organization.

The other piece is system outage.

So when a service account that is leveraged for critical tasks gets hacked or breached, what typically happens is that the important tasks within your organization get impacted.

Think about it and relate this to production outages.

You might have a revenue-generating application that you’ve completely cut off from the ecosystem because that one account that was required to run that revenue-generating application was breached.

So it’s a huge loss to organizations, these direct risks.

But there’s also some soft costs, indirect risks, maintenance burdens, right?

Now that we are organically shifting from human accounts to nonhuman accounts, because if you look at the human account landscape, you have a typical process on where the account originates, like an HR system, and how it flows through an IGA system and how workflows work and you provision them into target systems.

But nonhuman accounts don’t have this lifecycle management.

So your maintenance burden of managing these accounts is elevating as you work through your compliance framework.

A good example is now more and more of the compliance frameworks like ISO or NIST or PCI are requiring you to properly secure your service accounts.

The challenge that every organization is facing is, hey, I don’t even know where my service accounts are, so how am I going to manage them efficiently?

How am I going to provide the right reports to my auditors saying, hey, this is how we are managing them, this is how we are identifying them, and this is how we are securing them?

So maintenance is becoming a big burden, and maintenance leads to outages and account compromise as well.

Loss of productivity is key because think about it, right?

You need access as an employee.

I join acme.com, and as an employee, I need access to certain systems.

The challenge is, how do I get access to these systems?

I get access to these systems through administrative accounts or shared accounts or service accounts.

Now, the path of providing these accesses is challenging because we do not know the landscape of who has access to what and what application is managed by what account.

So there’s also a soft cost of loss of productivity because we don’t really know the landscape of who needs access to what.

So there’s a little bit of both: direct risk, indirect risk, and direct risks are hard cost dollars that directly impact the organization from reputational damage when there is a breach.

Indirect risk is more soft cost dollars like maintenance burden and lost productivity and so on and so forth.

Okay, now you’re getting me concerned.

I think you’ve got my attention here.

This is something that’s real and needs to be addressed.

Do you have some examples from some real-world customers about the scope and the areas at which this impacts your organization, things maybe that you’ve worked on directly?

Because I know it’s always important for our folks to see how others are viewing this problem and what they’re addressing and the areas that they’re paying attention to.

No, absolutely, Wade.

So again, like I mentioned when I earlier joined the call, this is becoming more and more of a challenge.

Every organization is facing it.

Every company in my block that I walk into, I already start to see them reacting to, hey, we have a good handle on our human accounts, but nonhuman accounts are becoming one of our bigger threat landscapes or risks or areas where we are failing when it comes to compliance and audits and so on and so forth.

So I’m sharing with you one typical example of a major insurance company.

Back in the day, one of the most important pieces is we broke this down under technology and also business challenges.

The reason being, for a very long time, identity was not considered a part of cybersecurity.

Identity was not considered as, hey, this is a business impact to the organization.

Now more and more people are realizing that because of identity, there are risks like direct risk and indirect risk that can be directly tied to business challenges and productivity loss and so on and so forth.

This specific example was a large insurance company where they have been growing for a very long time over the years and they had tons of systems, directory stores, local accounts that exist within the ecosystem, application local accounts, and so on and so forth.

Now there was a time where they started to see a lot more of the impacts and threats around breaches on those accounts.

So they started to focus on, hey, how do I first discover these nonhuman accounts?

How do I perform an access review on those nonhuman accounts once I discover them?

Because the most important piece is once I find them, how do I monitor them?

How do I protect them in the future?

The key is increase the visibility.

So in the case of a breach, when I know that this specific service account is responsible for the breach, what visibility do I have on what impact that caused to the organization?

How can I quickly backtrack and reduce my blast radius so it’s not impacting other areas of my business?

So their focus was, hey, first I need to discover it, then I need to monitor it, review it, make sure that an ownership is assigned to that account and so on and so forth.

The most important piece is visibility.

What can that account do within your organization?

If that account gets breached, what other systems does it impact?

The business challenges are pretty straightforward.

We’re reducing the risk of breach.

It’s improving reputation because we don’t want to go through a lawsuit and reputational damage, because if identity gets breached, it reduces the confidence in the business.

Every organization has their own competitors.

Insurance has multiple insurance providers.

You don’t want to lose your business to other insurance providers just because you breach the lack of trust.

Now, what we’re also seeing is once we bring in this information, it also helps in providing some of the other use cases or business challenges or technology problems that you’re solving within your organization.

In this example, once they discovered these accounts and monitored these accounts, they wanted to use these accounts for their Zero Trust framework.

Once we’ve created that centralized repository, providing the right roles and the right access for these accounts was a lot easier.

They were able to reduce the concept of overprivileged access to move to a least-privileged model in their Zero Trust framework.

Zero Trust, again, is a policy, it’s a framework, it’s a process, right?

There are different variables that exist within that ecosystem and nonhuman identities or nonhuman accounts like service accounts, technical accounts, are also part of that ecosystem.

So it’s kind of like you solve one problem and it’s opening up a value chain for another initiative or a program that you’re building within your organization.

Excellent.

Wow, this is impressive.

It shows that they’ve definitely invested a lot of effort in this area.

They recognize the challenge and they recognize the downside and the upside potential here.

But for the average person attending our webinar today who’s just looking at this as a challenge they have to start to face, and they go through the discovery process, what are they going to find up front?

When they have a blind spot as big as this, when they first peel back the covers, what are the kinds of things they’re going to be confronted with, and how do they start to move through that new area of discovery and resolution?

That’s a great question, Wade.

What we are seeing is that every time, and I talked about this, I touched on it a little bit, about lifecycle management.

Human accounts have a very straightforward process.

Nonhuman accounts, the lifecycle management is broken.

Let me give you an example.

In my world, I call it no chain of custody.

Nonhuman accounts, because of lack of ownership management.

If an end user or an identity like myself leaves the organization, typically there should be a process that changes the ownership of all of the nontechnical accounts or nonhuman accounts that I personally own.

But because this chain of custody is broken in the lifecycle management of nonhuman accounts, that service account or technical account becomes an orphaned account, right?

Typically the best practice should be, hey, I’ve identified that the owner of this account, Akshay, is leaving the organization.

So I’m going to find another owner and tag that service account to that owner so it can be reviewed and managed much more efficiently.

But the reality is we don’t see that.

So there is a lack of chain of custody in the ecosystem in managing these service accounts, and creating these orphan accounts is inherent to the process of the organization.

The second piece is inconsistency.

How are these service accounts created?

Typically when a user onboards an application and the application is important to the business, nobody really goes through the best practices of cybersecurity.

They say, hey, I need to onboard this application, so I’m going to bring this application on and I’m also going to create a bunch of service accounts because the administrators of those applications need to manage that service account.

Now, because this is not going through the proper process of provisioning these accounts, they lack quality in those accounts.

For example, is there an ownership?

Is there a proper description of why these accounts are being created and what they are being used for?

Are there flags that indicate that these are service accounts?

Is there proper password rotation on these service accounts?

Because again, service accounts and admin accounts are all keys to the kingdom.

They have a lot more access, and you want to make sure that these passwords are rotated in a much more efficient way, and that goes to password strength and all of the good things that we as cybersecurity professionals focus on.

But there is a small business within your organization, they just needed the application, they onboarded it.

So that’s the kind of inconsistency that we see where eventually over years, there are tons of accounts that exist that we do not have any information on at all.

The third piece is lack of governance.

Like I said, compliance is catching up.

They’re saying, hey, these accounts are also critical.

You need to have visibility on these accounts.

You need to manage them efficiently.

You need to guardrail them with the compliance frameworks of cybersecurity.

Within each of these compliance frameworks, there are clauses in their frameworks that say, hey, this is exactly how you need to manage service accounts.

Once you identify this, you’re able to appreciate everyone’s patience.

This is the first time back in the new system, so of course it’s going to try and hurt us.

So I think we were just wrapping up there on lack of governance, Akshay.

Actually, these are rather concerning systems here.

My thought is, though, that no good engineer, no well-thinking identity management person is going to create a system that has this kind of bad management built into it.

So what really happens that has our customers’ environments evolved to this level?

What’s the challenge that they’re facing that they have to go back and try and re-engineer themselves so they don’t go down this path repeatedly?

You hit the nail on the head, Wade, right?

How did we end up here?

It’s important to understand because nobody’s trying to make a decision that they want to get here.

They just eventually end up there.

There are a couple of reasons that we see why organizations suffer with unmanageable service accounts.

A good example is legacy systems and processes.

Like I touched upon, lifecycle management is broken.

Lifecycle management is equal to processes.

If you don’t have a centralized lifecycle management around service accounts, it becomes challenging to manage them.

With legacy systems, the biggest challenge is you don’t want to change anything because it’s going to break something.

You say, I don’t know who built that application and anything that I change within that application, something will break.

That’s creating hundreds and millions of dollars worth of revenue for the organization.

I don’t want to touch it.

So it’s key to touch every single system that exists within the ecosystem.

We’ll talk about how we maybe in the future connect to those legacy systems and so on and so forth.

Now, ID debt is also one of the biggest challenges.

When you buy something and onboard something and you bring on a new application, you’re not thinking about, hey, what can I retire?

So you end up having two of each and that creates a snowball effect to have many of the same.

That all trickles down to, hey, how do I manage everything that exists within the ecosystem?

You’re looking at it from the mountaintop, but there’s so much more buried down within the iceberg.

The third piece is what we see typically is mergers and reorganizations or acquisitions.

You went on to grow the business, and the organic way of growing the business is to acquire another organization.

Now, you as a parent company might have a very good, stringent process when it comes to onboarding a service account, right?

But that’s not true with the company that you just acquired.

Of course, you want to be sure that when you integrate these systems, you’re also making sure that the processes of your parent company are established.

But more often organizations want to see a quick return on investment.

So there are quick integrations.

That means you’re bringing on all of those additional noncompliant cybersecurity practices into your parent organization.

So mergers and acquisitions seem to be one of the biggest challenges of why large organizations end up there.

Those are the three reasons why I see organizations suffer from an inorganic growth of service accounts.

Excellent, yeah.

So it’s not any one person’s fault.

It’s really kind of a perfect storm of Murphy’s Law and Murphy’s corollary.

If something can go bad, it will.

If something can get complicated, it will.

So it seems like I’ve got this real challenge that I recognize now.

For the organization who hasn’t gone as far as your original example and really built out this discovery process, what are the next steps in digging ourselves out of this hole?

Where do you start?

How do you eat the elephant one bite at a time?

That’s a good question.

There’s no magic button.

Let me be honest.

You don’t click a button and everything is fixed.

The world of AI has made life so simple that everybody in the business thinks, hey, I want to introduce this one tool and everything is going to magically appear for me.

But the reality is it’s a process.

It’s a five- or six-step process, and you want to be cognizant of the fact that you as a service account admin or administrator need to involve different teams within the organization to get through this process of cleaning up your environment.

It starts with inventory.

You want to first identify what is your current state.

Do I have a good handle on my service accounts?

Do I have a good handle on my human accounts?

Are they in the right order before I can move on to my nonhuman accounts like service accounts, bot accounts, and so on and so forth?

So inventory is critical.

Understanding your current state of your maturity cycle and your model is extremely critical.

The second piece is interview.

You need to start to work with the other stakeholders.

It takes a village because you have repository owners, you have application owners, you have domain administrators where local accounts could exist.

You have SQL Server databases where local accounts can exist.

You need to go start interviewing the different stakeholders within your organization that own and manage technical accounts.

Like I said, it’s a process of collaborating with these different teams.

In this collaboration process, in the past, typically what you would do is walk around with Excel sheets and give them out to people to fill in.

But that’s not a scalable approach.

You need tools in place in order for you to go and reach out to as many people or stakeholders as possible within your organization and collect this information and have the ability to start assessing risk within your organization.

Why is this important?

As you start going through this process, you’re going to realize that there’s a lot more that you need to cover in a small amount of time.

Making sure that you assess the risk after the interview process is critical because that allows you to break this down into phases.

You’re starting to realize that there are certain systems that are low-hanging fruit, which are centralized ecosystems like my Active Directory as an example, but there are a lot more other systems that are local accounts that are a lot more complex because I don’t know what the authorization rights and permissions look like because they were not created centrally.

So understanding risk allows you to phase this approach and then understanding complexity also creates another indicator into what you need to first factor into your cleanup process.

Then you go down the order of what you can take on next.

The last piece is extremely critical.

Once you identify this, what do you want to do with it?

So I’ve found out that there are three hundred service accounts that exist within my Microsoft SQL Server, which gives access to my SAP financial accounting system.

You found that out, but what do you do with that?

Mitigation strategies can also vary.

There are different mitigation strategies.

One mitigation strategy is, hey, I’m going to shut the lights off.

I’m just going to deactivate these accounts because they do not exist in the system.

But then there are implications to that.

What if it’s running a critical system?

You deactivate the account and that critical system is going to stop working.

Again, assessing risk also allows you to make decisions on how you want to mitigate these systems.

Some mitigation might be, hey, I’m not going to deactivate it.

Now that I’ve identified these accounts, let me run a review process and find the right account ownership and make sure that I, as an administrator, understand that a specific account is used for a specific purpose and the lights need to be kept on, so I don’t deactivate the account moving forward.

The other way I’ve seen organizations manage mitigation is, hey, I found these fifty accounts.

They are extremely critical and I don’t want them to be local accounts that are unmanaged.

So let me, as a mitigation process, onboard these accounts to a CyberArk service, which is kind of like a privileged account management service, or a Delinea or any of the PAM solutions, and make sure that they’re managed even more efficiently so I don’t run into this challenge again.

They’re protected so nobody is trying to hack those systems and get access to those accounts that exist within those systems.

Your mitigation is critical and think about it as a waterfall process.

Every stage that you go through becomes an input to the next stage.

So your mitigation relies on the interviewing and the inventory and the risk assessment and the complexity assessment.

Excellent.

Yeah, it is very much an interconnected process here.

I think your phrase you used a minute ago, it takes a village, is critical.

What I’ve noticed in large projects like this is that this isn’t something you can give a summer intern to take on: “Hey buddy, clean up our service accounts while you’re here for a couple of months.”

It also takes executive management.

Anytime you have to bring people in and get them to cooperate, you need a level of executive backing on a project like this.

But there’s a lot of wet work here.

There’s a lot of talking.

There’s a lot of planning.

There’s a lot of analysis.

People like action.

They want to jump to dessert: show me a change.

So when you actually get to start making a foray into the environment and figuring things out, getting real concrete facts, what does that look like?

What’s the path that you follow once you’ve got your map?

How do you leave town and start heading to the big city?

Yeah, the path forward is important.

We’ve talked a little bit about the challenge and the process of how you can get to the final state, but what do you do if you break this down into a project?

The first piece is, hey, everything relies on data.

You need to connect to those systems and collect as much information as possible from all of those disparate systems, whether it’s directories, HR systems, your databases, your SIEM solutions, your local accounts, applications, and so on and so forth.

The more information you have, the more you’re able to identify patterns within those systems, be it behavioral patterns of those accounts—when are they authenticating?—or naming conventions within those accounts, or metadata within those accounts.

These become very clear indicators to tag them as nonhuman accounts.

Then you start to compartmentalize them as a nonhuman account: is it a bot account, is it a service account, is it a technical account, is it a shared account, and so on and so forth.

But the first path is to connect to all of these systems.

Once you connect to all of these systems, it’s very critical to identify and understand the context about those accounts and map that context to a human identity.

That’s where the process of correlation becomes extremely critical.

What you’re doing is you’re identifying a human and then you’re mapping all of these accounts that might exist within these ecosystems to that human so you can create what is called an access chain.

At any given point in time, you’re able to identify that, hey, Samantha Schwartz exists within the Acme ecosystem and these are the five accounts that Samantha Schwartz owns, and using these five accounts, these are the systems that Samantha Schwartz has access to.

Then the access chain can be infinitely expanded.

Can we bring on CMDB information?

Can we bring on file share information?

We can keep augmenting the access chain of Samantha Schwartz.

In this case, our typical example is that Samantha Schwartz owns this account called SAP SRV, which is a service account.

She is the owner.

She needs to make decisions on whether this account needs to exist or not.

The access this service account has is to a SQL database server.

Through the SQL database server, probably an SAP financial application is getting access to that system.

So the access chain is critical.

With raw data as you collect it, you really can’t make any inference.

You need to bring it into a model where you’re creating an access chain so you can start slicing and dicing the data and identifying patterns to first discover these accounts as well as tie them back all to one identity, which is the most important piece.

Excellent.

That is a great illustration.

I think that the chain of ownership and the nature of that account’s privileged access management is a critical piece to putting this all together.

It looks like you’re really building a puzzle and an analysis of the whole platform.

Can you tell us a little bit more about the kind of systems they’re going to run into?

You mentioned Active Directory before as being low hanging fruit.

What’s out there that I’m likely to find?

Where do I need to go look when I start this project?

You mentioned earlier some nonservice account technical accounts.

We use “service accounts” as kind of a catchall phrase, but there’s a number of different species of account out there that are nonhuman.

You touched a little bit on what those are, and then the real critical piece, I think, for a lot of organizations—the biggest blind spot—is local accounts.

I don’t have any visibility into local accounts at all.

I literally cover my eyes and pretend they’re not there in a lot of scenarios.

We can’t do that anymore in a blind spot, risk-based model.

So if you could touch a little bit more on what we are looking for, the different kinds of accounts we’re likely to run across, and then a little bit more on local accounts so we can understand where we need to go next.

No, absolutely.

So there are usual suspects within the ecosystem, and you want to start with the usual suspects.

Those are where all the service accounts are typically hiding.

You have centralized systems like your Active Directory, which acts as your central directory for authentication and authorization.

Most often, I would say sixty percent of your accounts exist within those ecosystems.

But again, you do have, like I mentioned, organizations that are organically growing.

An application that is being onboarded, instead of enabling it to authenticate against an Active Directory, most times they have a criticality, they want to onboard the application quickly.

So they just create their own repository in a SQL database and say, hey, this table with all of my users is going to act as my authentication source moving forward.

That’s where you have the other pieces of your service accounts that get hidden.

That becomes kind of like a blind spot within your organization.

Of course, we’re seeing a large move towards the cloud ecosystem.

We’re seeing the actors and entries of the world that are also authoritative to identity information, including not just human accounts but nonhuman accounts.

But the most important piece that everybody is trying to avoid getting into that mess is local accounts, but that’s where the gold exists.

Because in the history of identity management, it started with local accounts.

That’s where accounts existed.

That’s how people gave access to all of the applications.

So it’s critical that you also analyze these accounts because what it takes is one blind spot for the threat actor.

You might get all of the other systems that are centralized in order, and if the threat actor or the bad actor gets access to that one account that exists within the local system, whether it’s domain managed or within the server, that becomes a major risk to the organization.

You want to make sure that you’re covering the entire ecosystem through this process.

Certain systems like Splunk become extremely critical as well because usage logs are important to monitor the behavior of these service accounts.

The more information you can get from those systems, the better you can identify and differentiate a human account versus a service account.

Because it’s the wild, wild west when you start looking at these accounts.

You have no idea because there’s no real differentiation when you look at these accounts.

You need more indicators that define that this is a service account, and usage logs coming from SIEM systems become an extremely strong indicator to identify a service account.

What we’ve been seeing is that the access chain that I talked about is now being extended with CMDB information as well.

Why is this important?

The CMDB manages all of the configuration data, asset management, and so on and so forth.

By identifying the service account, what you’re able to do is map it to a CMDB service and say, hey, this service account actually impacts this financial application that exists within the ecosystem, and that service account is being used by a load balancer that manages that financial system.

So you can get to that level of detail of what are the impacts of those service accounts.

It’s important to identify these usual suspects and bring them all into the system and start monitoring them.

To your point, local accounts are also a critical vector.

Just before we jump on, I know we talked about local accounts and the discovery on local accounts.

Discovery on local accounts is critical because what you’re dealing with is hundreds, if not thousands, of systems.

We’re talking about local machines that a human might own that might have a local account.

So you want to do this at scale.

There are different discovery options that you need to inherently adopt to look at all of these systems at scale.

When you’re looking at these systems, it’s not just, hey, find me that account and bring me that account back.

It’s also the access chain of that account.

What rights do those accounts have and through what group information they gather those rights, and what permissions are attached to those rights, and what applications do they have access to through those rights.

Think about it as when you identify those service accounts, it’s not just identifying the account, but also identifying the context about that account.

What are the relationships that exist for that account in that local system?

We need to bring in not just the accounts, but also the context is my final thought there.

Excellent.

What I think you pointed out on that slide and this slide is that these are disparate systems.

These are platforms that don’t normally talk to each other.

Local accounts don’t like to talk to anybody.

So you really need a platform or a foundation to build all this on.

Radiant Logic’s capability of connecting to all these systems, to gathering this data together, to bringing this forward so you can actually start to do the analysis and build the access chains.

That set of tools is critical.
I think the combination of a really strong methodology, which you’re outlining here, and then a set of tools that is capable of doing this really changes the challenge here from someone coming upon a lake and trying to figure out how to fish to someone being taught how to fish.
Once someone knows the methodology, has gone through this, and then has the proper set of tools, this becomes a much easier process to go through, it looks like.
Yeah, Yeah.
Touched on an interesting point a second ago with the introduction of the CMDB data, because this to me seems like I’m really now casting a much wider net.
There’s so much information out there in these platforms that if I can leverage that, imagine how much more accuracy, how much more depth I can have.
What are we doing with that kind of data when we start bringing this all together?
No, the critical piece is, hey, what are those service accounts impacting?
So a lot of that information exists centrally within a CMDB service.
So you wanna be able to take advantage of that.
So within the system, what we do is we connect to those CMDB services and augment that information into the access chain.
So what you’re getting, and you’ll see this a little bit, I’m going to introduce you to how do we solve for this using the product, but what we’re typically doing is we are connecting to the system where everything about a configuration item is centrally managed, including the resources and so on and so forth.
So once we identify the service account, are automatically able to map that account to all of the CMDB services that it might impact, right?
In this case, we’re saying, hey, a SAP SRV account is actually impacting the SAP Financial Accounting System, which drives billions of dollars in revenue.
And the dependency that one account has on all of the other systems are massive.
Right?
So there’s two ways organizations can use this, right?
One is, hey, how can I better analyze risk of that service account?
Hey, this is a typical large scale application and my service account is supporting that large scale application.
So the risk level is higher.
Or the secondary is a reactive approach.
Once you identify a risk or a breach or an anonymous access to that service account, hey, how can I come into the system and quickly see what is the impact to what that service account breach could be, right?
What are the different layers it touches so I can quickly go and remediate and create the right fences so the lateral attack can be stopped and mitigated, right?
So it gives you a high level visibility into everything that one account could impact within your ecosystem.
Excellent, that looks like really good information.
Now, we’ve gathered all this data together, and that’s critical because if you don’t have information, you can’t start working on this problem.
But then how do you bring that together?
How do you turn this into something that’s recognizable?
How do you aggregate this data together?
What are the tricks and secrets that you’ve been able to accumulate over the years and the ways the tools operate that let you now make sense out of this?
How do I get a view of the world now where I can quickly recognize risk, where I can remediate things?
And if I’m going to automate these processes, I have to have this information in sort of a business process model.
So what does that step look like?
So, one thing with service accounts that we’ve seen is there’s no real common indicator that says, hey, I’m a service account.
The importance is you need to start looking at different indicators.
So the tool is through the concept of controls, what they’re able to do is look at all of these individual indicators.
And initially I talked about bringing in all of the data together, right?
That’s the most important piece.
Once you have all of these data in one point, you’re able to analyze the data and run through these common indicators.
So naming convention is a great example.
Hey, does the service account start with a prefix and end with a suffix that says SVC or a technical account, or is there some kind of jargon that I can identify within the naming convention?
And then if that’s not the one key indicator, then you can go down the order of, hey, how can I create a bunch of indicators that can quickly look through the system and analyze and identify matches to those indicators and quickly tag them as service accounts, right?
Account activity is a great thing.
If you look at a service account, it’s created for a specific purpose.
Hey, run a script at twelve am in the morning every single day and publish a report, right?
So if you look at the service account, it has keys to the kingdom because accessing data and then publishing the report.
So you’re identifying that every day at twelve am, there an account that is accessing a system.
Now typically a human behavior is not that, right?
You’re not logging in at twelve am exactly and running a script.
So that gives you a good indicator that this specific account is not a human account, it’s a non human account performing a specific activity within the organization.
Then there’s other kinds of information that you can look at such as metadata attributes about the service account.
You might have description fields that give you a small nugget into what the purpose of that account is that could allow us to tag whether it’s a service account or not.
Password policies are also other indicators that we can look at.
Certain flags that you might have within the account that identifies that this is a service account.
So a combination of all of these vectors become indicators for us to define that, hey, we ran through all of this data and we’re able to identify patterns and we’re going to tag these accounts as service accounts.
Excellent. Okay.
So now that I’ve got this information gathered together and I’m performing these aggregations, what would sort of like a map of this look like?
What if I step back from building out this analysis?
How do I sort of visualize seeing all these pieces together?
It looks like, again, I have a discovery get clean model, but I also have a keep clean model.
I need to have processes built that allow me to maintain this.
So what does it look like when I start to go into a more mature model of saying, I’ve not only identified everything here I’m cleaning it up, I’m finding ownership, I’m testing risk but going forward I’m processes that are going to keep this from recurring, that are going to get me to a level of ongoing security, which is the critical piece because bad operators only need to find one account and be right once.
We need to be right every time.
So we can’t let this descend back into chaos again.
Yeah, remember, and you touched upon this, it’s not just a one time process, right?
It’s not just, hey, I’m just going to run this for the next six months and get everything cleaned up and not worry about any of these inefficiencies coming back into my system, right?
It is always the process of getting clean and also staying clean.
And you want this to be an automated process behind the scenes that’s constantly looking at identity data, right?
Looking at usage logs, looking at CMDB information, looking at all of the identity as a service data points that come through, right?
And the most important piece is the brain in the middle, which is ******* this data, identifying based on those indicators that, hey, these are the list of newly identified or discovered technical accounts.
And once you discover these technical accounts, you just don’t onboard them as technical accounts.
What you need to do is perform some level of hygiene practice on that service account.
Hey, there are thirty accounts that we’ve identified.
Can we look at all of the metadata and the attributes about the service account and identify whether, A, the service account is any more needed.
So imagine organizations when they onboard an application, they onboard a service account.
But when they offboard an application, which is, hey, this application is no longer needed, do they really go back to the system and actually check if the service account is needed?
They do not, right?
So what happens is it becomes a zombie account or an orphan account that just exists within the system.
It’s never used, but it does have access to certain critical data points.
So what you want to do is hygiene, right?
Identify whether those service accounts are needed, identify if all of the attributes are populated within the service account, identify whether there’s the right role ownership or service account ownership tied to that specific technical account and populate all of this metadata before you onboard that into a system like a IGA platform.
Because what we want to do is not just identify these accounts, but we want to identify them, categorize them based on risk and send a strong signal back to your Lifecycle Management Service saying, hey, go ahead and onboard these list of accounts into your Privileged Account Management Service because they hold the keys to the kingdom, You want to make sure that you’re managing them appropriately, rotating their passwords appropriately and so on and so forth.
So yes, we had absolutely, it’s a get clean, stay clean state.
You want this completely automated and it needs to be built to governance standards.
So you’re also able to go back to the auditors and prove that everything’s working as expected.
And you mentioned the need for that brain right there, the one that’s able to start and look at all this data and make those kind of correlated decisions and stuff.
Where would one go to find a brain like that?
Do you know anyone that makes a brain like that?
That is what our identity analytics solution does for you, right?
So I’m going to quickly jump into the product and show you maybe like three or four minutes of a teaser on how we get all of this done within our ecosystem.
But the the the most important piece is categorizing them as human identities and non human identities and putting them into buckets as, hey, are they correlated accounts, justified accounts, unjustified accounts, and then start working through the hygiene of the system, right?
So let me quickly shift my screens into showing you a little bit about the product and how we get this done, and then we can jump straight into the next piece of the presentation.
So what you’re seeing here is our identity analytics platform and I want to start with our dear old Samantha Schwartz that we’ve been showing you through the slides.
This is the access chain that I described.
Samantha Schwarz is an identity within the organization and she has access to four accounts and through those four accounts she has access to specific systems like SAP as an application, Sage accounting as an application.
So the key is to bring in all of this information and create this access chain.
And we did touch a little bit about, hey, how can we identify these accounts that exist within these ecosystems?
How can we provide results and reports and dashboards within this ecosystem?
The first piece is identifying these accounts and bringing these into the ecosystem and tagging them appropriately.
So I’m going to show you a quick example of an LDAP directory that we ingested into the system.
And as we ingest this data, we’re also based on those common indicators, automatically reconciling those accounts as, hey, these are all technical accounts, which means they are non human accounts.
And we’re also breaking them into different types of accounts because a bot account needs to be managed a lot more different than a guest account or a shared account or a service account.
So you want to make sure that you’re categorizing them into different accounts and loading them into the system.
Of course, your indicators are not going to get you to the final state.
There are going to be still certain accounts that exist in the ecosystem that fall through the gaps of those indicators or those rules.
So you want a system that you’re able to go in and identify those accounts through the list and mark them manually as are they a technical account or not.
So you also want that administrative access to doing certain functionalities within the system.
Now, most important piece is once you identify these accounts, what is critical?
What is critical is to manage these accounts and monitor these accounts appropriately.
So what you’re doing is through the concept of controls in an automated way, managing these accounts.
So as an example, I identified fifty seven accounts and each of those accounts do not have a manager of that account, right?
That’s a risk because you’re not able to review those accounts if you don’t have a manager.
Then you’re seeing thirty one accounts that not even need a password, which means those are service accounts which are performing anonymous access.
Then you have three accounts that are set to passwords never expire.
You have a technical account where you’re not performing password rotation.
That is a big risk within the organization.
Before we hand it back to Veer, I just want to quickly show you the concept of technical accounts that might exist locally.
For that, I’m just going to quickly search through an account that exists within a database, right?
So in this example, I’m running a pre identified search and the account that I’m curious about is SAP SRV, right?
And SAP SRV is a service account that exists within a SQL Server database because it clearly says that repository is a SQL Server database.
But what we’re also able to do is attach this service account to the CMDB element and say, hey, this service account that exists within the SQL Server database impacts the payroll service that exists within your ecosystem.
So this way you’re able to identify that blast radius that I talked about, what can this service account impact within your organization?
Now, the other piece that is extremely critical is once you identify these service accounts, you also want to go through the hygiene practice.
In this case, the service account is an account.
It might be because the owner of the account left the organization, it just was left as an orphan account.
You within the tool should have the ability to come back and say, Hey, I want to say that this is not an orphan account, this is actually a privileged account and you want to be able to tag this as a privileged account and say, Hey, ownership left, This is Priv account.
Now what happens is within the system, you automatically tag this as a Privileged Account.
And what you can do once you tag this as a Privileged Account is assign ownership to the account.
So here I’m saying, Hey, I want go back and say, this account is owned by Samantha Schwartz.
So I’m going to go back to Samantha Schwartz, look her up and say, I’m going to attach this account to Samantha Schwartz.
So what you’re doing here is not only identifying the account, but also building hygiene practice on this account.
So now when you go back to the access chain of Samantha Schwartz, you also see this additional account, which was a service account that is now tied back to Samantha Schwartz as an identity.
And you’re seeing already that Samantha Schwartz through that account has these three different access rights within that SQL Server database.
So you’re augmenting the access chain of the user.
So know that was a quick run, weird.
I wanted to quickly run into the tool and show a little bit about how things work.
Switching- That was phenomenal because what you just illustrated there, think it took the fear out of everything for me, because we first of all talked about massive amounts of data that need to be found and collected from disparate systems that don’t share or communicate well, so you’re able to bring that information into the system.
It’s built to do that rough work for you.
But then the ability for you to really sort of, once that data is there, go through the correlation, the aggregation, adapt to the changes in the organization, and then start to build in structure and be able to go back and automate a lot of that process.
Because the scale of this is tremendous.
You can’t rely on spreadsheets like you said earlier.
That would be crazy.
So the power of the tool here to do that level of aggregation and correlation, but then to let people step in, because critical here, AI is a real powerful tool.
Does some amazing things. It also hallucinates.
You need to have the ability for a human to come in and validate the steps and to say, Yeah, this is true, or This is an exception, and I want to handle it.
You don’t have that leftover vulnerability.
So that’s amazing to me that all that capability is there because it makes this sound doable now.
It makes it sound like with that help, I can actually climb this mountain.
And just to summarize what we went through today, and there’s a number of areas we stepped on.
Basically, started with the idea of risk, that there is a tremendous amount of risk here.
This is not an area to be ignored, and it should not be ignored internally because the bad operators out there are not ignoring it.
They’re focusing on it.
This is the low hanging fruit for them when they’re trying to come into an organization.
And it really comes about because the nature of IT infrastructure is that things just expand.
I add new systems, people leave the organization.
Chaos is normal to introduce them to a platform through Entropy, so you need to have processes.
You need to be able to rein in the natural move towards chaos.
And that’s the challenge.
The challenge is how do I get my arms around all this information?
How do I go out and put myself in a position to be able to find those blind spots, to be able to then, once I’ve found the raw data, a method to go through and understand the nature of that information?
How can I bring in other data points to my platform that will allow me to be more informed about the system?
The ability to bring in detailed local account data and then bring in CMDB data and correlate that with identity information to me is phenomenal because you need to have all that granularity to start to be able to clean the system up.
But I think what you mentioned earlier and this is even more critical is the maintenance of this system.
This could be a great project.
It could run for a number of months.
But if it’s not a journey, if it’s not a lifestyle change, if it’s not something you’re doing ongoingly, it’s just going to fall back into disrepair.
And unfortunately, we have a lot of turnover in our industry.
People move, projects raise and lower in their criticality in the organization, so it’s important that this gets put in as a long term process.
It’s not just a one and done kind of model.
And from that, you get results.
You actually get a system where you can go upstairs to the CSO’s office and say, Here is validation of our increased level of risk mitigation in the organization.
Here’s examples of doors I closed.
Here’s bars I bought for the windows.
This gives you the ability to not only make a change, but to show the value, which is critical for any IT operation because you have to go back for budget.
You have to show you’re making a difference.
This is really a project that if you invest in this, I think you can definitely show the value back to the system.
I’ll turn it back to you, Akshay, for any closing thoughts as we’re just touching the top of the hour.
I appreciate everyone’s time today joining us.
And Akshay, as always, it’s a joy to work with you.
I learn something every time we talk. Floor is yours, sir.
No, appreciate it, Wade.
And if you want to learn more about this, please reach out to one of us, and we’d love to share and open the doors to more content about this.
This is an interesting topic.
I’m seeing a lot of organizations tackle this immediately because it’s becoming a big risk within the ecosystem.
So I’d love to have more conversations.
Thank you so much, Wade.
All right. Thank you everyone. See you on the next session.
In four weeks, we’ll have a customer talking directly about how they modernize our IT infrastructure with Radiant Logic. Thank you.