Protecting Service Accounts and Other Identity Security ‘Blind Spots’

Great to be here. Thank you for, for coming. What I want to talk about today is something that I think is really one of the areas of identity security that was left behind for many years and has become a pretty critical problem that attackers know about and are targeting. And I wanna talk about this problem and, and how we can potentially resolve it. And that is the problem of service accounts or non-human identities in general, in other blind spots that exist in our, in our ident security today.

So I'll talk a bit about what are those service accounts and why they're so difficult to secure, and then some of the things that we learned from companies that we are talking to about how they are still trying to, to overcome this challenge because I think it is one of the, the biggest gaps right now in identity security. So let's start from why are those service accounts specifically so risky and to so difficult to protect? So one thing that makes them very risky is that they're usually highly privileged, right?

A lot of times the, those service accounts, because of what they need to do, they require a lot of privileges, meaning that if somebody compromises them, they can cause a lot of damage. In addition, usually they have unknown dependencies. That means that we don't necessarily know where they're being used. We may think that they're being used by this system, but a lot of times we are not even aware that there are 10 other systems that are using the same service account. That makes them very challenging to protect.

Because if we try the traditional approach of putting them in a, in a privileged access management solution in a vault, one of the things that happen is that some applications will break. Okay? And the reason why they will break is because we thought that we are only changing it here, and we didn't know that there are five other or 10 other applications where somebody just reused the same account.

So we talked with a lot of companies that were trying to protect these accounts manually over the years, and they just gave up because every time they tried something broke, something in production, something critical, and they prefer to not touch it. The other thing about service account is that they are often misused or abused, meaning that people just use them for their own purposes outside of what the service account really needs to do and not treat them the right way. Because usually there isn't a very clear process, and if there is, it's not enforced.

So people just in order to make their life easier, can, can simply use them in a different way to save themselves time, but while doing it creates some risk. So when we talk about this problem, it's, it's really something that is true for non-human identities anywhere, you know, in the cloud or OnPrem. But I think that where the problem is, the, the biggest in most companies is around active directory. Because in active directory, not only these accounts suffer from these problems, but they're also using vulnerable legacy protocols.

This is some data that we collected from a few hundreds of our customers that were willing to share data with us, showing that many of these accounts are even using very vulnerable protocols like NTLM, even though the company taught that there's no NTLM left, but some of these automated processes just use it still. And obviously these accounts are very difficult to secure with all of the existing tools like MFA, which, you know, they can't really do, or Pam, which they're very difficult to onboard to.

But again, the other reason for the complexity is some of the bad practices that people have around them. So some of these bad practices that we've seen a lot, and I invite you to check if, if they also happen in your company are, for example, people using their personal account as service account. So they don't even create dedicated service accounts, they just use their own personal admin accounts to one, an application.

I remember we were once in a, in a customer environment where we were trying to install our own product, and as part of installing our own product, we need a service account. That query is active directory. And the person that was working with us just said, oh no, just, just use my admin account for that. And that's exactly what our product is meant to fix.

And, and still they didn't think about. Maybe that's a bad idea because it's so built into the way that we walk. People don't want to go to the process of asking for a service account. It's so much easier to use my own account to on a schedule task. So a lot of times we find that a lot of the, a lot of the regular accounts, the human accounts theoretically, are actually behaving like service account, the running schedule tasks, the running applications, and, and it's important to pick up on that behavior. The second issue is the opposite.

A lot of people use service account for their own purposes instead of asking for privileges. So if I don't have the privileges to do something, but I know the password of a service account, I'm just going to use that pass that service account to do my job because it's so much easier than asking for those privileges and explaining what I need them. So we say a lot of times that people do interactive log on with a service account or they use it manually to do the, their job. Obviously also a bad idea, but it's part of the, the issue of even having those service accounts unprotected.

The other issue is that people are reusing service account across many applications because again, if I created the service account once, that was hard enough, I don't wanna do that again. I'm just going to use that service account for different systems. And we see that a lot. And then we end up seeing a service account being used on hundreds of different applications and servers. So it's something that obviously increases the risk. 'cause if somebody compromise even one of them, they can take over everything.

And the last thing is the privileges that people give, but sometimes too much, sometimes more than you really need to do that job. You know, a lot of service account have admin privileges, even domain admin privileges because of the one thing they need to do, but that makes them accounts that if somebody compromise those accounts, they can take over the entire network. So is there a way to allow those service accounts to do what they need to do, but only that without causing any additional damage? That is really the goal, right? That's what we, we want to do.

But when we started the working on this problem a few years ago, we saw that before we can even protect those accounts. Some of these issues create even a more basic problem where people don't even know where their accounts are. They have no idea who those service accounts are, where they're being used. I'm talking about the most advanced companies. Okay?

I, I haven't, I don't think I've met a company in any size or any industry that was really in control of where dorf service accounts are and who's using them. It's, it's like doesn't exist.

