What are some of the underlying causes of account lockout best practices that can lead to happier users, while giving IT a time rebate in the process?

Dealing with account lockouts is one of the unhappy facts of life for many IT security teams. And while resolving lockouts isn’t particularly difficult, it is the sheer volume of incidents that often weighs down IT teams. In fact, research conducted by HDI found that one-third of IT and Support tickets are tied to password resets and account lockouts. Lockouts are a major source of organizational waste. It’s the dreaded “lose-lose” situation where users and applications are prevented from doing their jobs, while IT staff must spend time doing menial repetitive work instead of working on higher-priority issues. As a result, getting smarter about account lockouts is becoming a priority for many organizations.

The Forecast Calls for More Lockouts

There are some common issues that lead to accounts being locked in the first place. The most obvious source is that users simply forget their password. A user may change their password, then go on vacation and simply forget. Other users may be seasonal employees or intermittent contractors. Even if users remember their password, they may forget the specific combination of substitutions they used in order to make the password “strong.”

What was that password again? P@ssword, passw0rd, pa55wrd!...

And while human forgetfulness is impossible to eradicate, this is the least of our account lockout problems. Most lockouts can be traced back to the ever-growing sprawl of our user devices and applications. These devices dutifully try to log-in on our behalf to make things easier, but generate a cascade of automated login failures in the process. Likewise, applications, mapped drives and terminal services can all use stale user credentials and changes can lead to an account lockout. What normally is a convenient automated authentication leads to an automated lockout.

NIST’s Password Pivot

NIST recently updated its guidelines for creating password policies, and several recommendations will directly apply to reducing lockouts. First, from our examples here, it’s obvious that the more often we change passwords, the more chances we have for something to go wrong. In one of the more eye-opening changes, NIST no longer recommends the regular changing of passwords based on time. Instead NIST recommends that passwords are only changed when there is evidence that the password has been compromised. Likewise, NIST backtracked on composition rules in passwords, meaning that users no longer need to remember the tricky character substitutions in their passwords (@ for “a”, etc). This leads to fewer password changes overall (and fewer chances of mistakes), while also taking away some of the complexity burden from users.

It’s important to ensure that this “less-is-more” approach delivers on its intended goals. Constantly monitor the environment for any weak passwords, passwords that are known to be compromised or that are in hacker dictionaries. When a weak password is identified, notify security staff and force the user to create a new password. This is where automation comes in handy. The important point is that password changes are triggered by actual risk, not by an arbitrary cadence.

Getting Smarter About Identity

It is important to remember that the whole reason for automatically locking out accounts in the first place is to prevent attackers from brute forcing passwords (and stealing a valid identity). One of the core problems behind account lockouts is that it is rooted in a time when identity was much simpler. Authentication was a manual process, and a user had a single device. In those days it was a fair assumption that if a user login failed 10 times in a row it wasn’t just due to typing mistakes. But as we’ve seen, identity is not so simple today. Users are associated with multiple devices and typically access scores of applications and services.

Attackers also have a variety of tools and techniques beyond brute force they can use to compromise credentials such as account scanning, pass-the-hash, Golden Tickets attacks, and attacks against the AD infrastructure itself. Of course we want to prevent unnecessary account lockouts, but we also need to do a better job of finding and stopping compromised users. This requires a much more modern understanding of identity. What devices is a user normally associated with? What applications are normally used? What network resources are used and when? Where does the user normally connect from? This context will not only reveal when a misconfigured iPhone is causing repeated login failures, but will also reveal stolen identities that an account lockout would never see.

Adaptive Policies to the Rescue

Once we have a better understanding of our users, devices and their behavior, we can start to look at taking appropriate protective actions. Here it makes sense to start replacing the old rigid enforcement policies of account lockouts (e.g. five failures = lock account) with more adaptive policies.

An adaptive policy should be able to do several things:

• Protect the organization’s users, assets and data;
• Do not disrupt the work of valid users;
• Do not require the manual intervention of IT or security staff;
• Adapt as the situation evolves.

For example, instead of a strict black-and-white policy that locks out users after a few failures, staff can use the overall behavior and risk of user to progressively scale back privileges. If an administrator begins behaving abnormally, the account can be temporarily demoted in Active Directory or the user prevented from accessing high-value servers. This can allow the user to remain functional, while protecting key assets.

Also, as the name implies, adaptive policies can change over time in response to new information. Repeated login failures or abnormal behavior can trigger a multi-factor authentication challenge to verify the user’s identity instead of directly locking the account. This is a simple but massively important shift. Instead of just passively waiting for information, adaptive policies can actively seek out additional information to make a smarter decision.

The key point is that instead of having a strict threshold that locks users out, adaptive policies allow organization to gradually reduce privileges as risk increases, and to challenge users and verify a problem before they are blocked. These policies can be applied to any application or resource including file shares, which are a common culprit for using stored, stale credentials. The list here provides a few simple examples of how adaptive policies are being used today:

• Focus on compromised passwords. Instead of changing passwords on an arbitrary schedule, adaptive policies can trigger only when a user is detected using a password that is compromised or in a hacker database. When triggered, the user can be required to change to a new password on the next login. This has the added benefit of reducing the password churn in an organization and login failures that come with it.
• Get a handle on unusual behavior. Enterprises are increasingly turning to behavioral analysis to find signs of users who may be compromised by attackers. However, is that admin’s behavior really malicious or just out of the ordinary? Adaptive policies can trigger the user or administrator to verify their identity via multi-factor authentication.
• Know your priorities. Policies need to adapt based on the user and the assets being accessed. Administrators and their privileges make them a constant target for attackers. Likewise, certain applications and resources such as databases and fileshares can be more important than others. Adaptive policies should be able to recognize the heightened risk of these users and devices. Maybe access to a critical fileserver should always require multi-factor authentication. Likewise, maybe an admin should always be challenged when connecting from an unmanaged device.
• Address your password hygiene. In addition to finding the use of compromised passwords, organizations can root out risk by finding exposed passwords, passwords that are being shared by multiple users, or stale accounts that can be deactivated. If the underlying issue can’t easily be resolved, these traits can be scored based on risk to drive adaptive security policies.

The steady rise of account lockouts is a symptom of a security control that is out of touch with the real world. Static, black-and-white rules that stop user productivity and require manual work to fix should be anathema to modern IT teams. At the same time, organizations have to be better at defending against increasingly persistent and inventive attackers. Adaptive policies that bring together identity, behavior and risk allow us to server both needs. These examples just scratch the surface of how adaptive threat prevention is making organizations more efficient. And while there are plenty of places to start, it makes sense to start with the processes that consume the most time for employees and security staff. In many organizations, account lockouts can be the first on the list. However, wherever you start the ultimate goal is a more secure environment that keeps employees (and security staff) more productive.