The most difficult access to monitor is the privileged access to sensitive data. Because the role requires access to data, and sometimes, in non-traditional methods, it can be difficult to determine malicious intent and to confine data only to approved systems. When privileged users access data, it is typically in a direct fashion over secure communication channels, making it near impossible to know what specific data is being accessed and potentially transmitted to other systems not initially intended to securely store the sensitive data. Data access monitoring may help but if the access is intended as per the role and access permissions, this becomes a non-absolute method to monitor access and determine intent because access is granted. To help provide a better understanding of expected data access and actions, profiling "normal" behaviors can highlight the anomalies, behaviors outside the expected "norm".

It may become a requirement to protect the data in a fashion that access is monitored but certain actions not specifically required for the role are restricted and enforced by a technical solution. Arguably, this is the best practice—a simple least privilege enforcement—though many times this implementation is uncommon. In order to enforce this method, controls need to be implemented on the privileged user's system and access may need to be brokered by a security system to mitigate transmission of sensitive data to less secure systems.

Because this user type has, in essence, the keys to the kingdom, it is imperative that every action the privileged user executes is monitored for anomalies and other behaviors beyond the scope of the assigned role. This will require authentication mechanisms for each action that is specific to an individual and not a group of users. An area where this is an issue is with database administration and the use of additional elevated accounts within the database infrastructure. A series of monitoring logs including database activity must be carefully correlated to ensure an individual can be associated with specific actions. A regular audit of actions should be performed to ensure the actions are within the bounds of the role and any discrepancies accounted for and approved by management. There are several commercial tools available for privileged user monitoring but management of the solutions and review of the output must be a mature process with accountability for unapproved actions.

System administrators may arguably be the holders of the keys to the kingdom with more access than the database team. In many cases, the database servers are implemented in a configuration that allows system administrators access to the data content while not actually being in a database administrator role. This is a flaw in implementation, but can be discovered and mitigated through a review of configuration. Apart from databases, all other data residing on systems in the enterprise is accessible by system administrators regardless of the owner of the system and sensitivity of the resident data. This level of access across the enterprise should be taken very seriously and monitored heavily as this is the most abused access in the enterprise. Leveraging system-level monitoring capabilities is a method to achieve auditing privileged user system access.

Another method is to leverage encryption technology that is able to provide access based on the authenticated user and rightful owner of the resident data on a system. It is understood that trust is a significant part of being an enterprise user, however, trust alone will not thwart human behaviors of curiosity and personal gain. These are all intentional actions so far; but what about the unintentional consequences of privileged system access by the standard enterprise user?

When the standard user has gained privileged-level access to their system, typically to install an application, the system is left vulnerable even to a simple user error in judgment in additional to intentional actions. It is a common occurrence in the enterprise to have users request local administrator permissions in order to install a software package, but this access if really needed should be temporary in nature. The primary cause for malicious software installation is the unintended consequence of a user action; but this has also led to some of the most notable hacking instances in recent history, one example being RSA. RSA, the makers of SecurID, were hacked using a spear-phishing technique, when the user opened the e-mailed attachment, malware was installed as the user which held elevated system privileges. Once installed, it allowed hackers to gain the information they needed to further exploit RSA systems and compromise the most critical data supporting the SecurID product.

In the previous example highlighting the dangers of elevated user accounts, a simple click to open an infected link caused serious damage to RSA. This is such a common occurrence that new security technologies are flourishing such as the FireEye Malware Analysis System, which is able to examine malware in real time from these attack methods and provide mitigation.

A process should be developed to revoke the access once the reason for elevation has be achieved, either in an automated fashion or through manual action. If possible, enforcing all application installs via software package delivery or by PC support will ensure users do not gain and maintain elevated system privileges. There are capabilities within Microsoft Windows such as Group Policy that can be used to temporarily elevate a user's system privileges, and then remove them after the requirement is fulfilled.

Monitoring the actions of users with elevated privileges even on end user workstations is advisable for a small scope of actions, so that remediation efforts can be managed. In any instance of privileged system access, monitoring and regular auditing is a must to reduce the likelihood of system compromise, misuse, and data loss through user actions.

Most applications have roles defined such as user, power user, report user, administrator, and so on. The purpose is to limit the access various user types have to the data resident or accessible by the application and actions that can be taken within the application. Usually, the administrator is the only role with the ability to fully manage the application including adding other users, managing application settings, and full read, write, edit access to data. With the administrator role comes additional responsibility that should be assigned cautiously, monitored, and managed meticulously to reduce the impact of misuse, and unauthorized access through poorly managed accounts assigned by this role.

Because the privileged application role has the permissions to add accounts, this activity should be monitored and should follow a formal change process based upon the data resident in or accessible through the application. It is in general a best practice to enforce change management for all accounts added to a system or application, but the level of review may be limited based on the requested access and the criticality of the system and data.

Rogue application accounts can be detected through a regular audit process that should occur at least quarterly. This process should also be leveraged to remove old accounts that should no longer reside in the application. For example, terminated employees.

The best solution for account management is to use a centralized authentication, authorization, and accounting solution that allows for simplicity in account management across enterprise applications. The central system should enforce a policy of consistent password change requirements (not to exceed 90 days) to limit the window of compromise, though it should be mentioned that a shorter window should actually be implemented closer to 45 days. The longer a password is in use, the more likely it will become compromised; this is the primary reason for regular password changes. These are the most common and poorly implemented aspects of application security that put enterprise data at as much risk as the other components of enterprise security architecture.

During application installation there may be unique administrator-level installation accounts with default settings; these should be removed or configured to an acceptable security level prior to production deployment of the application. Any test accounts configured during setup or test of a role's access should be limited, and removed or disabled at the completion of testing. Any users that require the elevated privileges in the application must have a unique ID for proper security monitoring of account access. Use of any built-in administrator accounts should be restricted or disabled to ensure all administrator-level application access can be attributed to an individual. These accounts are easily overlooked and most times remain enabled with default passwords when implemented in production. This aspect of applications should be included in the quality assurance process and must include the IT security personnel for validation.

Consistent monitoring and auditing for activities associated with privileged accounts are the best methods for finding misconfigurations, erroneously elevated accounts, and to detect behaviors that may indicate account compromise, misuse, and malicious activity. The end result in a properly implemented application-privileged user security mechanism is more secure enterprise data.