In today’s IT support model, the service desk/help desk often represents the focal point for all users to bring their needs and issues to IT. Need your password reset? Call the service desk. Need to be added to an AD group so you can get your job done? Call the service desk. Need your last name updated because you got married? Call the service desk.
Of course, the service desk does much more than the simple tasks mentioned in the examples above. But these examples highlight an important point that IT professionals should consider:
While the service desk can address these requests, the more important question to ask is should the service desk address them?
When you take a closer look at the situation, these requests are much more than simple administrative tasks. They have serious security implications as well. Let’s look at these requests from a security perspective, then. When someone calls your service desk to request a password reset, does the technician validate that the person is who he or she claims to be? If not, what’s to prevent someone from calling and asking to have another user’s password reset? The answer is probably nothing — except for the possible security “test” of checking the extension used to make the call. The security holes here are potentially huge.
What about a request to be added to a group, and its inherent permissions? From a security perspective, this situation is even more hazy. In most companies, there is no process in place to verify whether a user should or shouldn’t be included in a particular group. Of course, someone in sales saying “please add me to the Financial Admins group” would raise some eyebrows and invite scrutiny. But when you consider how distant the average service desk technician may be from understanding who should be in a specific group and what the security repercussions are, your service desk may be in a situation similar to one described by an attendee of a recent Imanami webinar:
“Anyone who submits a request to the Service Desk can get themselves added to almost any AD group. We centralize AD group management to the Service Desk, and not to the business unit that requested the group. In most cases, the business unit whose operations and security depend on the AD group have no control over who gets added.”
So, does it really make sense to have the service desk handle issues that impact the security of your organization? Wouldn’t a self-service solution capable of managing these tasks securely be a much better option? If you agree with us that self-service is the answer, check out GroupID Password Center from Imanami.
Let me share two common facts to provide some color. In the case of password resets, according to Verizon’s 2014 Data Breach Investigations report, the biggest threat comes from the use of stolen credentials. And one of the easiest ways to obtain the more secure half of those credentials (the password) is to simply ask for it to be reset.
In the case of adding members to AD groups, you may think it’s not that bad. But in a recent Ponemon study, almost three-quarters of the end-users surveyed stated that they frequently or very frequently have access to information that they shouldn’t. And it’s more than likely that this access was given how? Yep, you guessed it — groups.
Changing Focus from Service to Security
Your service desk is a great asset to help end-users. It’s perfect for addressing problems that require a bit of technical prowess. But when it comes to certain security-impacting activities, it may be time to remove those responsibilities from the service desk and take advantage of self-service solutions that provide better security. In addition to creating a more secure environment, this approach has the added benefit of improving the quality of service as well.
If you’d like to learn more about this topics, check out some of the other articles on our website.
Jonathan Blackwell
View ProfileSince 2012, Jonathan Blackwell, an engineer and innovator, has provided engineering leadership that has put GroupID at the forefront of group and user management for Active Directory and Azure AD environments. His experience in development, marketing, and sales allows Jonathan to fully understand the Identity market and how buyers think.