Putting limits on users’ privileges

“Least privilege” is the No. 1 IT security mantra. It means, “Don’t grant users permissions or privileges beyond the bare minimum they need to perform their assigned duties.” Unfortunately, adhering to this mantra always has been easier said than done. Both Microsoft and third-party software vendors have attempted to ease the task, with some (but not complete) success.

For two decades in the Windows world, application developers were accustomed to users always being logged on as full-time administrators. Removing regular users from the built-in Administrators group proves among the most difficult tasks a security administrator can perform. Well, it’s easy to do — just remove the user from the Administrators group — but the fallout from the operational aftermath has often forced well-meaning administrators to reverse course or to delay least-privilege implementations.

[ Master your security with InfoWorld’s interactive Security iGuide. | Stay up to date on the latest security developments with InfoWorld’s Security Central newsletter. ]

Microsoft upped the ante starting with Vista by implementing a least-privilege default process called User Account Control (UAC). When UAC is enabled and a user from one of 17 pre-defined elevated groups (such as Administrators, Domain Admins, Enterprise Admins), or one who has been assigned an elevated privilege (act as the operating system) logs on, Windows splits his or her single logon access token into two tokens: one standard and one elevated. By the default, the elevated user runs with the standard token most of the time, such as answering email and surfing the Web, and must be prompted to approve actions requiring the use of the elevated token. Although Microsoft (my full-time employer) would prefer that standard users never log on as elevated users while performing non-elevated tasks, UAC is seen as necessary evil.

Unfortunately, UAC is fairly binary in many of its actions. Whereas some UAC actions can be customized per user or per application, the most important functionality is global across the PC. The newness of UAC, coupled with the operational interruptions it can instigate, has caused many administrators to turn it off or seek more granular third-party least-privilege products.

I’ve had experience with many of these products, including those from BeyondTrust, Cyber-Ark, and Avecto. I’ve been very impressed with the products I’ve reviewed. I’ve found them to be very useful, feature-rich, and hard to exploit — although the latter point was always true in the early versions. What I love most about these products is their ability to allow administrators to granularly define what programs, processes, or users can run. Once a policy is defined, all programs run seamlessly in the manner intended by the controlling administrator.

Some computer security experts don’t trust least-privilege products for a variety of reasons. Their most important worry is that rogue users or determined hackers can misuse the products to grant themselves unauthorized escalated privileges. This is a true security risk. More than likely, least-privilege products contain unknown or unpublished security vulnerabilities that could be found and abused. That’s the risk of any software product, including Windows and UAC.

The question, though, is whether you’re at greater risk from deploying a least-privilege product or from using nothing at all? In many cases, I’ve had clients who would not have upgraded Windows XP (to one of the more secure Windows versions) or would have completely disabled UAC because of the operational requirements of their environments. Using least-privilege products allowed them enough granularity to utilize vastly more secure operating system versions or to keep UAC enabled.

It’s with that in mind that I highly recommend that readers consider one of these least-privilege products if it can help them bridge the gap between less secure operating system implementations and the higher security models that are available today.

It’s always best to tell users to only log on as a standard user when performing non-elevated tasks or to use Microsoft’s built-in UAC, but if you’re in the large bucket of enterprises that absolutely needs to allow their users to function as their own local administrators with more granularity, today you have options. 

This story, “Putting limits on users’ privileges,” was originally published at InfoWorld.com. Follow the latest developments in security and read more of Roger Grimes’s Security Adviser blog at InfoWorld.com.