Headline
For Service Accounts, Accountability Is Key to Security
Modern networks teem with machine accounts tasked with simple automated tasks yet given too many privileges and left unmonitored. Resolve that situation and you close an attack vector.
Source: Westend61 GmbH via Alamy Stock Photo
COMMENTARY
Over my 32 years in cybersecurity, one painful constant has been managing the risks associated with network service accounts.
Service accounts are supposed to be machine-to-machine accounts that perform repetitive and automated scheduled tasks without human interaction. Common examples of service accounts include running applications on operating systems, databases, automated backups, and network maintenance. They should have extremely limited access rights, disallow human interaction, and only perform their intended function.
Rare is the management model that addresses service account concerns adequately from a security perspective. Best practices reduce the ability of threat actors to use such accounts to move laterally within the enterprise, undetected by our monitoring systems.
Trouble Points of Service Accounts
Every organization has service accounts. Every organization would also like to have fewer accounts and better monitoring and control for the accounts they must have. Threat actors understand the security risks of service accounts and take advantage of:
Lack of visibility. Service accounts can have complex dependencies in processes, applications, database structures, and programmatic systems. These accounts can be exceedingly difficult, if not impossible, to monitor and properly secure.
Difficulty in monitoring. Since service accounts are not typically associated with a specific person, monitoring the logs can cause confusion and complicate incident investigations. This can result in networks being exposed to threat actor actions and lateral movements, while the malicious actors remain completely undetected as they move around in the network.
Complicated nature of evictions. If threat actors breach your network and you need to evict them, every single password must be changed over a brief period, some more than once. This is when service accounts can really become burdensome and complicated. To commit to an eviction, you must change every single service account password. If you do not have a good inventory and understand the functionality of all service accounts, you should not attempt an eviction. In such a case, the few service accounts you could not change will probably be used by the threat actors.
Common Gaps in Knowledge
Many times during an incident response engagement, I have seen the following tendencies among organizations with regard to service accounts:
No one knows how many service accounts exists or how they are used.
The passwords have not been changed in years, and no one knows how to change the password — or what will break if they do.
No one knows why a service account exists or who owns the account.
The organization doesn’t have a process for monitoring and securing the service accounts.
This is why it makes sense that threat actors gravitate toward service accounts. Often, these accounts have unnecessary rights and access.
Developing a Comprehensive Strategy
Understanding the problem is just the first part of developing a comprehensive strategy. Let us now identify the steps to solving security issues concerning service accounts.
Inventory all the service accounts. This can be done programmatically, using PowerShell or Active Directory tools.
Once you have a good inventory, assign an owner to each service account. This brings human insight and accountability. You may find that some service accounts are no longer needed.
Determine the purpose of all service accounts. How is the account used, and what does it do?
Document this information very carefully.
Finally, now you can formalize your service account program in a way that brings more security and oversight. You could choose to add your service accounts into a privileged access management (PAM) system, which would be ideal. However, remember this can be a long and tedious endeavor. While it is worth the effort, do not think it is not going to require lots of time and effort.
Next, whether or not you used PAM, develop a formalized audit reconciliation program around the use of each service account. This will heavily depend on the service account owners. An organization should require every owner to attest to the continued need for the service account periodically — I did this every six months — and accept the risk associated with the account’s continued use. When the account owner accepts the risks associated with the service account, they change the password for the account.
Ideally, you can automate this process by using software platforms designed to manage risks and assist organizations in governance, risk, and compliance (GRC) issues. In such a system, if the automated workflow does not get processed correctly, the service account will be automatically disabled. If the service then remains disabled for a set period, it will automatically be deleted. This brings accountability to the management of service accounts.
This comprehensive strategy will reduce risks around the usage of service accounts. The most important thing is that the strategy ensures all service accounts are documented and holds a specific person accountable for their continued usage. This accountability, along with routine password changes, will dramatically reduce risks and help reconcile this important and often overlooked security weakness.
About the Author(s)
Principal Consultant, Secureworks Incident Response Team
Patrick B Barnett is Principal Consultant within the Secureworks Incident Response Team. With more than 26 years of experience in IT and information security, Pat architects and implements custom cybersecurity solutions for networks across the globe and has managed over 1,000 cyber incident responses over the last 25 years. Pat is passionate about seeing cybersecurity done right and is committed to aiding organizations in defining proper policies, procedures, and mechanisms to respond to any size event. Pat has a Master of Science degree in Computer Engineering and Business Administration and several post-graduate cybersecurity certificates from MIT and Stanford University. Pat holds the following certifications: CISSP, HISSP, PCI QSA, PCPIP, CISM, CEH, and CISA. Professional affiliations include ISSA, EC-Council, ISC2, and PCI DSS.