BeyondTrust

Removing administrative privileges from users is always a challenge, but especially in the case of notebook users, who can find themselves on the road with no internet access and requiring support or needing to make a system-wide changes, such as installing a driver or application. As a result, notebook users either get to keep their administrative rights or Privilege Guard (Edit: now Defendpoint) is deployed to track when and why users are elevating privileges.

Prior to Privilege Guard 3.6, there were three options for IT when users elevated privilege or ran untrusted applications, i.e. those not included in a whitelist policy:

  1. Block applications or privilege elevation requests.
  2. Allow users to run or elevate applications on demand and log the activity for later inspection.
  3. Create exception rules on demand so users can run blocked programs or elevate privileges as necessary.

Typically, allowing notebook users to run or elevate applications on demand is the most practical option, providing a means for users to do their jobs and track when applications have been run or elevated. But unless we regularly inspect event logs, it may be that users are elevating or running untrusted applications far more than we would like, putting devices and the organization’s data at risk. On demand exception rules require notebooks to have connectivity to the corporate network and some administrative effort from the IT department, which is not optimal from both users’ and IT’s perspective.

Where on demand elevation operations in Privilege Guard require only user confirmation (Figure 1), challenge response authorization necessitates that users enter an authorization code. When elevating an application, users must dictate a code displayed on screen to the helpdesk (Figure 3), and the helpdesk responds with a corresponding authorization code that confirms the required operation (Figure 4).

Setting up challenge response authorization

When creating a challenge response policy in Privilege Guard for the first time, you’ll be asked to enter an authorization key. This key is used as the basis for generating challenge response codes and is required by the helpdesk to create authorization codes. It is best practice that the authorization key should be changed on a regular basis. The challenge response system is integrated into Privilege Guard messaging, so it can be used for both privilege elevation requests and for unblocking applications not included on a whitelist.

In this example, I’ve changed an existing elevation message in a Privilege Guard GPO, which is applied to notebooks and previously only required users to confirm elevation requests, so that challenge response authorization is enabled with a maximum of three attempts. As you can see in Figure 2, all I needed to do was enable challenge response authorization and change the Maximum Attempts parameter from Unlimited to Three attempts.

Once my updated policy has been applied, when a user tries to run blocked applications or elevate privilege, instead of a simple confirmation message (Figure 1), they’re required to enter an authorization code given to them by the helpdesk (Figure 3).

The authorization code is generated by a support technician using a small program (PGChallengeResponseUI) supplied as part of the Privilege Guard management console. To generate an authorization code, the authorization key and the code generated on the user’s desktop are required. In Figure 4 you can see that the authorization key is hidden, the challenge code provided by the user is in blue and the authorization code is shown in green.

Once the user has entered the authorization code received from the helpdesk into the elevation dialog on their screen, all they have to do is click Yes to run the blocked program (Figure 3).

Confidence with challenge response authorization

While challenge response authorization doesn’t completely remove the need to trust users, it is likely employees will think twice before calling the helpdesk to receive an authorization code for something they know shouldn’t be run or elevated, not least due to the effort required. Challenge response authorization allows organizations to block untrusted applications and privilege elevation requests in all but the circumstances where genuinely required, while retaining confidence that support can be provided or changes made when users are working remotely without Internet connectivity.

Defendpoint

Edit: Privilege Guard has now evolved into the brand new security suite, Defendpoint, which encompasses Privilege Management, Application Control and Sandboxing. For more information, please visit www.avecto.com/defendpoint.

You May Also Be Interested In: