Discovering, Provisioning & Deprovisioning Service Accounts

When Bank United’s Anne Gorman first tried to inventory her company’s service accounts, she was flying blind. 

“We didn’t know how many service accounts we had. We didn’t know where the service accounts were. Nobody even knew the passwords to think about what the service accounts ran. It was a hot mess,” Anne admits. (Watch the video).

Bank United’s struggle with privileged account sprawl is familiar to organizations of all types. The number of privileged and administrative accounts in an organization can range anywhere from 30% to 100% of the number of employees; accounts can easily fall off your radar, while privilege sprawl escalates.

Privileged accounts abound, persisting long after the people who managed them have left

Even with identity access management (IAM) systems in place and GPO controls in Active Directory, privileged accounts abound, persisting long after the people who managed them have left. An Intermedia and Osterman Research study found that as many as 89% of employees leaving their jobs retain access to at least one business application.

Shadow IT has led to an explosion of the number of privileged accounts inside a company, as business and technical users can license SaaS tools or cloud services without IT permission. When left unsecured, these accounts can become a backdoor for an ex-employee to gain access to sensitive systems and information.

Service accounts are the most slippery types of privileged accounts

Because they aren’t tied to a person’s identity, without strong governance, service accounts take on a life of their own. Managing these service accounts is a manual task with little oversight, producing incredible amounts of risk.  Even finding and documenting service accounts can be challenging and error-prone. Security and IT Ops teams rarely know the purpose of service accounts and so are generally unwilling to decommission them due to the risk of potential service interruption. ​

Cloud-based service accounts used to accelerate development cycles or as part of a DevOps workflow can be particularly difficult to find and manage. Containers and microservices get provisioned quickly and are often abandoned after use without proper disposal. Given the ephemeral nature of these credentials, they are usually not inventoried, updated, or controlled, meaning that cyber criminals can use them to gain easy access.

Below are proactive strategies that can help you stay in control.

Continuous discovery: find your service accounts

By revealing unexpected, unsanctioned accounts,  privileged account discovery can help identify potential insider abuse and external threats. PAM discovery should include Windows, Mac, Unix, and VMware ESX/ESXi accounts, as well as legacy or custom technology. In the inventory you build based on your discovery, it’s important to include necessary information on scheduled tasks, application pools, and all dependencies between systems.

Set up continuous discovery so information stays up to date as people come and go

Keep in mind, discovery is not a one-and-done activity. It’s important to set up continuous discovery so the information stays up to date as people come and go and systems change. We recommend discovery processes be automated and reviewed on a weekly basis at the least to curb privileged account sprawl.

Yup, finding forgotten service accounts is awesome. But discovery is only one part of effective privileged account governance.

Steps to take after service account discovery is complete

For human accounts such as domain admins

Once discovery helps you determine how many people have domain admin rights at your organization, you can identify opportunities where those could be reduced or shared. You can tighten your attack surface by removing accounts that are no longer in use. For example, as one of their first accomplishments with Delinea’s Secret Server, Allina Health was able to cut the number of their domain accounts by 75% (video).

To accomplish this quick win, you can replace individual named accounts with shared accounts and remove named accounts from the DA group. Or, you can configure your PAM solution to have it temporarily belong to the DA group only when utilized.

For services (non-human) accounts such as root access to infrastructure, development platforms, and more

Service account governance is somewhat more complex to manage than domain accounts that are tied to humans. In addition to discovery, service account governance should include:

1. Setting up standard workflows that must be followed before service accounts can be provisioned.

• Documenting the purpose of the service account. For example, is the account meant to manage Unix root access, spin up a server in a DevOps process, or a cloud platform?
  
  
• Assigning responsible parties for the service accounts. Even though service accounts aren’t directly tied to individual users, it’s important to name a specific person who has ultimate responsibility for the use of the service accounts.
  
  
• An approval process to provide sign-off for the provisioning of each service account. Perhaps only a small group of trusted IT or business leaders have the authority to approve the creation of service accounts. The rules could change depending on the business or IT function, or sensitivity of the systems or data involved.

2. Forcing periodic review of service accounts.

• Requiring that each service account in your inventory receives a regular check to determine if the original purpose for the account still holds true, if workflows are still appropriate, and if the people responsible are still in place
  
  
• Documenting the review. To show auditors you’re a responsible steward, not only do you need to regularly check the status of all your privileged assets and confirm who has access to them, but you also need to document that you performed the check. To meet PCI requirements, for example, you need to document regular service account status checks.
  
  
• When service accounts are no longer needed, deprovision them and document that they have been deprovisioned.

Added bonus: Once you formalize the service account governance process above, your reliance on discovery will decrease. You may still find the occasional rogue account, but the vast majority will follow a standardized, transparent process that keeps you in control.

Sounds great, you say. How can I make this happen?

We were inspired by how the State of Indiana leveraged Delinea Secret Server to develop a creative solution to service account governance. As Senior System Administrator Gordon Brock describes, Indiana standardized how their team provisions service accounts by creating templates for fill-in-the-blank service account creation that “eliminated all kinds of mistakes.”

We believe this type of service account governance should be possible for companies of all sizes, even if they don’t have a team of PowerShell developers to build a custom solution.

Today, no PAM system addresses service account governance out of the box. But, that’s about to change. Watch this space to see how Delinea is making service account management faster, easier and possible for everyone.