Category: Policy and Procedure

Understanding password requirements

The Cybersecurity and Infrastructure Security Agency (CISA) just published new password requirements and it can be counterintuitive to say the least. Unfortunately, it doesn’t seem like they did a great job of explaining why things are changing and what the changes mean, so I’ll do so here.

For at least five years now, researchers have been showing that complexity and rotational requirements, special characters like ^%$! and rotating to new passwords every 90 days(or 30, 60, 120), is actually less secure. This is where it becomes counterintuitive and when trying to just say we’re going to change the password requirements based on new standards falls flat. You would assume that making things more complex and changing them makes a password more secure, and you would be right in a technical sense. When taking the overall picture, though, this breaks down. Special characters means passwords are harder to come up with and harder to recall and being forced to change them four times a year is a burden, especially when you consider the average user has to have passwords for 30 different things between their work and personal life. (LOOK THIS UP!) So, the average user with their average amount of passwords is now making it as easy as possible to remember and that means using the same password everywhere they can and as often as possible, only changing up with a different character. Most people in IT know that Spring2022! is pretty insecure, but usually works within password requirement restraints. Oh, and then when it’s time to change we’ll just go ahead and make it Summer2022!. Problem solved.

So, the likelihood of a breach becomes higher because your users are now reusing their Pinterest password, bank password, and work domain password. Cybersecurity does not exist in a bubble and neither should the policies we live by. I’m sure from a technical standpoint password requirements can be created to not include common words, dates, and whatever else we could dream up, but users will probably still write them down and lose them, email them to themselves, put it in a spreadsheet with all their other passwords in a Google Doc, or whatever else they could do to make it easier. They flow in the path of the least resistance and we need to give that to them. In the case of passwords, the path of least resistance is longer but with fewer constraints. At least 12 characters, but with no requirement for special characters and don’t reset it unless there’s some need. Tell them to use a phrase that makes sense to them. I look around my office walls for words to make into phrases.

Fiscally speaking, you aren’t going to have as many calls coming into your IT help desk or lone IT person for help with a password. If you can cut down on workload you can keep from having to add staff or be able to concentrate on projects and priorities that matter to the organization more than helping someone reset their password four times after they reset it because they can’t recall it or wrote it down incorrectly (once again, writing it down!)

What is Zero Trust?

Pretty sure I know what zero trust is as I use it. Can I define zero trust, though? We’ll find out.

You’ve probably heard at least one person in IT grumble, “Never trust, always verify.” And that’s about the bulk of zero trust. There’s a whole NIST publication (NIST SP 800-207 Zero Trust Architecture) on zero trust and that’s what I slogged through, but really you just need to remember what that person grumbled in a meeting about cybersecurity three years ago. What that saying means is that everything on the network is verified for identity and context every time it tries to access a resource.

To really get it I had to take a little trip down memory lane to what apparently was only the year 2018 when there was no zero trust and everything was implicitly trusted (not true, but it’s my story so stay with me). AdminJane logged into the VPN while on vacation in Eastern Europe so she could do some server updating. After logging in through SSH using her admin username and a password she could update that fancy web server and then jump on over to the print server no questions asked. And apparently, that’s how things were back in the day. Once you get through the firewall everything on the network just assumes you are good to go. But what if AdminJane isn’t really on vacation and all that happens at 3 am? Probably not cool, but apparently once you are in you are in. Nefarious or not. Was it really like this? ehh, not really. But close; and for the most part, it still is pretty close today.

Okay, so back in the day you get through the perimeter and you’re into everything. With zero-trust, though, all that communication between enterprise resources is checked and double-checked and, of course, encrypted. Not only does it ask for the correct password from AdminJane (and hopefully now some multifactor), but it also uses some context. That fancy $15k next-gen firewall is making some choices now and some of those include location and time. Ever get an alert that someone tried to use your credit card number and it was caught because you used it in Kalamazoo, Michigan but then someone tried to use it in Sacramento, California three minutes later? Your firewall is doing something like that. Once you get in, though, the verifying continues. Various parts of your security infrastructure are working together to constantly be vigilant. Identity and access management is making sure the right resources go to the right person when they need them, the firewall makes sure that person isn’t using ports they don’t need at times and places they shouldn’t, the SIEM is pulling all the info and tracking. On and on in what is now called the Software Defined Perimeter.

The one thing you should keep in mind is that zero trust isn’t a set of tools. Zero trust is a process and culture. Zero Trust is the idea that something shouldn’t be inherently trusted just because it made it through the front door and everything you do to implement it should be based on that idea.