Test Accounts: Another Compliance Risk

By: Merritt Maximi

A major benefit associated with deploying identity management and/or identity governance into an organization is that these solutions provide the ability to detect and remove orphan accounts. Orphan accounts refer to active accounts belonging to a user who is no longer involved with that organization. From a compliance standpoint, orphan accounts are a major concern since orphan accounts mean that ex-employees and former contractors or suppliers still have legitimate credentials and access to internal systems. Identity management and identity governance solutions can help identify potential orphan accounts which the IT and audit teams can review and determine if these accounts should be deleted. By actively monitoring and managing orphan accounts, organizations can reduce IT risk and better manage their overall users and entitlements more effectively.

However, there is another type of account that can present many of the same problems as orphans, yet these accounts are often overlooked during the certification and governance process. The accounts in questions are test accounts which reside on almost every application. Test accounts serve a very valuable function, especially as organizations prep to move a new app or version from test to production. The test account is how IT can verify functionality. Because of the application requirements, most test accounts have full administrative privileges meaning that the account has access to every capability in the given application. The challenge is test accounts serve a valuable purpose and they cannot be removed completely.

The preferred best practice is to only have test accounts in test environment, or staging environment at most, but never in the production environment.

However, as is often the case in today’s highly complex, heterogeneous and distributed IT environment, test accounts often end up in production environments. Even worse, these test accounts often lie undetected or in a large grouping of unaligned accounts. And generally speaking, the longer an application has been in production in an organization, the greater the probability is that test accounts reside within those systems.

So what is the best approach for managing test accounts?

1. First, if a test account is to reside in a production environment (and there may be legitimate business reasons for this), make sure that this account is assigned the least possible privileges possible. This allows for some basic testing of the production system without exposing the entire application.
2. Leave the full test accounts for the test and staging environments.
3. Adopt an organization-wide common syntax for test accounts. Make them all called “test” or something else. This will make step 4 even easier.
4. Conduct periodic audits of your production environments to identify potential test accounts. This can be laborious manual work, but your auditors (and others) will thank you in the long run. The simplest way would be to start looking in the group of unaligned accounts (those not tied to any individual) as well as for other syntax like “test” or “12345” which are often what developers use to name a test account.
5. When conducting your periodic review of test accounts, you should also do a review of the test account activities. The helps determine if anyone was using the test accounts for actual changes that could affect the production environment. The impact could be indirect (e.g. policy changes that are done in staging environment may impact production if, by error, these changed policies are automatically pushed into the production environment as part of some bigger configuration rollout) and analyzing the activity can help prevent these issues.
6. Consider utilizing privileged user password management (PUM) functionality to protect all your test accounts, especially those in production. PUM solutions can help mitigate the risk of test accounts by securing those accounts in a secure encrypted vault., and can ensure appropriate access to the passwords based on a documented policy. Doing this also helps make the users of the test accounts accountable and also means that test account use is no longer anonymous as all user actions are securely recorded.

In summary, test accounts are not the enemy, but they do represent a potential risk that every IT organization should manage.