How to secure the enterprise with Least Privilege

By Centrify Asia-Pacific Regional Director Matt Ramsay

It’s time we took a fresh look at the core problems bedevilling our enterprise security.

Do we only need to guard against the bad guys trying to hack our infrastructure? Or do we need to defend ourselves from the bad habits of the good guys who manage that infrastructure?

The bad guys are a given: Their hack attempts are driven by every motivation from greed to ego. But the bad habits of the good guys – your beloved systems administrators – are another matter.

One example arises from the difficulty that many Windows administrators face: to allocate and maintain finely grained user privileges with standard tools such as Group Policies. As a result, admins get into the bad habit of only deploying coarse-grained privileges in practice.

This creates the situation where sites are either overly permissive, and thus insecure, or so restrictive that users are annoyed by the need to petition IT to make even a tiny change.

The same problem exists in Unix-like environments. Privilege entitlements managed via “sudoers” (Unix programs with the security privileges of another user) require expensive resources to maintain a syntax error-prone, text-based system that has no decent enterprise level administrative interfaces.

The result is that Unix administrators employ the same bad habit of coarse-grained privilege allocation due to the intractability of having machine-specific sudoers (akin to machine-specific GPO’s).

In addition, Unix sites frequently resort to the unsecure practice of shared accounts to deal with the lack of sophistication of enterprise-grade Unix privilege management.

Bad guys need to find only one flaw. A permissive setup gives them a huge opportunity for phishing (the currently most favoured attack) for accounts that have Domain Admin or similar rights.

Although a permissive setup means your users are by and large happy, any “unhappy” user now likely has Domain Admin rights – thus creating another problem.

These problems are compounded when an over-privileged user leaves your organisation and the overworked IT department has no idea what to turn off – they may not even know that a risk exists.

On the other hand, the restrictive access scenario is onerous and expensive for administrators – who are forced to deal with many petty requests – and annoying for the user.

There’s also a real chance that it will encourage users to find alternate ways of getting things done – that is, circumventing security or finding a grey area such as a SaaS portal to sidestep IT altogether.

The compromise between restrictive and permissive access is called “Least Privilege” – created by easy-to-use tools that can quickly configure and maintain fine-grained security policies.

Security tools need to work more like plumbing than rocket science – they should be affordable and predictable with modest training requirements.

At the moment, expecting a well maintained Least Privilege outcome from the goulash of Group Policies, sudoers files and resulting policy outputs is as silly as suggesting that programming in Assembly will deliver high quality ERP software “if you just try hard enough!"

Admins need the tools to visualise what has occurred and when so they can easily answer questions like: "why does John have backup rights on those machines?” and “How did that come about?"

Rather than rely on guru-like admins or super-awareness, we need tools that can grant and manage fine-grained rights that are as simple to use as making computers and users members of appropriate groups. 

Twitter