The Service Account Security Problem

Originally published by TrueFort.

Written by Matt Hathaway, TrueFort.

For a modern-day cyber attacker, initial access to an application is more than half the battle. With it, they are free to pursue their objectives, which likely include moving about freely to find data to sell or hold for ransom.

Most access to critical systems and data is facilitated by user accounts – digital identities tied to specific individuals. So, it’s no surprise that IT and security teams have focused so much of their time, energy, and resources on managing and securing them.

However, as any cyber attacker will tell you, one way in is just as good as another so long as it provides access. As for ways in, user accounts are like front doors. They’re usually well-locked and have lots of eyes on them.

There is, however, another type of doorway into most enterprise environments. It’s an entry point off the beaten path, generally not monitored, and often entirely forgotten by IT and security teams. I’m referring to service accounts, and software-to-software component identities that pose serious security risks to the many organizations that aren’t managing them closely today.

The nature of service accounts and their risks

Service accounts are similar to user accounts in one crucial way: they provide the access needed to run all kinds of things, including applications, virtualized compute resources, automated processes, and IoT device management. Enabling many key activities, service accounts facilitate access to systems, applications, and data. Unlike user accounts, however, they’re not tied to individual people. Service accounts are typically generated when a new application or service is being pushed to production. Their creation is, for example, one of the key steps in having an OS grant an application or service access to system resources and data it needs. Service accounts are, in a way, the equivalent of user login credentials – just for machines instead of people.

The nature of service accounts is what makes them a significant security risk. They’re not associated with any specific people, they’re usually embedded in lower levels of the technology stack, and they’re usually touched by humans only once – during installs. Often the people doing the installations use vendors’ default passwords – and those passwords are rarely, if ever, changed.

These characteristics make service accounts vulnerable because they’re initially set up and tested, but then, in many cases, they’re not actively tracked. That means they can easily get overlooked and become a risk.

For bad actors, these traits turn service accounts into easy doorways to step through to get into enterprise environments and access all the valuable resources within.

Current approaches fall short

There are best practices that companies can follow to try to manage and secure their service accounts more effectively. But these largely manual approaches are labor-intensive and time-consuming. They involve kludgy, manual processes of looking back in time to figure out which service accounts are associated with which apps and services, and which service accounts touch which physical and virtual servers or other IT resources. Even if all that discovery is made, there still remains the question of who initially created the service accounts and what passwords they used. Answers to all these questions are rarely readily available.

Then there’s the scary unknown of which particular applications and services use which service accounts. IAM and PAM solutions can be configured to include these accounts and log their use. Without the application-mapped relationships being known and visible, will a service account password change cause unexpected failures in critical apps or business processes? Chances are, the answer is yes.

The bottom line is that manually managing service accounts across dozens of spreadsheets is time-consuming, costly, error-prone, and risky. In short, it’s generally not a viable option.