Securing Service Accounts

Securing environments has never been more tricky. Every day, we are using external applications. In the day of the cloud, these things are no longer executing inside our traditional security perimeters but outside of them. Every time we go to a website, such as this one, we are loading content externally, and loading it on our local devices. Sometimes this even means executing code, such as with javascript.

Our lives continue to be interconnected. We authenticate via Google, Apple, Microsoft or Facebook OAuth. We have cookies track our every move, across sites.

And even when we do have things execute in our internal perimeter, when we do things like update the application, we still have external trusts. Unless we are of course the application developer, we are given updates from these external vendors, which we load their logic and their binary into our systems. In order for many of these systems to work properly, they need privileges inside our environment so they can function properly. To do just that, usually applications are given non-human accounts, or "Service Accounts".

Sadly, most of the time, we do not secure our Service Accounts (SAs) properly. In fact, most organizations I talk to, don't prioritize these accounts so they usually have no visibility of them. More worrisome, these are traditionally the most privileged accounts in our environments. They tend to have privileges across multiple machines. They can't be traditionally MFA'd, since, well, how would an application respond to a MFA/Step-up Authentication request?

Even more sad, we almost never configure SA accounts properly. We allow them to do both interactive and non-interactive logons.

The only time an SA account should ever do an interactive logon is when it's misconfigured. The only other time you should ever see a SA account do interactive logon is when it's been compromised and being used by the adversary.

Read the above again. Most things in life aren't black and white.

This is.

In future blogs I'll show you how to secure these applications, or at least your environment in the low probability that the application goes haywire – either based on a bug or a supply chain issue impacting the provider of said binary. For now, let's continue double clicking in Service Accounts.

More insane, when we review Zero Trust security and we relook at identity protection, almost all organizations I've ever talked to completely ignore two things in their plan:

• Domain Admins/Enterprise Admins
• Service Accounts

What I mean by this is organizations have good intentions to implement Zero Trust, but it's almost always tied to the cloud. They want a cloud identity provider, where they replicate their user directory to. This is all good and all but... in reality, you're extending the problem. Authentications still will happen on-premises unless you are one of the few that doesn't want your network to work if you lose network connectivity or the cloud service your using goes down. Additionally, sensitive on-premises accounts, such as Domain Admin/Enterprise Admins (those managing the Active Directory) and Service Accounts aren't replicated, or at least shouldn't be. In fact, even Microsoft pointed this out as a best practice – there is no reason to replicate these accounts externally. They shouldn't be used externally and there is no need to further exposing them outside the organization as such.

So what this means is, Zero Trust and securing identity in almost all scenarios is only being applied to the cloud part of your identity plane (e.g. Azure AD, Okta, Ping, etc.). We aren't applying the same rules to on-premises authentication flows, to include our existing on-premises applications.

This is a massive flaw. As SolarWinds breach showed us, a compromised on-premises can lead

For now, chew on this content and see if you agree/disagree. Do you think its much more difficult to secure SAs than how I describe above? I haven't given you guidance yet on how to secure them, yet... but first we must agree on the approach before we get lost in the technical noise.

AH