Privilege Manager Common Scenarios

THREE COMMON SCENARIOS

There are three common scenarios that typically require application-level security in order to properly satisfy the principle of least privilege.

Restricted Users:

End-users are not entitled to local administrator or even power user status. However there is a need to allow them to run a particular set of applications that require local administrator permissions, as well as to manage their own physical printer, screen resolution and selected other computer settings.

The only resolution to this problem has been to make each user a member of the Administrators group or otherwise grant their user accounts elevated permissions. This violates the principle of least privilege, presenting significant and obvious security problems; end-users have the ability to circumvent all local computer security.

Protected Administrators:

Administrators are entitled to run processes that require local administrative permissions in order to accomplish their authorized administrative functions. However, the level of permission required varies by application/task. Cautious administrators have a second restricted user account for carrying out tasks that do not require administrative access, such as browsing the web or checking email.

Using this account by cycling between logon sessions and/or using the RunAs utility, presents its own set of difficulties associated with the user of multiple identities, and often this is enough to prevent administrators from adhering to this practice. This violates the principle of least privilege, presenting significant and obvious security problems; if the administrator’s account is attacked from within the browser or by an email worm, the potential damage to the computer and possibly the network can be substantially greater.

Need to Know:

It is common for users to be authorized to access protected data/resources only in certain authorized circumstances. Computers do not provide this capability in the native security model. Access control to resources is based solely on user identity, not context. Many organizations have a need to restrict resource access based on the application performing the access, so that the application effectively acts as a security proxy to the data – preventing unauthorized data exposure on local systems.