System Access — Use It or Lose It

Business problem
SarbOx, HIPAA, or TJX — take your pick. Doesn't matter whether it's fear of regulators or fear of fallout from a security breach or both — every business needs tight control of all system access. The hardest part is ensuring that access, once granted, is removed promptly when workers

• leave,
• change job roles, or
• don't use the account.

"Elvis has left the building"
We need two separate and distinct sets of processes to track terminations of employees and non-employees:

• For employees, we use termination data from the payroll system (Who works here?).
• For non-employees, we create "positions" to give managers a familiar paradigm. Like employees, each position is assigned to a department and account code, has a supervisor, and there is no limit on the number of positions for any individual.

Unlike regular employees, non-employee positions have an expiration date of no more than one year in the future, forcing the non-employee's supervisor to renew the position annually. Without renewal, the position automatically expires — the equivalent of a termination.

When an employee is terminated, or a non-employee's final position (if they have more than one) expires, all system accounts for that worker are flagged in our homegrown user access application. The network account is automatically inactivated by a daily, scripted process, and all relevant system administrators are automatically notified to cancel accounts.

Musical chairs
Any organization has a certain amount of worker "churn" as staff are promoted, demoted or transferred. New responsibilities may require different system access, so every job change must be reviewed by the user access team.

User rights in major systems are grouped into generic job roles to minimize individually-customized rights. An automated process sends a daily e-mail to the user access team, listing any job changes in the past 24 hours, and system rights are modified as necessary.

Use it or lose it
If a system account is really needed, it will be used regularly. If it isn't used, it is simply one more vector for attack on the system, and should be inactivated. This principle is really just as important as closing accounts for terminated workers, but is not always given the same attention.

Now that we had data about last login for each account (System Access — Who Has What?), we could implement a security policy inactivating any system account that has not been used for 90 days. The only exception is the network login, which is left active as long as there is any active system account.

On the 23rd of each month, an automated process sends e-mails advising of any accounts that will be closed during the following calendar month.

• To supervisor of anyone with unused account(s), a list of all unused accounts for supervised workers; and,
• To worker with unused account(s), a list of any unused account(s).

If the account is no longer needed, no action is required by either supervisor or worker. If the account is still needed, the worker simply needs to use the account at least once prior to the date listed in the e-mail

Sample e-mail to worker with unused account

This process has worked beautifully for several years. We no longer have unused accounts cluttering our domain controllers and clinical systems. There have been only a few complaints, none of them serious enough to make us reconsider this policy.

Lessons learned

• With solid data about accounts and usage, it is possible to have tight control over accounts, using fairly simple automated processes.
• Managers will support good security measures if they are clearly explained and there are no surprises along the way.

Posted 19 March 2008