Michael Byrnes, Director of Solutions Engineering, iMEA at BeyondTrust explores service accounts and the challenges that accompany them and how to mitigate risk
Service accounts are a particular type of non-human privileged account used to execute applications and run automated services, virtual machine instances, and other processes. These accounts can be privileged local or domain accounts, and in some cases, they may have domain administrative privileges. This high level of privilege facilitates the smooth operation of many IT workflows, but a single service account can easily be referenced in many applications or processes. This interconnection, along with the critical nature of their usage, makes them very difficult to manage.
So let’s delve into how service accounts work, some of the common challenges in managing service accounts as well as recommended best practices and solutions for properly managing and securing these accounts.
Inner workings of service accounts
Service accounts run automated business processes and are used by applications, not people. They can be stored in services, tasks, COM objects, Internet Information Services (IIS), SharePoint, databases, and applications. A single service or process account may be referenced in multiple places.
Many servers use local accounts — like root on Linux and administrator on Windows — to run persistent applications, whether or not someone logs into the machine. For example, a web site would be an example of a persistent application, as would a database or other line-of-business application.
Service accounts are needed for these persistent applications so that they can perform actions on behalf of the users of the application. In other words, service accounts are proxies for performing limited actions for users that have no access to sensitive data and systems.
In many cases, the mechanics of service accounts means that an account must be known and verifiable to, not only the application, but also everything that the application interacts with. Consequently, the service account is generally a powerful access credential.
Generally, service accounts are created and configured by the package manager during installation of the service software. So, even as an administrator, humans are not (and should not) be directly in charge of the creation of service accounts.
Key challenges
Proper system functioning and business continuity depend on the functioning of the underlying services. The compromise or malfunction of a service account can potentially cause widespread system outages, particularly if an account is associated with multiple services.
Passwords — The consequence of the service account structure means that any password change of a superuser credential must not only be performed in the authentication system (i.e. Active Directory), but also in every service/application that stores the password for that same credential. So, not only must you update the authenticator, but also all references. Updating all the places where a service account is stored is known as propagation.
If you miss any of the places that have a stored password, the wrong password will be used and that could spur cascading system failures. The use of an incorrect password by a service could even cause the operating system to think that the account is under attack and, consequently, lock out the account. This means that every service that uses that locked out account will now fail too.
Because of the implications of passwords that don’t correctly sync, many organisations simply choose to ignore the issue, rather than risk downtime. Consequently, service accounts are often configured with non-expiring credentials that remain unchanged for years!
Access — Service accounts have privileged access on the local system and, in some cases (i.e. Windows domain accounts,) access to off-system resources. While a service account rarely requires Domain Admin level rights, they often are over-privileged as an easy way to overcome any potentially unforeseen operation challenges that may impact service continuity.
Administration — Since service accounts are not directly associated with a human identity, access of service accounts requires sharing of the credentials for those accounts. This sharing of credentials dilutes accountability and makes oversight of service accounts difficult.
Centralised provisioning of service accounts has traditionally posed a challenge due to the disparate origin of these accounts (Windows, Unix, Linux and the Cloud have separate accounts, provisioned individually when the software they manage is installed). As a consequence, many organisations manually provision service accounts.
Given the complexities around service account management, some IT teams take the approach of manually managing service account credentials. This is a tedious, error-prone, and potentially disastrous, process. Manual rotation requires identifying everywhere that credentials exist and executing a change whenever the credential is used. An errant credential change can disrupt services and cause critical systems to go down. Additionally, just as with other instances of password management, humans invariably fall into the trap of using easy to remember credentials, or reuse credentials across multiple accounts. When credentials are re-used, the exploit of one instance can potentially lead to the compromise of all the accounts that share the same password.
Visibility and auditing — Service accounts create some visibility issues that are common to all types of machine/non-human accounts. Since they typically run in the background without the interaction of a human user, they may avoid scrutiny and oversight, so long as services seem to be operating smoothly. Additionally, most organisations suffer from a sprawl of service accounts, including orphaned accounts that are forgotten and/or no longer used. It’s possible that multiple identities (users) have access to a service account, and share the same login details. This means it may be impossible to connect a single user’s actions to any changes to the service account.
Put simply, most organisations have serious service account lifecycle management deficiencies when it comes to addressing provisioning, onboarding, enforcement of security best practices, session auditing, and de-provisioning, etc.) of service credentials.
The management challenges of service accounts also encapsulate why the accounts are praised and sought after by hackers.
Best practices
The best approach to effectively securing services accounts is two-fold. The first element requires an immediate plan to identify and bring all accounts under centralised management. The second element entails implementing an ongoing program based on automated onboarding and management of new accounts.
Step One: Identify and centrally manage all accounts
If you do not know where all your privileged service accounts are, you cannot fully control and audit their usage. The first priority, as with all other types of accounts, is to deploy a method of continuous identification and cataloging so they can all be brought under centralised management.
Step Two: Automate management of accounts
Given the dynamic nature of IT environments, auto-discovery capabilities save time and ensure that no account is left unmanaged. Automatically profiling and classifying accounts ensures that new service accounts are immediately brought under control, removing the complexity and risk of manual administration. This enables complete visibility over all privileges in an environment.
Next, privileged credentials (passwords, SSH keys) associated with service accounts need to be centrally secured within an encrypted credential safe. Access to these credentials should be controlled and monitored to mitigate the risk of misuse.
Finally, as service account credentials are changed, the automatic propagation of credentials to all places where they are referenced is a critical factor in preventing systems failures and downtime.
In addition to these steps, you should also apply a few additional best practices including applying the principle of least privilege (PoIP) by creating accounts only with the minimum privilege required to complete a certain task, refraining from putting service accounts in built-in privileged groups and having a “worst-case” plan for outage scenarios that may disrupt the availability of your service account password management solution.
The bottom line
Service accounts are critical to the smooth operation of most IT systems. Manual management of these critical accounts simply won’t scale or meet the security and auditing requirements of modern enterprises.
Today, organisations can leverage solutions to help them automate the discovery and management of service accounts, while securing, controlling, and auditing access to them. Automation is essential to mitigating the risk of service account sprawl and protecting your enterprise from the risks of compromised privileged credentials.
Commentary: Amr Alashaal, Regional Vice President – Middle East at A10 Network
Cybercriminals had a busy year in 2020, with rapidly increasing numbers of distributed denial of service (DDoS) weapons, widespread botnet activity, and some of the largest DDoS attacks ever recorded. As COVID-19 drove an urgent shift online for everything from education and healthcare, to consumer shopping, to office work, hackers had more targets available than ever—many of them under protected due to the difficulty of maintaining security best practices in an emergency scenario. At the same time, the ongoing rollout of 5G technologies has accelerated the proliferation of IoT and smart devices around the world, making unsuspecting new recruits available for botnet armies to launch crushing attacks on a massive scale.
In our ongoing tracking of DDoS attacks, DDoS attack methods and malware activity, A10 Networks has observed a steady increase in the frequency, intensity, and sophistication of these threats, most recently in our State of DDoS Weapons Report for H2 2020, which covers the second half of the past year. During this period, we saw an increase of over 12 percent in the number of potential DDoS weapons available on the internet, with a total of approximately 12.5 million weapons detected. The good news is that proven methods of protection continue to be effective even as threat levels rise. In this article, we’ll talk about recent trends in DDoS activity and how to defend your organisation against this common and highly damaging type of attack.
Commentary: Mohammed Al-Moneer, Regional Director, META at Infoblox
As of the end of 2020, many organisations had still not implemented necessary cybersecurity to protect this far more distributed user base. Email, a vital and essential tool, remains the top threat vector used to attack both government and businesses of all sizes. Despite training and warnings, users continue to open suspicious emails, both in their business and personal accounts. They click on malicious email attachments and URLs and view websites not generally associated with business use. Proprietary business information is at risk when workers use personal and business instances of applications such as Office 365 on the same machines, collaborate within clouds and connect to an ever-increasing number of SaaS clouds that are not work related and not sanctioned by their IT department.
For all of these reasons and more, cyberthreats remain alive and well. Threat actors will innovate, adjust and sustain proven methods in 2021. Rogue nation-states and organised crime will continue to build on their offensive capabilities. Accurate intelligence about timely, relevant threats enables an organisation to make thoughtful, targeted improvements to its defenses and lower its risk.
To stay up to date on the latest, trends, innovations, people news and company updates within the global security market please register to receive our newsletter here.
Media contact
Rebecca Morpeth Spayne,
Editor, Security Portfolio
Tel: +44 (0) 1622 823 922
Email: editor@securitymiddleeast.com
