An area of constant challenge is properly defining system users and roles to perform required tasks. This is less of an issue for server systems, but a significant issue for end user systems. In order to install software and perform some system functions, the operating system may require elevated privileges. Instead of leveraging a software management system to install requested software, users are given permissions temporarily in order to perform the installation. There are two issues with this scenario. First, software needed to perform a business function should be owned and maintained by the organization allowing for version control, patching, and proper licensing. Second, the organization's IT standards should have rules in regards to non-business software installed on business assets. In fact, one of the biggest drivers for BYOD initiatives is this very subject, software. However, these legitimate and non-standard install requests force the IT support teams to provide elevated access on systems. These elevated privileges then get used to inadvertently install malware as it requires these elevated privileges most times to install and cause havoc.

Organizations should have a method to provide the software being requested or only temporarily provide the elevated privileges. The norm is that these temporary privilege elevations remain and are not temporary at all. In haste, sometimes users are just added as system administrators as this is commonly the easiest path to resolving the incident ticket and will make the user happy.

When these accounts become rogue, meaning the user is no longer with the organization or due to incorrect permissions they were able to create more accounts, the organization becomes vulnerable to account misuse, unauthorized access, and malicious activity. The process to gain elevated privileges should require additional scrutiny and only in accordance to the security architecture and policies to protect the organization's data and assets. If these requests become the norm versus the exception, perhaps the organization should re-evaluate its position on enterprise software. If the software cannot be purchased, maintained, and installed by IT, then it should not be on enterprise systems. This is the case where one issue creates a more critical issue of regular business users having permissions that only the internal IT support staff should have. Because of this, the same IT support teams are tasked with responding to increased malware in the enterprise and supporting non-enterprise applications.

In order to ensure that there are no rogue accounts on systems, the enterprise should perform user account auditing across all systems on a regular basis. Once all accounts are discovered, they should be referenced to understand their purpose; if rogue accounts are found they should be disabled. Also, maintaining a termination list to reference for accounts that should have been disabled or deleted at the time of termination should be a formal process. Without auditing the environment for rogue accounts or accounts that were supposed to be temporary, there will be an increased risk of misuse and unauthorized access. If the accounts were used to install software or for a non-interactive process, chances are that the accounts have elevated privileges leaving the system and data vulnerable.

There are tools to aid in this discovery and these should be a part of the overall system and user management processes within the organization. The tools should be run, at a minimum, quarterly to coincide with the most generally accepted password expiration standards.