So if, if that's the case in your company, don't feel bad about it. I think it's really everyone has the same problem. When we did a, a survey that we ordered from Osterman research called the state of Identity attack surface, one of the things we wanted to check was, was this. And about five, 5.7% of organizations thought that they had visibility into service accounts. Maybe they do, or at least they, they think that they do. Most likely they know about the official ones.

But even in those companies, there's probably other accounts that are used as service accounts that you don't even know about. And the majority of companies are aware of that. So they do know that they cannot defend against an attack that has, that compromises a service account. And there are examples of those, right? They don't wanna go into all the different attacks that happened. But here are a few examples that I think everyone knows of data breaches where service accounts were leveraged. And these are just a few examples.

There are many, I think that almost every large data breach of the recent year had a service account involved in, in some part of the process because it's just the most effective way to, to find a privileged account that nobody's protecting, that doesn't have MFA, that probably isn't in the PAM solution because it's too complex to put it there. It's just becoming the go-to target for attackers. They know that this is the, the easiest way. And it's not just those companies.

According to our own data, where we looked at a lot of data breaches that we stopped in our customer base in silver fraud, we saw that around 70% of the cases there was a service account involved. Okay? Just few months ago we stopped an attack by a scattered spider.

You, you may know them as the group that attacked MGM and, and many other large organizations. We stopped an attack by that same group on another Fortune 500 company where a product was deployed.

And, and it was exactly the same tactic, you know, every time using identities, using service account, using that to move laterally in the network and eventually breach other identity systems. I think it's, it's really the, the most popular approach right now. So I talked a lot about the problems. I don't want to depress you and I, I do want to also talk about how can we solve these issues, okay? Because I think everyone has them. We spent a few years trying to figure out how we can, we can answer this.

I'm not going to focus on our products more on an approach of what are the steps that it takes in order to solve this problem. And the first step in my opinion is to understand where are the service accounts, right? Who are they? So discovery basically, and discovery has a few ways of doing it. I think that you, you need all of them. And it starts from the simple part, the easier part, which looks at things like group memberships, okay?

You may have groups that you can identify that have service accounts in them groups or, or use naming conventions if you are organized enough over the years, sometimes the naming conventions can help. I, I have seen companies where at least many of the service accounts have a certain pattern in their name. And there are some other hints. For example, maybe in your company there are other attributes in active directory that identify employees. Maybe you have an employee ID in there, maybe you have an email address in there. A lot of times the service account will not have that, right?

They will not have an email address that will not have an employee ID or whatever custom fields you have. But that's usually not enough because all of that will only find the accounts that are officially service accounts. And the problem is much bigger than that. There are many accounts that look like humans, but they behave like service accounts because they've been abused. So the second step is behavior based discovery. Okay? That is using machine learning. I try to avoid saying AI in order to find that non-human pattern.

So usually the non-human identities, the, the automated processes will look very different in just the way they behave. They will do a scheduled task every certain timeframe going from this source to this destination. They don't sleep at night, they don't, they don't rest in the weekend. They just do the same scheduled job. And that's very different than human behavior. So there is a way with machine learning to pick up on that.

And, and we can show that to those who are interested. This is an example of how our product analyzes some of these authentications across the different protocols and sees those, those patterns. Sometimes you can see them with your own eyes like here, but even if you can't, that's one of the advantages of of doing it with machine learning. And eventually you get into this map of all the service accounts that you have.

Of course, there's also ways to automate that if you have other sources that know about service accounts, okay? Like CMDB or other systems where we can find information about which accounts are used by different systems. So obviously there are APIs and you can use that too, but most companies don't have anywhere where there's a complete picture of those. So once we complete the discovery, usually in, in, at least in large companies, you will find that there are too many of them. So the question is where to start.

And once we took the approach that you should just protect all of them immediately, but we understand that prioritization is really the next critical step. And in order to prioritize, there are a few types of service accounts that I think that it's better to start from, obviously the privileged ones, okay? Starting from your tier zero, you know, domain admins, but, but all the way down ones that are used by critical applications. So if you have applications that are critical to your business, they're using, you know, the, they have, they have customer data, they have other very critical things.

Even if you don't consider that account as a privileged account, that's probably something that you want to protect. Service accounts, that do interactive login, that's some something that service accounts shouldn't do. It's probably a human that is abusing that service account. And that's relatively easy to understand that. So you can find that person based on where it's coming from.

Ones that are very broadly used I think are, are important to start from because if, if you have a service account that somebody's used across many different applications, it's a relatively good place to, to focus on and, and fix a lot of places at the same time. And service accounts that have other risk factors, for example, they're using also a legacy protocol or they're coming from very problematic endpoints or they have all kinds of other attributes that make them more risky.

So after prioritization, you'll probably understand that you wanna start from this group and then move to that group and so on. And I think that's critical if you want to actually complete this journey. And by the way, we have helped companies that had even millions of service accounts to complete this process relatively quickly.

