Dealing with account lockouts is one of the unhappy facts of life for many IT teams. And while resolving lockouts isn’t particularly difficult, it is the sheer volume of incidents that often weighs down IT teams. In fact a recent survey found that ⅓ of IT and Support tickets are tied to password resets and account lockouts.
Worse still, 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. So let’s take a look at some of the underlying causes of account lockouts as well as some best practices that can lead to happier users, while giving IT a time rebate in the process.
The Forecast Calls for More Lockouts
Let’s first take a quick look at the 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 pretty impossible to eradicate, this is the least of our account lockout problems. The majority of lockouts can be traced back to the ever-growing sprawl of our user devices and applications. A user changes their password on their main laptop, but not on their other personal devices which continue to use the old password. Applications that store or cache credentials, mapped drives, and terminal services can all use stale user credentials and lead to an account lockout. What normally is a convenient automated authentication leads to an automated lockout. The underlying problem is complexity. More devices, more applications, more history in the network – the more chances for a 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 above, it’s obvious 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.
Preempt can help to ensure that this “less-is-more” approach actually delivers on its intended goals. The solution constantly monitors the environment for any weak passwords, including passwords that are known to be compromised or in hacker dictionaries. When a weak password is identified, Preempt can notify security staff and even automatically force the user to create a new password. The important point is that password changes are triggered by actual risk, not by an arbitrary cadence.
Adaptive Policies to the Rescue
Preempt can also bring new flexibility to how an organization responds to repeated login failures and behavioral anomalies. It is important to remember that the whole reason for automatically locking out accounts is to prevent attackers from brute forcing passwords. Preempt not only monitors for these brute force techniques, but also a wide range of additional ways that attackers gain access including account scanning, pass-the-hash, Golden Tickets attacks, and attacks against the AD infrastructure itself. The system also looks for behavioral anomalies that suggest that a user has been compromised.
Preempt uses all these factors to understand the real risk of the user or device and then apply controls that are appropriate and adapt as the situation changes. For example, instead of a strict black-and-white policy that locks out users after a few failures, staff can use the overall risk score to scale back a user’s privileges. 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. These policies can be applied to any application or resource including file shares, which are a common culprit for using stored, stale credentials.
These are just a few examples of how you can use Preempt to reduce the amount of time you and your team spend on account lockouts. Hopefully you find some of these suggestions useful in your daily practice, and as always, we are always happy to answer any questions and show how we can help in your network.
This is a Security Bloggers Network syndicated blog post authored by Wade Williamson. Read the original post at: Preempt Blog