[Autogenerated] so requirement ate all about identifying users and making sure
that the user is the person who's logging into the system.
So basic identification and authentication.
Yes.
Um,
the thing that strikes me about Requirement eight on we
haven't talked about policies a lot.
We talk about policies a lot when we doing firewalls,
but required 8.1 starts off with.
You need policies and procedures.
Yeah, do.
And that's quite strange for the standard,
because it's like, right right up the front,
like you need policies and procedures.
So So again, you're walking on site is an assessor.
Is that what you reach for?
First, give me your user creation cache creation policies and procedures.
Well, what are typically ask for in the conversation with,
Ideally,
the people who can explain it is Tell me about your user management practice,
right?
I mean, yes, I do want to see the policy.
Yes, I'll read that.
You know when I get it, But tell me about the process, right?
Help me understand.
You know, is there a way that that most of your user accounts get created again?
If you're using Active Directory URL DOM or something like that,
there's probably some fairly well defined process.
Here is how we get requests.
Here is how we vet them.
Here is how we provisioned the users.
Here is how we supply that user with their initial
password or whatever their mechanism is.
You know, here's the sort of lifecycle of create a user.
Make sure that person can get access to it right on that zord of the 80% right,
the other 20% I think it fits into sort of two buckets,
right?
What are the kind of users that don't follow that
process because their user accounts for,
um, going to,
maybe network devices or appliances or other kind
of off the beaten track systems?
Right?
Uh, usually,
many organizations have kind of like one username
process for kind of most of their stuff,
as opposed to a bunch of disparate systems.
Although there are, you know, large,
complex organizations that have a bunch of disparate users management processes.
And that's, you know, consequently more complicated.
But then there are all the little one Z two Z systems that you
have to sort of track down individually.
The other thing that is interesting and challenging is how
an organization manages service accounts,
error process accounts.
These error the the user accounts that are used by a process right
used by a computer and not necessarily by a human.
And you can't get away from those, right?
Like everything hinges on service accounts because
everything needs some sort of user IDE.
Uh, but you wanna make sure that those don't get misused and,
you know, I find, you know, that splits pretty evenly,
right?
There are organizations that, uh,
have a at least some notion of how to manage the service accounts,
how to make sure that there are not inter actively accessible.
Right now, you can't sit down at the keyboard and,
you know,
button mash the password and then log in as some
process account and do terrible things.
Right?
But most access control systems of a setting that say,
you know, disable introduction.
Right?
But some organizations have engineered some things
to run on top of a user account, uh,
in such a way that they can no longer disable that interactivity feature
without breaking the application that rides on top of that right?
And, you know, I said earlier, uh,
good cryptography won't save you from bad architecture and good access
control features also won't save you from bad architecture.
And if you've made the sort of lousy application architecture decision
to ride on top of a user account that has a ton of privilege and you
cannot protect from interactive misuse, uh,
you know very little can save you from that.
Is that a file that is, that a CSS five?
It should be right,
and I find a lot of assessors don't necessarily kind of pull that threat all
the way until they find out the truth of what's happening.
But if I can find, you know, an interactive,
Lee accessible, privileged account that is,
you know, powering some process and they can't,
you know, control the credential in some meaningful way.
Like if I can't disable its interactivity,
then how do you at least manage the credential?
And if the answer is, we can't even change this password and we never have,
because it's hard coded into something,
or there's some other reason why changing it would
break application functionality then, yeah,
it's time.
Start talking about a compensating control or time to start
talking about re engineering this application right,
right or both.
The most important thing again is that you know that's a security issue.
It is, yes, it's a compliance issue.
We keep talking about compliance, but it's a security.
It's a huge security risk.