Introduction

Cybersecurity is commonly considered to involve users or people as a key part of the problem, and more than that, it’s an ‘everyone’ problem. Everyone has both a stake and role to play in securing an organisation, having mindset and awareness, and reflecting those in their actions and behaviours.

But CISOs and other security practitioners know that applying organisation-wide cyber protections means encountering individuals or subsets of users for whom the existence of these protections may not sit well.

The protections may be perceived as an attack against internal freedoms; be painted as detrimental to user productivity; or seen as illustrative of a lack of trust in the sense, judgement and abilities of staff to recognise and not fall victim to commonly observed or encountered security threats.

Software developers and senior executives are often considered to be pockets of resistance.

Developers’ efforts power products that are sold, used or consumed by paying or internal customers, and these efforts are often supported by a variety of tools – some sanctioned or in the standard operating environment, others bespoke or fitting individual ways of work, language of choice or personal preferences. The last thing developers want is for something that sits between them and their ability to innovate. Their technical literacy can also be considered, not least their ability to discern safe and unsafe paths to innovate and grow.

To add complexity to the situation, senior executives commonly have access to the most sensitive of information within an organisation and should therefore have the highest degree of access control applied to them – but commonly they are treated the same as everyone else or potentially given excessive rights because they believe that their leadership style may be cramped by security protections. Worse, if senior leadership find a security control to be too intrusive they may question whether it is hindering overall productivity and why it is required in the first place.

The real issue for cybersecurity leaders is understanding and navigating the complexity and broader challenges of user adoption and resistance, bringing some key strategies to limit resistance to bear. In this way, the rate of adoption versus resistance can become a measure of success of the project, not an inhibitor to it.

So, what are some of the strategies that leading organisations employ to break down pockets of resistance to the rollout of security protections?

‘It’s not you, it’s them’

In the above scenarios, the concern around security is misplaced. Security protections are about what organisations don’t want to allow an attacker to do, more so than what they want to allow or disallow staff from doing.

Consider the need to restrict administrative privileges that may exist in an environment. Restricting administrative privileges is a core control in the Australian Cyber Security Centre’s (ACSC’s) Essential Eight, but controls aren’t just about compliance, nor should they be, nor are they a reflection of how much employees are trusted.

Rather, when we talk about cyber threats or cyber risks, if a user is a local administrator on their machine or has excessive privileges, half the attacker’s job is done for them. Paths to privilege via lateral movement, escalation and persistence are enshrined into many environments – all an attacker needs is to be able to engineer a way in. The research tells us that the mean-time-to-identify credential-based attacks, where legitimate credentials are stolen or compromised, is 229 days, with a further 63 days post that to contain them – a total of 292 days. When security protections are introduced to endpoints, it’s to curb the potential paths to privilege of this nature to occur. This is one way that elevated protections may be positioned and user buy-in sought.

Exception handling is key to user experience

Technology choice and policy definition are also important factors in user acceptance. There are multiple ways to implement application control and to manage privileged access, and some strike a balance between security and usability better than others. Users’ concerns are often linked to perceptions that their productivity and ability to innovate will be negatively impacted by the additional controls, but this does not have to be the case.

This is why it’s important to include exception handling when considering privilege escalation or application control in conversations with the organisation about the introduction of new protections – and to have technology that can implement these arrangements effectively. If and when a user encounters a control or restriction, there should be some flexibility built into the security policy and the system that imparts a certain degree of control back to users: to be able to install some things, remove others or change settings, without having to route all requests or exception-handling through central IT.

Conclusion

The responsiveness of the system to exceptions should naturally change based on what the user is doing, where they are, and the confidence in their corporate identity – who they say they are – has been established. Some requests could be automated; in other circumstances, a step-up authentication challenge or routing of the request via the service desk may be judged as required. The decision process should offer far more than a simplistic “yes/no”, and it should never grant the end user time based unlimited access on their systems to handle exceptions.