In any organization, there are certain accounts that are designated as being privileged. These privileged accounts differ from standard user accounts in that they have permission to perform actions that go beyond what standard users can do. The actions vary based on the nature of the account but can include anything from setting up new user accounts to shutting down mission-critical systems.
Privileged accounts are essential tools. Without these accounts, the IT staff would be unable to do its job. At the same time, privileged accounts can pose a serious threat to an organization’s security.
Added risk of a privileged account
Imagine for a moment that a hacker manages to steal a standard user’s password and is able to log in as that user. Even though the hacker would have access to certain resources at that point, they would be constrained by the user’s privileges (or lack thereof). In other words, the hacker would be able to browse the Internet, open some applications, and access the user’s email, but that’s about it.
Obviously, a user’s account being compromised is a big problem, but there is a limit to what a hacker can do using that account. The same cannot be said, however, of a situation in which a hacker gains access to a privileged account. A hacker with access to a privileged account controls the victim’s IT resources.
This presents a bit of a quandary for those tasked with keeping an organization’s IT resources secure. On the one hand, privileged accounts are necessary for performing day-to-day administrative tasks. On the other hand, those same accounts represent an existential threat to the organization’s security.
Ridding your organization of privileged accounts
One way that organizations are working to negate the dangers associated with privileged accounts is through the adoption of zero trust security. Zero trust security is a philosophy that essentially states that nothing on a network should be trusted unless it is proven to be trustworthy.
This philosophy also goes hand in hand with another IT philosophy called Least User Access (LUA). LUA refers to the idea that a user should only have the bare minimum privileges required for them to do their job. This same philosophy also applies to IT pros.
Role-Based Access Control is often used to limit privileged accounts to being able to perform one very specific privileged function rather than having full unrestricted access to the entire organization.
Privileged access management options
Another way that organizations are limiting privileged accounts is by adopting a Privileged Access Management solution. Privileged Access Management, or PAM as it is often called, is designed to prevent privileged accounts from being exploited by cybercriminals.
There are several different technology vendors that offer PAM solutions, and they all work a little bit differently. Often, however, accounts that would ordinarily be privileged are restricted in a way that causes them to behave like a standard user account. If an administrator needs to perform a privileged operation (a task requiring elevated privileges), the admin must request those privileges from the PAM system. Upon doing so, privileged access is granted, but for a very limited amount of time and the access is only sufficient for performing the requested task.
Even though PAM restricts privileged accounts in a way that lessens the chances of those accounts being abused, it is still important to safeguard any privileged account to prevent them from being compromised.
Bringing in an added layer of security
Whether you’re implementing zero-trust or decreasing the odds of abuse for privileged accounts, your helpdesk is a risky endpoint that needs an additional layer of security. One way of doing this is to adopt Specops Secure Service Desk, which is designed to prevent a hacker from contacting the service desk and requesting a password reset on a privileged account (or any other account) as a way of gaining access to that account.
Secure Service Desk allows users to reset their own passwords, but if someone does contact the help desk for a password reset, the Secure Service Desk software will require the caller’s identity to be definitively proven before a password reset will be allowed. In fact, the helpdesk technician cannot even reset the caller’s password until the identity verification process is complete.
This process involves the helpdesk technician sending a one-time code to a mobile device that is associated with the account. When the caller receives this code, they read it back to the helpdesk technician, who enters it into the system. If the code is correct, then the technician is given the ability to reset the account’s password.
It is also worth noting that Specops Secure Service Desk aligns perfectly with zero trust initiatives since helpdesk callers who are requesting a password reset are treated as untrusted until their identity is confirmed. You can test out Specops Secure Service Desk for free in your Active Directory here.