[Autogenerated] eight, you know goes on for hours,
pages and pages and pages about two hours about you know how long your
password should be and the fact you shouldn't reuse passwords.
And you have to assign a unique password to everyone.
And the one that gets me is everyone should get the
initial password they're giving.
It should be unique.
So, you know, which I find organizations really rarely do.
It's always summer 2007.
Yeah, I found a lot of organizations you know,
have some really crummy static password.
Uh, now the intent,
the stated intent that I heard about the requirement is this was
intended to provide examples of how to pick good passwords,
right.
So I think if you're serious about security,
if you're serious about going beyond what the compliance mandates
says and really protecting kind of user accounts,
the only sort of reasonable thing to do is to use some
sort of password management utility, uh,
memorize a long,
ugly password for that and then create random passwords that error unique
for each account that you store in that password utility.
And that's easier said than done.
Uh, but you know, you can do it.
And we've more or less gotten my organization to adopt that,
uh, you know, with some challenge.
I certainly know for every in I t departments where you have to
manage lots of passwords having some sort off either,
you know, on off the shelf or open source,
password manager or even going out and buying a privileged access
management system actually gives you that control over those those those
passwords it does rather than everyone knowing the password to log onto
the portal exactly to X or for wire.
Right?
And and some of those, you know, password management, utilities.
That error intended for an IT department to manage the credentials to
all of the networking devices or what have you,
uh, then give you some useful audit features?
Right?
You know, nobody is supposed to log in with the local password right there.
It's bound to, you know, tack acts or radius,
which is then bound to l'd app or 80 or something like that,
right?
So everybody can log in with a normal user account unless things break.
In which case, Yeah, you need the break glass credential to get to the thing.
Right?
But that should be a trackable essentially incident, right?
And so if you have some audit capability to say,
Hey, somebody checked out this password and used it right now,
make sure that that was done correctly and make sure that nobody,
you know, hacks of the device.
Essentially, where's the ticket?
Where's the ticket for that?
Right, The required that break glass events.
Exactly.
Right.
And so So for a lot of organizations, I recommend having some sort of procedure,
right?
If you have the utility that supports that great,
otherwise, maybe you need, you know, one of those those free,
open source password management utilities that's under somebody's control,
right?
Who doesn't access the system?
Uh, you know, and contract that kind of break glass sort of scenario.
Um,
one thing that worries me about passwords and on the fact
that standard changes so very rarely,
um is the requirement 8.2 point four to the required
to change passwords every 90 days.
Whereas if we look at the guidance from the National Cybersecurity
Center in the UK on now also missed in the U.
S.
You know, the the advice now is don't make users keep changing the passwords,
right?
Have you had organizations pushback on this requirement?
Now?
I mean, I have I have.
And you know,
the intent behind that idea of saying don't make your users change
passwords as frequently is because a greater frequency and change means
that that users will pick increasingly lousy passwords,
right?
So the notion is that a less variable password,
right that is more complex is better than a more
variable password that is less complex.
So But if if a client says you look, I've read them this guidance,
or in the UK, the National Cybersecurity center Guidance,
right, I ain't doing sorry.
I am not doing right because your clients error no English and wouldn't say S3,
I am not doing requiring 8.2 point four.
What's your response is a necessity e the standards
almost against Google practice.
Now eso in the language and requirement error anymore is the idea,
at least for for composition, Right?
We're talking about seven characters alphanumeric,
which is also not spectacular in terms of password complexity.
Uh,
is that or you could do some other equivalent kind of thing and I
would go so far as to say that you could toss in age,
uh, into that set of factors, right?
So if if what you're doing is essentially charting out how easily cracked that
password is using some sort of password cracking mechanism,
which is a pretty well understood concept.
Right?
And you want to say Okay, you know,
I can have a more complex password that you know are more complex
set of password parameters that is more resistant.
You know, it takes more time to crack, uh,
and thusly essentially achieve the intent of this
requirement by doing something else.
You know, I may write that up a za compensated control, but sure.
So you've met the intense, which is that bad guys shouldn't be able to.
Guess.
User password, right?
Yeah.
Okay.