Whether we like it or not, passwords are a fact of life in enterprise IT. For a number of reasons, we will have passwords in our lives for the foreseeable future, and that means security teams need to secure them and build policies and processes for
enterprise password management. The trouble is, passwords aren’t a “one-size-fits-all” problem. Many different types of teams and workers need different password models and policies, which means IT teams need a strategy to address them all. I’ve identified
password security requirements for the three types of users that are found in every organization, regardless of company size.
Ready to learn more? Join my upcoming webinar “It Takes All Types: Password Management for Different Teams and Roles” where I’ll talk about this issue in more detail, with additional tips and suggestions for how to get this done!
The Average User
First, we need a password policy for the “average users” in our organization. I call these users “average” for no other reason than job function – they likely don’t deal with sensitive information, they just need to get their work done, and if their accounts are compromised, it is the lowest risk threshold we probably face in that scenario. This doesn’t mean we shouldn’t care about the security of their accounts! However, we need a baseline password scenario to start from, and this is it. Trying to enforce 27-character passwords with these users is a losing battle in every possible way. You’ll fight them, they’ll resist, and we’ll find ourselves back to the dreaded “sticky note” situation faster than you can say, well, “sticky note”.
Be reasonable when crafting a password policy for these folks – stick to 8 or maybe 10 characters at the max, rotate passwords less frequently than for some other (more sensitive) user types, and give them some grace with account lockout – 5 tries is actually not that unreasonable. If you can pull it off without an uprising, enforce the use of multifactor authentication for certain types of access, at least for remote access if nothing else.
Users Who Handle Sensitive Data
Then you have the “sensitive users”. These are not IT professionals, but are users that have sensitive job roles or access to sensitive data, and likely include professionals in the executive ranks, finance, HR, and so on. Depending on the corporate culture, you may or may not have much success enforcing rigid or stringent password controls on these users, but you definitely need to make them more secure than the “average users” just discussed. Require a passphrase, maybe 12-15 characters in length. One way to offset this “burden” is to reduce the password change cycle, maybe only requiring a change once a year or so.
If you go this route, though, you’ll need to up your game on account monitoring to ensure any unusual behaviors are noted quickly - these users will likely re-use that same password all over the place, and you don’t need a compromise when the next big data breach happens. Again, push for multifactor authentication, and you may want to reduce account lockout to 3 attempts.
The IT Team
The final category of passwords is IT – they control the infrastructure, and should have the most stringent controls in place of anyone in the organization. Not only do IT users need long, strong password (and length > complexity, all day long), but also they should ideally be required to use a one-time password (OTP) mechanism for access to critical systems.
Privileged User Management (PUM) is one of the most valuable controls to implement across your IT infrastructure today, as these users are the prime targets of hackers, and it turns out they like to click on links to hilarious cat videos just like everyone else.
So, require long passwords that change every 60-90 days (this is somewhat controversial, I know), enforce the use of OTP for critical systems, and require the use of a lower-privilege account for day-to-day activities. Sounds like something you’ve heard before, right? Then why aren’t we doing it?
Join my upcoming webinar “
It Takes All Types: Password Management for Different Teams and Roles” where I’ll talk about this issue in more detail, with additional tips and suggestions for how to get this done!
