[Autogenerated] so requirements 78 and nine.
It's all about restricting access to cardholder data and
systems that contain or can influence the security of
cardholder data from a necessity perspective.
Jacob, this is just basic information security.
This is the standard stuff for every organization does.
Whether they got cardholder data, they don't have cardholder data.
So from a necessity perspective, you walk on site,
you're gonna do requirement seven.
Are you sitting down in front of the Active Directory URL that,
like, console on having a look at that?
What?
Tell me what you do.
Well, that could be one way of doing it.
Or if we can.
If we can get at like the Active Directory group policies and say,
What are the what are the roles?
What are the what are the privileges who gets what?
How is that assigned?
How is that?
Managed?
A lot of the stuff in Requirement seven about expressly granting access sort of
travels together with the stuff in Requirement eight about,
you know, authorizing users right?
So is seven is sort of the set up to that right?
Do you have usefully defined groups with certain privileges and some
users get that and some users get something else now because we're
all friends and we actually know we probably looked at our
Active Directory in our organizations.
We know that sometimes this is not the most tidy
apartment organization infrastructure.
How do you deal with that as an assessor?
Because you have to take a realistic view about the way the
organization manages its access control right and and a lot of
access control sort of influence.
The operating system layer, which may or may not sort of directly or usefully,
correspond to access to things like cardholder data,
which is what the requirements generally get at.
And so it may be the case where you know the most salient questions error,
who are the administrators and who are not right or who have some of these
other administrator like privileges and who doesn't on then maybe at the
database layer or at the application layer.
The question is, who can view the card number or not?
Right.
Okay, so you're looking at role based access.
So what's the typical barriers to an organization
doing well on this requirement?
Usually, it's it's either, you know,
just a history of not sort of handling it well and then
having a ton of users a ton of permissions,
a ton of kind of complicated arrangements of who could do what or or
just kind of a lousy process for managing users?
Um, e c.
A lot of organizations who, very deliberately,
as part of their process,
find another user in that same group and then copy that person,
right?
Rather than have that's real based taxes.
Well, that that's that's propagating errors based access.
Okay, I like that.
Yeah, there we do.
Okay.
Any tips or shortcuts you can think of for an organization to do well here?
I mean, something I've done is I've gone and got okay,
We're going to create some new groups.
That right?
I think that's great, right?
Um, you know,
if you if you can burn down some of the default groups or the old
groups that have caused problems and create something new or at
least silo the stuff that's relevant to your in scope environment
into a set of new groups, There you go.
That's certainly what I've done before is like,
Okay, we're going to create a silo,
and this is the administrators with that silo,
and these people have got read only access into that silo right on.
That was quite successfully, The other thing that was quite successfully.
And there are times when you need a reason in i t to do
something that's important but not urgent,
right?
Cleaning up your IDE or URL dup environment is important, but it's never urgent.
Never.
It never makes the business money.
But actually coming up to a first PC,
IDE s s assessment could be a really good time to just,
like, grasp that Nestle it is.
And just get on with it, right?
Right.
And and particularly if you are aware of things like
your mounting technical debt right,
then that that gives you some notion of urgency like,
Yeah, it's not, You know,
things don't stop working tomorrow if we don't go clean this up,
right?
But our technical debt gets bigger and bigger and bigger and harder to manage.
This time goes on, and obviously, you know,
this is this is one of those requirements I've seen people like.
That's a check box requirement, but actually,
of course, if you have someone with access to cut up,
the more people you have access with,
cut to cardholder data or the systems that can control the security of that.
There are more accounts for bad guys to just fish and take over.
So it's actually a really important control is it is.
It gets a lot of,
unfortunately sort of short shrift because it's relatively tiny
in terms of its length and amount of text,
a number of requirements.
And so, yeah, a lot of organizations, just kind of requirement seven.
Yeah, you know, but but it is very important.