But, but by taking these steps and the next critical step, which I think was the most challenging, but that's where we really focused a lot of our efforts in building our products after we completed the, the first steps was protection. How do you actually prevent someone from using the service account in a bad way? So the problem is, as we said, service accounts cannot do to additional MFA, right? They don't have good pumps, so they can't really do the usual type of MFA that we use to protect humans, onboarding them to a PAM solution.

Also, not a very reasonable approach, but what we figured is that there can be a different approach that really comes from a zero trust perspective that we called virtual fencing. And the idea was to learn what each service account is doing. Okay? So if we learn that the service account is coming from A to B every day, and usually you can, you can build those patterns, we could create a control that only allows it to be used in that way. Meaning that if somebody will try to use it to access something different or coming from somewhere new, you may want to alert on it or to block it, okay?

Probably first alert just to understand, you know, what is it and have a chance to go talk to that application owner. But once you did that and you understand that this account is behaving the right way, probably apply enforcement. Now what if enforcement really means, and this is just the way it looks in our product, but you know, conceptually it'll require, in any case, an ability to enforce real time controls at the directory level. So what I mean by that is we need to connect to the directory.

In this case it's active directory, but the, the, the solution and the concept itself is true for every type of identity store. Okay? In this example, it's active directory and you need to be able to intervene in the decisions that active directory is making so that if somebody is trying to authenticate with this service account in a way that it shouldn't, we tell active directory to not allow this access. As long as the account is doing the right thing, there's no problem. But if somebody is trying to use it anywhere else, they will not be able to, or it'll trigger an alert.

There are obviously other workflows that you can implement. You can ask for approval, you can do all kinds of other things. But the important thing is that you can actually prevent, by the way, why do I think that prevention is important in not only alerting? Because I think that with the way attackers are automating what they do, which obviously has to do with, with AI attacks are becoming much faster. A few years ago we used to think that detecting attacks will give us enough time to respond to them and, and stop them.

But I think it's becoming more clear that attackers are becoming more automated and faster. So we have no choice but to prevent threats in real time and not just wait a few hours later for someone in the SOC to notice it.

And, and this is really the approach here. And then the last step once you can do this is to automate, because you can't really protect these accounts one by one. Okay? Even if we discover them, even if we understand where they're being used, if you have hundreds of thousands of them, even if you have 500 of them, it's probably too complex to go one by one and and, and do it manually. So what it takes is one of two approaches or, or usually a combination of them. One approach is using a product like ours to build the automation within this product, okay?

So we can move every account at its own time from discovery to analysis, to alerting, to blocking based on whenever this account is ready. Okay? So if we see that the account is behaving in a very predictable way, we move it into alerting. If we see that there are no alerts, we move it into enforcement. And you can do that, you know, automatically even across a million service accounts. But that's mostly a good approach for accounts that are already there, okay?

So if there are accounts that are already there and you have no idea what they're doing, that's probably the best thing because you don't know what the policy should be. So let's automate this intelligent policy of creating the policy, but for new accounts, ones that you are creating now, why do this? While you are creating them, you probably know what they should be doing. So let's at least create automation from today forward, you know, to your IT tools, your CMDB or other tools that as part of that process will already create a policy. Okay?

So this is where the automation will create policies and update those policies ongoing as part of the IT processes so that the councils are protected from day one. This is it, and if you have any questions on this, please come see us. We are downstairs at booth 11, and if you want albedo after this session, happy to show you more. I hope this was valuable. I I hope that a lot of you will take this step of, of trying to tackle this very hard problem. And thank you very much for coming today and for your time. Thank you. Thanks.

Thanks Ed, for covering this very important topic. We've got a few questions here. Quickly though, talking about the processes of multiple thousands of service accounts being cleaned up. What timeframe exactly are you speaking about when you say relatively quickly?

So, I, I'll, I'll take an extreme hard case. Okay. For one of the largest banks in the world that had hundreds of thousands of service accounts, it took us about two months end to end, which I think is relatively short for this kind of project, all the way from installing the product to doing the discovery and all of that. There are of course companies that do it slower because of their own considerations. They want to take it slower step by step. But when you really want to solve this problem and go fast, I think that's, you know, a few months is roughly what it takes at most.

If you are a very large companies. We also have small companies that have done this in a matter of a few weeks, but I think that a few weeks is the minimum because just the discovery phase itself takes a couple of weeks no matter what. So that's the timeframe. Another Quick one. How is virtual fencing better than having exact acis in the directory? So a lot of times there's a, a better level of control that you can achieve with that.

It's a, it's a long explanation, but I suggest to the person who saw it to reach out to me, there was, my email was there in the last slide. I hope you, you got it. It'll give you a much better, more granular level of control, including in systems where you couldn't do that with acls, but it, it's, it'll be, I will be glad to go deeper on this.

Okay, Great. Thanks.

Hey, ve, Thank you very much everyone.