Well, Jacob, you can probably tell how important I think 6.4 is,
because I've given it like its own whole module.
Right.
My experience of not being an assessor,
but actually being the person in the organization
watching my beautiful PCI environment degrade gracefully
as people keep doing things to it,
says to me that change control is the most important BAU.
Do you agree?
I think so.
I think being able to manage your changes,
being able to track them, to document them,
to understand what happened, how you test them,
how you make sure they don't create adverse security impacts is really,
really important.
So the DSS has got some particular requirements there
about backing out and things like that.
Right.
My most important thing that I really want to talk about in
terms of change control is change to scope,
is that what the business is about to do,
how does it change the scope of your assessment?
You know, does it add stuff into the assessment?
Does it, do your firewalls suddenly, does your perimeter change?
Right.
Do you all of a sudden start holding your business process that you didn't have?
As an assessor,
how many times do you go to an organization and the environment you looked at
a year ago is exactly the same as the environment today?
It does happen.
Right.
It does happen.
It is uncommon though.
There's usually at least something that has changed, right?
Now,
sometimes they're not radical and sometimes they're not so
significant that they really change the scope,
but that does happen.
Hey, we got this new business process, we have these new systems,
we bought this new entity, we got rid of some stuff,
right?
Yes.
You know, all of that.
Or some people.
Right!
In fact, the people who used to do the PCI stuff.
Yeah, we got rid of them, right?
Because they were just costing money and complaining,
and now it's so much easier that we don't have to worry about scans.
So architecturally, is there a way,
is there a way of helping organizations be resilient to change architecturally?
I think, I think from a change management standpoint,
right,
some of the things that you maybe want to look at in your
records keeping or in your sort of process are,
does it affect your scope, right?
You know, and that can be like a binary sort of flag.
Are you tinkering with firewall rules, right?
Then maybe you need to get your information security or your compliance
people involved to say does this impact our scope,
right?
Or does this bring in some new process or does this affect a system that,
you know, stores processes, transmits, something like that.
And I think knowing when to rope in your security people
who can give you some analysis to say, you know,
maybe this is relatively subtle, but it has these far-reaching implications,
it's pretty important.
As opposed to just like, we made a change and we documented it,
and then you find out about it after the fact and you tear out your hair.
Now I think one of the big things of DSS is that there's no
independence of assessors and advisors.
There's not.
However, this is actually one area where it's a real strength,
because would you like to be called in as a QSA before
someone does change to give them a steer?
Yes.
Yeah?
Every time.
And that's I really would see is that now if you're doing changes that
affect the scope or the CDE or your core business processes,
when I was assessing, I always like to find out,
like when they do the change,
not when I came in at the end of the year to do the reassessment,
and it's like, oh, you should've told me,
because if you'd have done it like this,
or we knew about it earlier,
it would be much easier to keep you in a compliant state.
Right, well, and I tell my clients, do this in your planning stage, right?
Like before you deploy, before you start writing code,
before you commit resources and opportunity costs to something,
let's talk, right?
I don't even want to charge you for that,
right,
because it's going to save me a ton of time and grief on the
back end if I can look at something and say,
if you do that, you know, here are some consequences,
right, or if you do that,
you're going to drive off a cliff from a compliance standpoint.
Great.
So let's now talk about the actual change control assessment.
So you come in for your annual assessment,
you're about to assess 6.4, what are you looking for?
So obviously procedures, right?
Although after a while, a lot of change control procedures start to run together,
and then you know, show me your population of tickets,
right?
And you know,
we talked in requirement 1 about some change management stuff for that right,
and a lot of that mirrors what's here on requirement 6,
which can apply to software or applications that you're developing.
It can apply to infrastructure.
I've even seen organizations have their user management,
you know, work in the same kind of change management repository,
right, because all of that, you know, can work together.
And so I want to see the different kind of strata of changes,
and then I want to get some samples out of each of that.
I want to understand what the size of the population
is and then pick some tickets.
So you're actually going to go in, randomly pick some tickets,
and check that the procedure's being followed?
Right, and actually read, you know, some of the text in those tickets,
right, where they talk about, this is how we tested it or this is what we did,
or this is why it's here, and then pull at those threads and say,
tell me a little bit more about this.
It sounds to me this might be a common course of failure.
It can be.
Usually,
this requirement sort of travels together with some of the
software security things that I think we're going to talk about
shortly where the change ticket often has a lot of like the
code review or other things.
And so it's not so much that the change management stuff
in 6.4 is where things can fall down, or it fails catastrophically,
right?
But if it's also the vehicle for the 6.3,
the software development stuff, that's often where I find more failures.
Okay, great.
What if people fail on their second, I mean,
you know, you get to the second assessment,
you're looking back historically rather than optimistically forward.
Right.
You see there's a lot of failures in change control,
how does the organization get into a compliance state?
I mean, are they now noncompliant for the rest of their lives?
Well again, you know, there's a lot of the idea that okay,
we fix things and we go forward in PCI DSS writing; you're not sort
of compelled to sit out of a compliance state.
Now again, if you're showing me year over year,
you do a little bit of change management around the assessment time,
you let it all go in the interim,
you scrape it back together when I come back around,
right,
then I guess I really want to reevaluate my
relationship with you as your assessor, right?
Or at least try to understand what's happening here.
Is this a lack of leadership?
Is this some sort of competing priority?
Is this something else that's giving rise to this,
we only do change management when Jacob is staring over our shoulders?
What causes that, right?
And if it's just we only do compliance three days out of the year,
you know, then I think we need to be sort of done working together.
Okay, and that's your sanction as a QSA is like, we're done working together.
Well, and that's kind of the best you can do in many cases is to realize,
I don't want renew.