Every DSS requirement, as I've talked about already,
has got the last requirement of the requirements says,
oh, and keep ahold of the documentation that nobody ever reads,
apart from your assessor.
Right.
Well, and what they've done in this sort of current version of the DSS,
since about the version 3,
is they've taken that last sort of sub-number of the major number of the
12 requirements and said here is the policy catchall,
right?
Have policies and procedures that describe all these
requirements that we've just been harping on,
and make sure that they're adequately documented,
right?
Rather than kind of interleaving the policies throughout,
and then you have to go kind of pick them out from various
requirements that have all been kind of pulled to the end.
Right.
So as an assessor, you're looking at those policies.
Do you read them?
Yes.
Okay.
And what about a policy statement like this?
My policy is to comply with PCI DSS.
Does that work for you?
No.
Why?
Well, because I want to know how your organization is doing it.
Okay.
If you want to say,
as your sort of introductory sentence in a particular policy section,
is my goal is to comply with PCI DSS with respect to
firewalls and networking devices, and then here is how I do it,
okay.
I see people subbing policies off the internet for PCI DSS compliant policies.
Any good?
I think there's a range of them from probably okay to unspeakably terrible.
I would say, in any case, even if there was a really,
really great policy on the internet that you could purchase or
download or torrent or however you acquire it,
in all cases,
if you are unwilling to modify it to suit what your organization does,
then it's a mismatch, right?
Or in one circumstance I saw,
or even do a search and replace to put your name into the policy.
I mean, if you can even do that, that's the tell, right?
Or if you describe like CISOs or other roles within the
organization that you clearly don't have,
that's a pretty obvious tell that you downloaded this and
didn't actually give it a look-see.
But even if it's great, right,
if it doesn't describe what your organization actually does,
then you're kind of missing the point.
Because, and it's a long time, as I said,
it's a long time since I've actually been an assessor,
but I think it says you have to look at the policy and
then ask people if they know about it.
Is that right?
Yeah.
What's your testing procedure for policy?
There is that, right?
If the policy says here's what we do for cryptographic key management,
or here's what we do for network firewall devices,
or here's what we do for change management,
and then what people describe to me when I say tell me
about your change management process, show me some tickets,
show me some of the process flow, and if those don't add up,
then I've got a finding where I say something's not right here.
Either the procedure is wrong, right, or what you're actually doing is wrong,
right, or maybe both, right?
And my experience of looking at data compromise is
is that people just didn't have, they didn't even know the policy was there.
So the policy might be an okay, but they weren't actually doing it,
or the two things just never matched up.
And when I've been managing any infrastructure,
anything,
I'm trying to get to the capability and maturity model at least level 3 where
people actually know what they're doing and it's repeatable.
If I want to change to a firewall done, it's always done the same way.
And you could only do that by having policies and procedures.
I know it sounds really dull and boring,
but it gives you that quality of management,
doesn't it?
Right.
Well, I mean dull and boring is, I think,
actually preferable to terrifying and unknown,
right, which is the alternative, right,
when you don't have meaningful procedures,
right?
And like, did this thing actually happen?
Did somebody do their job?
Are we wildly unprotected on the internet?
I don't know.
That's not a good situation.
And you said that it was interesting,
because all the policy used to be stuck in 12 at the end of the DSS,
and the SSC move them to the end of every major one.
And we're not going to talk about policies for every single 12 requirements.
I thought we'd covered it in requirement 1.
One of the reasons was that if you look at a report on
compliance or if you look at any organization,
I think requirement 1 is always done brilliantly because it's the first one,
right?
And requirement 8, 9, and by the time you get to requirement 12,
people have lost the will to live, and often assessors have lost,
if you've got six days to do an assessment,
you've got the last half day to do a requirement 12,
so it sort of got overlooked.
And so I know from people on the SSC that one of the
reasons for moving the policies into each requirement was
at least that when the QSA was, you know,
when they had their head in firewalls,
they'd look at the firewall policies rather than get to the end and go,
oh, I need to look at your policies now.
Now,
I know some QSAs would have actually more sense and did the
firewall policies with the firewalls,
but it was very obvious that some people said,
okay, let's get to the end.
Oh, I need your whole stack of policies.
Let me take the policies away, tick, tick, tick.
Right, right.
No,
that's very much the potential concern there and the reason for sort of
spreading that throughout the requirements as they've done.