For many software applications, a set of generic usernames is shipped with the product. These accounts oftentimes have administrator-level privileges and are typically used to complete initialization and general setup of the system. Once setup is complete, these usernames and their corresponding privileges should be changed. What often happens, however, is that this task becomes one of those “it’s on my to-do list” items that always has another priority ahead of it. Only when an unauthorized change occurs and administrators are not able to track down who made it, does this change become a top priority – a day late and a dollar short.
Your security team will love you for moving off of generic usernames…the sooner, the better. Each FTE and regular consultant should have their own username and only the appropriate privileges. Remember to adhere to any password restrictions (if one is not in place, I would recommend a minimum of 5-7 characters, with at least one number and one metacharacter). But what about vendor support staff who need to remotely access your system? Opinions differ on this. I’ve come across sites that insist that anyone logging into the system have their own login. I’ve also seen sites that deploy support usernames where passwords are reset on a regular basis. One particular site that works well uses the following model:
- Five usernames are set up specifying the vendor organization and the role that vendor support needs to access (i.e., CERNIAC_NURSE, CERNIAC_ADM, CERNIAC_RAD, etc.).
- A script is written to reset the passwords for these usernames daily at 8 a.m.
- To access the system, an authorized, in-house employee (manager, team lead, etc.) calls their organization’s help/support desk to notify them that a specific employee of the vendor organization will be calling for the password to a specific username.
- When the vendor employee calls the help/support desk, the help desk personnel verifies the employee’s information and username and then provides the password.
With this method, the site allows support to access the system without inundating its list of accounts with one-off names. Additionally, the site has a running log of who accessed the system and when. Privileges and restrictions are maintained by the security on the account itself.
Although the task to move completely away from generic usernames seems like a task that can be put off for another day, swift action to move away from this schema will prevent the question, “WHO MADE THIS CHANGE IN PRODUCTION AS ‘SYSTEM’?!
Prognosis: Replacing generic usernames with specific passwords and appropriate privileges for each user will help keep Millennium safe from unauthorized changes.