Inactive user accounts pose security threats for organizations

For organizations around the world, account security of employees around the world is normally the responsibility of the employer itself. While some companies allow their employees to create their own strong passwords, many often provide all credentials and secured passwords to employees.

Today, employees realize that account security is also part of their responsibility while they are still employed. It is critical that they do not share, store or exchange user credentials over unsecured networks or devices as cybercriminals are always lurking around.

Despite this, cases of account security especially credentials like user names and passwords being compromised continue to be on the rise. What’s more concerning is that some companies are not disabling the accounts of employees who are no longer with the organization.

Inactive user accounts pose a big threat to account security. But who is responsible to maintain the account security of all employees, past or present? To understand more about this problem and how organizations can deal with it, TechHQ speaks to Jim Taylor, Chief Product Officer at SecurID.

How are threat actors using inactive user accounts to exploit organizations?

Colonial Pipeline was the highest-profile example of a threat actor using an inactive user account: a hacker gained entry to the company’s network using a VPN account that was no longer in active use. But the truth is that inactive users are just the tip of the iceberg: organizations need to think through the full range of ungoverned accounts, including service accounts, inactive accounts, orphaned accounts, and overly-provisioned accounts. These ungoverned accounts are creating a larger and more vulnerable attack surface.

And hackers are taking notice: IBM’s Cost of a Data Breach 2021 report found the most frequent step in all data breaches last year was the use of compromised credentials. It’s not just that those attacks were the most frequent—they were also the most difficult to identify. The IBM study found that, on average, “a breach caused by stolen credentials that occurred on January 1^st would take until December 7 to be contained.” That’s an awfully long time for cybercriminals to cause damage.

Should businesses look to provide daily login credentials, MFAs, and such in keeping track of third-party access?

At this point, we should be so fortunate to start with everyone at least using MFA for every user. I don’t feel strongly about daily login credentials per se: the benefit there is that you’d ensure some standard level of security. The drawback would be that your users would likely wind up writing their daily passwords down on post-it notes. Think about what that would do to your help desk costs.

The goal that we should aspire to — and something that I think security teams are guilty of forgetting — is to create a system that’s both secure and usable or consumable. Security teams tend to be good at implementing controls and requirements that are great in theory but don’t work in practice—not everyone has a degree in Computer Science.

My ideal way of doing that is to get rid of passwords altogether: Verizon found that 61% of breaches involved the misuse of credentials and that 95% of organizations face “between 637 and 3.3 billion malicious login attempts throughout the year.” Rather than have users try to manage and update their passwords, biometrics, push-to-approve, one-time-passcodes, and other methods can make it easier for legitimate users to authenticate and harder for cybercriminals.

How often should companies perform lifecycle management, especially on identity inventory and access?

In an ideal world — one where you’re observing a core principle of zero trust — companies would be performing lifecycle management in real-time for every access or entitlement request. That sounds daunting, but it doesn’t have to be.

Contextual authentication can use a variety of different signals to authenticate a user: if someone is logging in at the same time, from the same IP address, using a trusted device, and making the typical requests they usually do, then a system should be able to verify them with a high degree of confidence. Context-aware security tends to be more appropriate given the user and the request that they’re making.

Who should be responsible for managing inactive user accounts? Is it an IT problem or an HR problem?

In day-to-day practice, this is very much an IT problem. It should be informed by HR, which should define the access requirements and say that a person in the Finance department needs A, B, and C to do their job, whereas someone in Marketing needs X, Y, and Z. IT then needs to translate those expectations into entitlements. But HR shouldn’t be enforcing whether someone has access—they should define what resources various roles need. Then IT should be left to enforce those policies.

There’s also a third constituent: the business owner. If I’m working to assign Marketing entitlements, then I should work with the CMO to understand what her team’s needs are. But I need to ask her Marketing questions to make sure that her department is getting what they need—not IT questions. You need to triangulate entitlements: HR should set appropriate corporate and legal policies, the department should help fine-tune the departmental needs, and IT should implement those decisions.

Lastly, can the process be automated in the future?

The process must be automated in the future. In too many cases, attestation is still a manual process and it’s already falling behind. Elastic cloud resources are poised to widen this gap: in 2021, cloud misconfigurations were the third-most frequently used initial attack vector in all data breaches. It’s growing to be such a large problem that Gartner expects at least 2,300 less privilege policy violations, per account per year.

Larger trends like the Great Resignation and robotic process automation are poised to widen the gap even further — soon we’ll have manual processes set to supervise automated systems. That’s not scalable. If a machine can make a million decisions a second, then the security system policing it needs to be able to, as well.

I think one high-value way of doing this is moving to exception based-security: if you assume that every user in an organization has 150 entitlements, the majority of all users will share the same 120 core permissions. I don’t need to keep as close an eye on the 120 shared entitlements — instead, I should focus most of my time and resources on the 30 exceptions that individual users need to do their jobs.

If an organization can get to that point where they’ve defined those exceptions, then they can reduce their security challenges significantly. Security has to be appropriate and contextual—it’s not one-size-fits-all. By understanding where your exceptions are, you can focus your resources on where they’ll deliver the most value.