The three-stage path to a more secure IT environment

Organisations are re-doubling their efforts to reduce the attack surface of their environments. More often than not, this means rethinking how much leeway and flexibility employees have on their local machines.

What's become clear after recent high-profile attacks is the proliferation of local administrator privileges is making security policies hard or impossible to enforce.

Privileged accounts are a common target for threat actors since they can be exploited to allow an attacker to more easily move around inside of an organisation's network, escalating an attack while looking like a legitimate user.

An important body of work within organisations is underway to enact principles of least privilege, such that if a user account or endpoint is breached, the ability for an attacker to escalate beyond that point is limited.

But that comes with challenges. Historically, the removal of local administrator rights can lead to a poor user experience. That's because not all users have the same needs: some require flexible permissions; others don't but demand them anyway.

How the tightening of privileges is approached will very much impact the success of the endeavour and, therefore, whether the needle on security can be moved in a meaningful way.

Graduated flexibility
One approach is to implement a graduated set of flexibilities - high flex, medium flex and low flex - where users' permissions and their ability to do things themselves is gradually tightened or controlled over time.

Organisations should start all users in a high flex group, with similar privileges on the system, while establishing and mapping out their usage patterns into a baseline. Then, as you mature in your understanding of what's happening in your environment, user permissions can be tightened, signified by users being stepped backwards into medium flex and ultimately low flex categorisations over time. Following this method, an organisation can remove admin privileges and enhance security quickly and efficiently whilst avoiding negative friction with user groups.

It's worth explaining what each flexibility level looks like from a user and IT service desk perspective.

Users in the high flex group may be allowed to run trusted and approved applications with admin rights and may also have permission to run unknown applications on-demand - and with admin rights once they confirm that the application should be elevated. In addition, they can perform elevated tasks within the operating system, such as control panel applets or the modification of system settings.

A moderately flexible policy set would apply the ability to run known business applications and operating system functions and to have admin rights on trusted applications. They can still also run unknown applications when they want to, but unlike their high flex group counterparts, they may be prompted to provide a reason before they can run an unknown application with admin rights. In addition, some operating system functions that require admin rights may also be prevented and require support interaction.

The low-flex group has a tighter set of rules. It will still allow known and approved business applications and operating system functions to run but prompts users to contact support if a trusted or untrusted application requests admin rights or if an unknown application tries to run. The practical reality for this group, however, is they may only be impacted if trying to install or run applications with questionable business use or value.

Managing exceptions
While the default position should be to tighten user permissions over time, some user types may be treated as exceptions - or seek more flexibility as such. Whether that flexibility is approved or not comes down to a risk appetite and efficiency discussion.

Software developers and engineers, for example, often retain a highly flexible policy set. They're often accustomed to having tool choice and the flexibility to install things on their machines for test or production purposes. They also often need to be able to change configurations to test how the code they've produced interacts with these various tools and settings. As such, they're usually the most resistant to the removal of administrative rights. Our advice is to put them in the high flex user group, where rights are maintained, but everything they do is collected, audited and logged, such that anything malicious they inadvertently interact with will show up, and they'll be alerted to it.

Business leaders, particularly executives, may also consider their need for administrative and uncontrolled access to be in the same category. However, this should be treated with caution. Leaders - and the sensitive material they work with - are often the ultimate target for threat actors. A more prudent approach to handling these users would be to enforce rigid policies on systems where sensitive documents are handled.

It's desirable to have executives on the most secure desktops with the most secure settings. Promoting the secure nature of the setup may also convince leaders of the benefits of being in the most stringent policies with the least amount of flexibility.

By adopting a graduated and nuanced approach to privileged access management, Australian and New Zealand, organisations can emerge better placed to secure their environments against the rising tide of attacks.