The enterprise help desk has long been a favorite target for those seeking to use social engineering schemes as a way of penetrating an organization's cyber defenses. As ever present as such threats may be, however, the help desk poses another, far more serious threat that is often overlooked. This threat stems from the fact that help-desk staff members are often exposed to information that could gain them access to the organization's most sensitive data.

Every organization would like to assume that their help-desk employees are trustworthy, and in most cases the help-desk staff likely have no ill intentions. However, there have been incidents in which a rogue employee has used an organization's data for personal gain, as was the case in the Trend Micro breach a few years ago. Given the amount of damage that a rogue support technician could conceivably cause, it makes sense to take steps to limit the potential for harm.

The Transition to Zero Trust
One of the major cybersecurity initiatives over the past several years has been the move toward zero-trust security. Limiting the help-desk staff's exposure to highly sensitive information aligns perfectly with existing zero-trust initiatives. Implementing such controls, however, can be far more challenging. After all, how can an organization realistically put limits on its support staff without affecting their ability to do their jobs?

A good first step in bringing zero trust to the help desk is to identify the situations that might put help-desk employees in possession of sensitive or potentially damaging information. Once those situations have been identified, an organization can work to find alternative support methods that would make it harder for a rogue help-desk employee to cause harm.

Self-Service Password Resets for Security and Cost Control
Many organizations have implemented self-service password reset capabilities using a tool like Specops uReset or something similar; this is often done primarily as a cost-cutting measure. A 2020 study by Gartner estimates that "password tickets consume 31% to 40% of help desk's time," which can add up. However, a self-service password reset mechanism can also help to improve security because it greatly reduces the number of password reset requests that help-desk employees receive. That means that the requests that do make it to the help desk will likely receive greater scrutiny than might be the case if the help desk were responding to a high volume of password reset requests each day.

Giving users the ability to reset their own passwords is a great first step, but it doesn't eliminate the need for help-desk employees to be able to reset user's passwords. There may occasionally be situations in which a user needs a bit of extra help with a password reset. The fact that the help-desk staff is still able to reset passwords means that a rogue help-desk employee could conceivably reset the password associated with a sensitive account as a way of gaining access to that account.

The Problem With Authenticating Password Reset Requests
Another problem lies in the way that help-desk staff members authenticate password reset requests. As previously noted, the help desk has long been a favorite target for those wishing to use social engineering schemes as a way of gaining access to an organization. As such, most organizations have put policies in place that require a help-desk technician to do something to validate a caller's identity before granting a password reset request. However, the authentication process that is designed to protect the organization can also put extremely sensitive information into the hands of a rogue help-desk technician.

Imagine for a moment that a high-level user contacts the help desk to have their account unlocked and password reset. The technician may validate the caller's identity by asking them a security question, which the caller answers. The help-desk employee now knows the answer to the caller's security question!

Zero-Trust Password Resets
With that in mind, consider what a zero-trust approach to password resets and account unlocks might look like. The process begins when a user contacts the help desk seeking assistance. As before, the help-desk staff member needs to do something to validate the caller's identity. Rather than asking the caller for the answer to their security question, however, the technician may ask the caller to provide the last three letters of the answer to the question. That way, the technician is never given the complete answer. As an alternative, the user may be asked to validate their identity through a code sent to their smartphone or by signing into another identity provider.

Although this is a good start, there's one more crucially important piece to the puzzle. The user identity authentication process needs to be constructed in such a way that the help-desk technician is physically unable to reset the user's password until their identity has been validated. This not only guards against social engineering attacks but also prevents a rogue technician from performing unauthorized password resets for the purpose of gaining access to a user's account.

The password reset capabilities that are integrated into the Active Directory and other commonly used authentication services lack the features that would allow them to be used in a zero-trust environment, so using third party software is the only viable option. A tool such as Specops Secure Service Desk brings zero trust to the help desk by providing organizations with the tools that they need to positively verify user's identity by enforcing user authentication. Any software solution you employ should also prevent technicians from performing unauthorized password resets or gaining access to the answers to users' security questions.

About the Author

Brien Posey is a 20-time Microsoft MVP and internationally best-selling technology author and speaker. In addition to his 30 years of IT experience, Posey has spent the last several years training as a commercial astronaut candidate in preparation for a mission to study polar mesospheric clouds from space. You can visit Posey's website at http://www.brienposey.com.