The Service Accounts Guide Part 2: Challenges, Compliance and Best Practices

From April to early June of this year, a threat actor referred to as UNC5537 wreaked havoc on various Snowflake instances and its customers. 

The incident put the Snowflake name all over the headlines, causing a sharp decline in stock price in May when the incident first made headlines, and didn’t see a rebound until July after a roughly 23% decrease. 

The material impact was undeniable… but was Snowflake at fault?

The reality of this ‘incident’ was not a matter of compromised or unauthorized access to Snowflake’s enterprise environment, but rather a lack of best practices for securing the service accounts customers use to connect their Snowflake instances to other technologies. 

Each of these accounts had only a single factor of authentication—a password—to protect it against unauthorized use. A single credential stood between many organizations’ most sensitive data and the threat actors of UNC5537. 

In the previous part of this guide, we covered the origins of service accounts, their different types, common pitfalls, and key strategies for addressing them. In this part, we will explore the challenges of managing these non-human identities, and sprinkle in tips for securing them like a pro.

Part 2: Challenges , compliance and best practices

Service accounts, although not a new concept, are prone to mismanagement, security threats, and compliance issues. An example of the latter is the latest PCI DSS 4.0 which emphasizes some very specific requirements around the management and privilege of system and application accounts (non-human identities). 

Let’s examine some of the challenges related to these identities.

1. Who owns this thing, anyway?

Picture this: a service account is created to run a batch job. But then… who’s responsible for it? Jim in IT, who left three years ago? The developer who “forgot” to tell anyone about it? The dog? Anyone? Bueller…

Ownership ambiguity is a huge issue. Without a clear human in charge, these accounts often fall through the cracks, becoming security liabilities faster than you can say “forgot password.”

Oftentimes we begin our practice with a clear owner established – after all, someone had to create the thing, right? The problem often occurs during leaver/mover processes where that individual changes teams, changes jobs, or leaves the organization. 

This is where the breakdown happens, and ownership is typically lost because most organizations do not have a process to re-establish or attest to ownership of these identities during a transition or major lifecycle event. The accountability is lost, and the service account is egregiously forgotten about, which leads us to problem #2…

2. Zombie accounts (a.k.a. Unused service accounts)

Every IT department has them: unused service accounts lurking in the shadows like digital zombies. They’re not doing any work, but they sure are inviting trouble. Attackers love these forgotten accounts because no one’s watching them. It’s like finding an unlocked treasure chest in the jungle.

This is what happened at Snowflake and at Okta. These identities fall by the wayside without any clear understanding of their purpose or the business process they support. On a long enough timeline and with enough persistence, they can fall victim to an attack from a sophisticated attacker seeing an unmonitored, undetectable entry point into your critical systems. 

This problem is often exacerbated by the fact that the credentials for these accounts typically are long-lived/never expire and are rarely rotated. Take into account how frequently these credentials are given overprivileged permissions just to get it working

3. Compliance reliance

“We love regulations – and are always 100% ready to pass an audit” – said no technologist ever.

The latest PCI DSS 4.0 standards demand some interesting new controls and considerations for system and application accounts (service accounts), their privileges, and how they are used. What’s more, a number of cyber insurance carriers are starting to include language around controls for service accounts—and their premiums are even higher for those whose controls aren’t up to snuff.

What can we do about it?

The industry is changing—and for the better—by aligning best practices and security with tooling that helps support service account hygiene fundamentally and at its core. 

1. Trim the fat

Does your service account need access to everything? Probably not. Start with the Principle of Least Privilege—give your identities only what they absolutely need to do their job. While you’re at it, go full-stop on unused accounts. If a service account doesn’t spark joy (or isn’t actively used), decommission it. 

2. Rotate those creds… Or, get rid of them altogether 

Manually rotating credentials is about as fun as untangling holiday lights. Automate the process and save yourself the headache. Frequent updates mean less exposure for credentials, and automated tools ensure the rhythm keeps going without a hitch. Pro tip: don’t let your credentials live longer than a goldfish.

But imagine for a second a world without passwords. Welcome to passwordless authentication, where service accounts rely on ephemeral tokens or certificates instead of “Password123.” New technology standards are emerging around short-lived credentials and access policy controls that will make the traditional service account username and password combination obsolete.

3. Keep an eye on the bots

Your service accounts might be non-human, but that doesn’t mean they shouldn’t be supervised. Implement advanced monitoring tools to catch weird behavior. If an account is suddenly accessing sensitive data at 3 a.m., something’s fishy—and it’s not just the leftover sushi in the breakroom fridge. Monitoring keeps your accounts in line and attackers at bay.

The next part is a live workshop about common service account vulnerabilities, how to fix them, and how attackers might exploit them. Stay tuned!