Password Expiration and CyberOps Maturity
Over the last couple of years there have been numerous debates on whether it is a good idea to get rid of password expiration. The arguments against password expiration are usually variations of the below:
Forcing users to change their passwords on a regular basis leads to widespread use of weak passwords. Frequent password changes in many systems lead to password re-use (aka user is using the same password everywhere) Putting the burden of security on the user is wrong, technology should do the heavy lifting. What is interesting about most of the conversations I read, is that they seem to ignore all the other password improvements that the advocates for getting rid of password expiration usually cite – When you get rid of password expiration, you are supposed to also do the following:
A. Improve password length significantly (switch from passwords to pass phrases)
B. Get rid of some password complexity requirements (Special characters are really hard to remember!)
C. Introduce a Password Blacklist (e.g. block the word 'password' or its variations like 'p4ssw0rd')
D. Monitor your user accounts for leaked credentials and force password changes once you detect a leaked credential!
Now, A,B,C are really easy to deliver – You can just install and configure some tech, which will do the job for you. It is pretty much a set and forget kind of thing to implement. However, D is a completely different beast – See the paragraphs below.
The Role of CyberOps Maturity in all of this
OK, we understand now that with the new guidelines we are supposed to not expire passwords periodically anymore but we are supposed to force a password to be changed when it has been leaked/compromised. How would one do that?
In my experience there are three types of sources that can tell you when a password has been leaked/compromised:
A Leaked Password Database (e.g. https://haveibeenpwned.com , Azure AD Identity Protection, Recorded Future, + other services) Your SOC tells you that someone has tried to login from an unusual location and was blocked by MFA The User tells you that he has given away his password to a phishing website Number 1 is pretty straight forward – You feed these services with your user accounts and they alert you about any credentials they see on the dark web, on pastebins or any other nefarious places. However, those services need to be setup with your data and kept up to date with leaving and arriving new users. Therefore you need to drive your CyberOps maturity to a point at which you can rely on a process that keeps those services up2date, so you can be sure that they will alert you about any leaked credentials of yours.
Number 2 is probably the hardest. First, you need a SOC – That is something that not all companies/organizations can afford. For those that don't know: A SOC is basically a team of Cybersecurity Analysts that watch your cybersecurity tools on a 24x7 basis and respond to any detected attack. The expensive part about that is that you need at least 7-8 full-time Cyber Analysts to cover 24x7. Once you have a SOC, you need to give them a tool that is capable of detecting unusual login attempts. Those kind of tools usually use machine learning to create login profiles for all of your users, so they can alert you when Bob suddenly logs in from Nigeria although he usually works out of the US and India. By now you probably also understood that having MFA in place for all publicly available apps/services is a must – Even with a SOC you cannot really afford a successful login by the adversary. All in all you need a lot of money, time, and effort to put the tech (IdP, SSO, MFA) in place and then you need a lot of money, time, and effort to on-board and run an effective SOC that enables you to properly respond to leaked/compromised credentials every time.
Number 3 is fairly simple in comparison. All you need to do is train your users on the dangers and creativity around phishing in our days. In addition you need to tell your users how to tell the SOC real quick when they suspect that they have just given away their credentials (a shared mailbox or ticket system usually does that trick).
Another thing to consider: Phishing
Another thing I haven't mentioned within the realm of CyberOps maturity yet: Email Defenses against phishing. These days phishing constitutes to about 1% of the email traffic a company/organization receives. If your email defenses let 50% of that phishing volume get through to the user's inbox, your users are pretty much giving away their credentials on a daily basis. Even a 24x7 SOC goes crazy with that amount of leaked/compromised credentials and will get to its capacity limits. Therefore you need to make sure that your bases (email defenses) are covered appropriately as well.
Icing on the Cake
Another thing a well trained SOC can do besides detecting MFA blocked login attempts, is to investigate every phishing email that is reported by a user or any of the (after-delivery) email security tools. And by that I mean only the phishing emails that actually get through to the users' inboxes. A good SOC should be able to figure out who else within your organization has received a similar phishing email (same subject or same sender or same sender ip etc.) and which of the users have interacted with the phishing website. The results of such investigations lead to 'potentially compromised' credentials. I believe it is good practice to force a password changes on 'potentially compromised' credentials as well.
Quintessence
If your CyberOps is mature enough to execute the above procedures reliably and repeatedly, there are no reasons to keep expiring passwords. You are ready to take this security burden off the shoulders of your users and hand it to the CyberOps team.
If you like what you read and want to chat about it, you can find me at https://ioc.exchange/@seb .
If you don't have a Mastodon account yet, feel free to join https://joinmastodon.org .
— https://pages.nist.gov/800-63-3/
https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/