How your organisation can get exception handling of one-off requests right

As much as organisations want to standardise their applications and tooling, there will always be legitimate requests for exceptions. How these are handled is important. 

Assessing the legitimacy of the request or validity of the need - for one-off access to a new application or for an operating system task requiring elevation or to access a file or macro - needs to happen relatively expediently. 

One analyst firm quotes 10 minutes as the maximum time a user will wait to get permission to access or download a different video-conferencing tool to join an external meeting before giving up. A lot can happen in 10 minutes - but if nothing much does happen in response to a stated need, the perception of IT and security functions and their ability to flex to business requirements is likely to take a hit.

From here, several possible paths emerge.

One school of thought is that time-limited exemptions can work. In this model, the restrictions on an endpoint are lifted for a set period of time to allow the user to download the app or to grant a system one-off access to a file or macro hosted elsewhere on the corporate network or even externally - before reverting to its locked-down state. 

But this approach can be problematic. Specifically, it means that overly permissive bursts of administrative access are given to users or systems that don't need anywhere near that level of permissions to do what they're asking to do. 

For Australian organisations following Essential Eight guidelines, this model asks them to break the requirement to restrict administrative privileges on the basis that the exceptions are managed, and because it's temporary, it's OK. 

It isn't.

Exception handling around application control isn't conducive to a simple binary decision of allow/deny. Any action that's taken should be contextual to the situation that's being presented. 

Just as there are a range of contexts in which a user or a system may request an exception, there should be a range of ways available to handle the request, perhaps based on pre-configured policies or the severity of the risk associated with granting access. The response should naturally change based on user characteristics: what they're doing, where they are, and the confidence with which their corporate identity - who they say they are - has been established. 

Some requests could be handled automatically; in other circumstances, a step-up authentication challenge or routing of the request via the service desk may be judged as required. 

What's important is that administrators have a wide range of options available to them - and that the options applicable to an individual request are presented in a user-friendly way such that the user can move forward in a safe and approved manner.

When approaching exception handling, it's worth keeping three principles in mind during the solution design.

1. Think usability

Usability - both for end users seeking the exception and for the administrators and administrative systems handling it - is critical to success. Demonstrating flexibility in the way exceptions are handled and options are presented to users makes a big difference. When users encounter a restriction, they may be displayed a simple prompt: 'Did you mean to do this? yes/no' or 'You're trying to run something you wouldn't normally need, please tell us why you need it'. Other responses can be progressively more protective: asking the user to re-authenticate to be granted access; or routing them via a 'catch-all' for all remaining scenarios, where a service desk ticket is raised that requires manual approval of access to a specific file, task or application.

2. Think contextually

In cybersecurity, everything should be policy-based and contextual - according to what the user (or machine) is trying to do. As stated, exception handling should be more than just a simple allow or deny - it needs to be flexible enough to deal securely with a wide range of scenarios. It should take into account what granting access would achieve, how it would work, and whether the additional access comes with particular risks. When this assessment is seamless and the user experience of it is frictionless, it shows users that cybersecurity can make things easier while enhancing security. 

3. Think holistically

To respond effectively requires a holistic approach to application security: one that covers not just the base capability of application control, but also user application hardening and the restriction and management of administrative privileges as well. This approach treats everything in an operating system as a permission or an authorisation, and utilises visibility - into what's running and what tasks users are trying to do - to add context to the decision-making process. 

The end result is a pragmatic approach to application control: covering the assignment of just-in-time privileges around approved applications, scripts, tasks, and commands across endpoints and servers; the ability to manage exceptions on a case-by-case basis while denying unknown applications from executing; and the ability to restrict administrative privileges and to revalidate the need for privileged access regularly.