[Autogenerated] in the final motion of this course,
we're going to be looking at what I consider to be the
harvest part of PC ideas s compliance, which is to maintain compliance.
And it is especially hard in the first year after
initial compliance has been achieved.
One question you might ask yourself or your management my ask is,
Well, why should we bother maintaining PC ideas?
This complies.
We don't have to have an assessment for another 12 month.
So let's think about it in all nine months time.
I guess there are four reasons why you need to
bother with PC ideas as compliance.
The first is that on the attestation of compliance that an
executive of your organization would have signed they
committed to maintaining compliance.
Secondly,
criminals are always on the lookout for organizations that are not protecting
their cardholder data and maintaining PC ideas s compliance.
The meeting,
All the requirements will make your organization much harder to steal.
Cardholder data from the third reason for maintaining compliance
is in case you unfortunate have a data breach.
Because all of the car brands compliance programs take into account
whether you a PC I DSS compliant at the time of breach and whether it
was a PC ideas s requirement that was missing.
There was the contributions of the breach curry,
and that will be reflected in any enforcement action the brands take.
Finally,
you have tohave an assessment in 12 months and without an ongoing
positive commitment to maintaining compliance,
you will end up running a mini PC idea says Compliance program every year,
which is expensive, and it's not usually what management expect.
In my experience,
I've seen three reasons why PC Idea says Compliance
fails after the annual assessment.
The first is the natural tendency of requirements controls to
slowly lose their effectiveness over time,
something I call control decay.
The second is that no one takes ownership of the schedule tasks specified in PC,
Idea says.
So they simply just don't happen.
And then thirdly, change does happen.
Change happens in multiple different ways,
and these changes affect the cardholder data
environment and move it into non compliance.
Let's look at these three reasons.
Starting off with control decay.
You might remember this graph from a previous module where it discussed
one of the benefits of having an annual assessment,
which is that over time.
The strength of any control or requirement.
DK's and at some stage, the control DK so far,
but it becomes ineffective, but the organization hasn't noticed.
If you're lucky,
your annual assessment will let you know the controls become
ineffective before criminal discovers that vulnerability.
It's a truth that many people don't like to acknowledge,
but every single requirement or control will decay over time.
There are two ways to stop this happening.
The first, which I don't recommend, is optimism.
I mean, you just hope it doesn't happen in the second,
which I do recommend is proactive maturity management of all
the PC Idea says controls and requirements,
you may be familiar with maturity models based on the capability maturity model,
which described five levels of operation maturity of a control,
a requirement or a process.
The first level it is initial,
which means that things will happen in an ad hoc way.
Sometimes it control may work, but it might not.
People will use their best efforts,
but there's never any assurance that control or requirement will be functioning.
The second level means the organizer generally managed to
keep the requirements or control going, but again,
that's down to individual and small team capabilities.
There will probably be some documentation.
People probably know how to do something, but it's no procedural ized.
At the third maturity level, Controller requirement is specified in policy.
There's a management commitment that it should be operational on
where processes and procedures are needed.
These tour also documented procedural ized,
and there's a proactive allocation of responsibility.
Level four The controller requirements actively managed.
So that means they're a target operational effectiveness criteria that
metrics air collected to validate that the requirement is working
according to those defined criteria and steps to put in place to make
sure that when the operational effectiveness isn't met is remediated
and then finally level five, where requirements,
controls and processes are proactively optimized.
Generally,
PC I DSS requires an organization to reach maturity level of three requirements.
Apartment organizations.
Policy on all necessary processes and procedures are documented,
however, to stop control,
decay requirements and controls need to be managed that maturity level four,
where the organization actively ensures that every requirement is working,
and it's a priority for the organization to ensure that
when a control does start to decay.
But it's noticed by the monitoring system or by the metrics on its rectified.
Given that around 300 controls or requirements in PC Idea says is quite a large,
ask for any organization toe operate.
All of these ah maturity level of four was,
I generally recommend is that the key controls are prioritized.
And as an organization gets used to running mawr controls at maturity,
level four, the member of controls run at that level is expanded.
And there are two ways to decide which controls should be
prioritised for that higher level of maturity.
Firstly,
controls that we know that will reduce the risk of a breach
of confidentiality of cardholder data.
And secondly,
those requirements or controls that we know tend to de came or frequently
a great way of determining which controls you know will reduce the risk
of a breach of cardholder data is to go back to the prioritized approach
because by its very definition,
the prioritized approach recommends which requirements and organizations should
do first to reduce the risk of account all the data breach.
So obviously the same prioritization would apply when we were
deciding which controls all requirements to operate.
Ah,
higher level of maturity To understand which
requirements are more likely to decay.
I always recommend the organization's Consult
Horizons Annual payment Security report.
Horizon is a qualified security assessor company and that
also a PC I forensic investigations company.
This annual report is a comprehensive analysis of PC ideas s
compliance across a large number of organizations.
It's based on which requirements the assessor found out decayed when they
went to undertake a second or subsequent year assessment.
And it's also based on which requirements forensic investigators found were not
in place in what should have been compliant organisations.
The conclusions of the horizon report for a consistent between years and
the requirements where decay led to a data bridge,
typically in requirement one.
So that's network segmentation and particularly fire will roll management and
also in requirement ___ that's known vulnerabilities which don't get patched
vulnerabilities introduced by simple coding problems.
According to the report,
the most common requirements that were not in place when the
assessor went to conduct a second or subsequent years.
Assessments of busy not once.
That led 32 a data breach but weren't there when the assessor went
back in a compliant organization and these were internal and external
vulnerability scans not being carried out.
But, of course, vulnerability scans of vital,
because that's how you discover where vulnerabilities have
been introduced into an environment.
And that's typically because other PC idea says
requirements are not being followed next.
The systems had not being patched,
but although the organization had carried out their annual ___________ tests,
they'd not remediated.
The vulnerability is discovered by the ___________ tests that
the management of firewalls and particularly removing obsolete
firewall rules was not carried out.
That multi factor authentication was not properly in
place for remote administration.
That user ID's were poorly managed,
especially related to people moving roles and leaving the
organization that TLS configurations of Web servers were not kept up
to date to prohibit insecure protocols being used.
And finally, the organization's didn't review their logs on a daily basis.
To detect malicious activity on this list of worst maintains
requirements really reflects my experiences an assessor as a
consultant and also from reading the forensic report produced
after organizations have data breaches.
These are the typical requirement the organization's failed to manage.
So, together with the prioritized approach,
this list is a really good starting point for the requirements
that an organization needs toe actively manage her maturity
level of four to prevent control decay.