PCI DSS has recently changed the way that we have to do risk assessments. You may recall
that in the past we had an article about how to complete a risk assessment for PCI DSS but
everything is about to change in version 4.0.
In version 4 of PCI DSS the focus changes from a broad risk assessment that has to follow a
standardised risk approach such as OCTAVE, IS 27005, or NIST SP800-30 to set of “targeted
risk assessments” or TRA. The TRAs are focused on a combination of periodic tasks as well as
specific risks that PCI cares about and which could affect your PCI DSS compliance the most.
Examples of some of these specific risks are:
- TLS configurations and cipher suites
- Encryption key algorithms and strength
- Hardware and software that no longer supports your PCI compliance or is going “End of
Life”
From that list you’ll notice that PCI DSS is really focusing in on the things that you need to stay aware of and plan for as part of your ongoing compliance.
Now, this doesn’t mean that the old risk assessment is no longer helpful, and you don’t have to stop using your old risk assessment methodology as long as it supports the new risk assessment requirements. So standard, accepted methodologies like ISO still remain very valuable to a structured approach to risk.
In this post we are going to talk a bit more about how you can improve your approach to risk, and things you might need to consider for how you maintain these new risk assessment requirements.
Periodic Task TRAs
Throughout PCI DSS v4.0 you will see quite a few mentions of risk assessments to show how
you determined the frequency of a periodic task. For example, you will need to ensure you have
a risk assessment that results in defining how often you should inspect your payment terminals.
Sounds simple, right? But here’s where things get bit complex. The reason I say that things get
complex here is because you might have different systems with different levels of risk. Building
on that initial example of inspecting your payment terminals, you might have a combination of
attended terminals which sit with one of your frontline staff. You might also have unattended
payment terminals that sit out in a car park, for example. Sure, not everyone will have multiple
types of payment terminals. But this just gives an example of why we might need to not just rely
on a single TRA to be able to meet your PCI compliance. You might have to know enough about
your environment to know when you need more than one to determine different frequencies,
based on different risks.
Example of a Periodic Task
Take your payment terminals that sit with your frontline staff. If they’re behind a secured desk or
there’s always somebody watching over them. Maybe there is a reason to inspect them a little
bit less frequently. But what about those ones that somebody might not be watching over? What
about that payment terminal that sits at the back of the car park and isn’t covered by your
standard CCTV that you used to make sure that nobody is doing anything dodgy in the car
park? Well, maybe these are the kind that you need to take a look at a little bit more regularly
just to make sure that somebody hasn’t tampered with something that is a low hanging fruit.
And so from these two examples, what you see is that they don’t have the same risk profile.
One might be much more likely to be tampered with than another. So applying the same
methodology for both might not be what you want to do. That’s not to say that you couldn’t
examine them all daily or multiple times a day. But you might have scenarios where you will
want to consider the risk for the periodic performance of task differently based on either the
system / process or the likelihood of an event occurring if there is a significant difference that
you want to account for.
What’s Included in a TRA for a Periodic Task?
So what do you need to include in your TRA? You need to include:
- the assets that are being protected,
- the threats that you are protecting those assets against,
- the factors that contribute to the likelihood or impact of that threat being realised
The result is a documented analysis that determines and justifies how frequently you are
performing the task in order to prevent that threat from being realised.
These TRAs need to be reviewed at least once every 12 months to make sure that they are still
accurate and up to date. And that means that if you need to update them, you need to do that
as part of your annual review.
Customised Approach TRAs
The customised approach is certainly not for everyone. The customised approach is only
available if you are doing a full report on compliance with a QSA meaning you cannot do the
customised approach as part of an SAQ. If all you do is an SAQ. You don’t need to read this
section at all.
The customised approach has a very specific way that you need to complete your risk
assessment. A risk assessment needs to be completed for each and every requirement that you
do a customised approach for and you have to make sure you document all the information in
Appendix E2 of PCI DSS v4.0 or you can use the table right out of that appendix.
Because we expect that few people will take the customised approach, this is where we will
leave it for now. But watch for a specific post about the customised approach in the future.
Hardware and Software Risk Reviews
The last thing that you want to find out during one of your PCI assessments is that the
operating system you are using has suddenly gone end of life or is no longer supported. This
means that you will not be able to meet PCI compliance unless you are able to figure out a way
to use a compensating control or maybe you end up scrambling to quickly upgrade. But we
know that a lot of risks come from using out of date hardware and software because they can
no longer receive security patches. So to lessen this risk a little bit, PCI wants to make sure that
you are proactively identifying when there is hardware or software that might pose a risk to your
environment.
At least once a year, you need to review all of your hardware and software to make sure that it
continues to receive security fixes from their vendors promptly. You also need to make sure that
all of your technologies continue to support, and they don’t preclude your PCI DSS compliance.
What does this actually mean? This is that sort of scenario where, for example, your hardware
might not support the minimum number of characters for a secure password. Or it could be
where the database solution that you are using supports only disc encryption but not column
level encryption.
You should also be updating your hardware and software risk document anytime there’s an
announcement about a hardware going “end of life” or being no longer supported by the vendor.
And at the end of the day, what you’re going to need to do is have a plan that’s been approved
by senior management to remediate these technologies that won’t support your PCI compliance
anymore. Does that mean that you have to replace them immediately? Probably not. But you
will still need a plan, and there’s a good chance that if they won’t meet your PCI compliance
now, you’ll still end up doing a compensating control until that plan has been fully implemented.
Cryptography Risk Reviews
One of the other types of risk assessments that you’ll need to take a look at in PCI version 4 is
around the cryptographic cypher suites and protocols that you are using in your environment.
This includes the encryption that you are using to protect the data in transit, as well as when it
is stored or at rest. As a starting point, this means that you have to understand and have an
inventory of all of the cryptographic cypher suites and protocols that are in use. That inventory
also needs to include the purpose and where it is used. Just like hardware and software, you
need to be actively monitoring industry trends.
Changes to encryption should not be a surprise. Organisations like NIST announce deprecation
and disallowed configurations several years in advance. For example, NIST announced in 2019
that three-key TDEA is deprecated through 2023 and disallowed after 2023 for encryption of
data.
And the reality is, if we’re talking about encrypting card holder data at rest, you might need a
few years to be able to change your encryption if the algorithm or key strength you use is being
deprecated or disallowed.
And once again, just like your hardware and software, you need to have a documented strategy
to respond to anticipated changes in cryptographic. Vulnerabilities as well. The most likely
scenario that you’re going to encounter here is changes to TLS configurations. Cypher Suites
for TLS are regularly updated and identified when there are weaknesses. In mid-2022, we saw
a number of cipher suites starting to result in failed ASV scans. So you will almost always see
changes to TLS configurations come through in your vulnerability scans. We understand that
sometimes you can’t change your cypher suites right away because your customers need to be
able to use them. But that’s where you need to be aware of where they are used and what the
actual risk is so that you can come up with a migration plan to protect your customers and
minimise your risk.
How do you Document Your Risk Assessments Now?
So there’s a good chance that how you document your risk assessments is going to change.
The overarching organisational risk assessment doesn’t often lend itself nicely to being able
to identify the frequency that a task is being performed at. So what this means is you’re probably
going to have to change the way that you document your risks a little bit.
One approach to looking at this could be to take a look at the template in Appendix E2 of the
PCI DSS standard. In saying that this template does not necessarily translate identically to what
you will need in a TRA. However, Sections 1, 3, 4, and 5 of this appendix do provide a
reasonable starting point for how you can get started. These sections cover:
- The control you’re performing
- Wha the threat is that you’re protecting against
- What the likelihood of “mischief” occurring is
- What the impact is if that “mischief” occurs
- How often you need to perform the control to reduce the likelihood and impact (and it’s
helpful to also include information about how performing it at this frequency would result in a lower frequency or impact) – this must be justified - Sign off by an appropriate member of the organisation who is accepting the risk of
performing the control at the defined frequency - The date that the TRA has been completed – and if you’re simply reviewing it and it
doesn’t need an actual update each year, make sure that you include the date it was last
reviewed as well.
This isn’t the only way to do it and there is a bit of flexibility – unless you are doing a
customised approach, in which case the information that needs to be captured via Appendix E2
all needs to be present in whatever format you decide to use.
How Do You Organise Your Risk Assessments?
And after all this, what you’re probably going to notice is that you’ve gone from one, maybe two
risk assessment documents to a half dozen, a dozen, maybe even more in a very complex
environment. And that means that you’re going to have to have a process to actually track your
risk assessments. We would strongly recommend that you do something to track each and
every one of your risk assessments, including:
- the PCI requirement it relates to,
- the system(s) it applies to,
- who is responsible for the system / risk assessment,
- the date that it was completed/reviewed, and
- the date that the next review is.
This goes back to what I mentioned earlier in the article where I said that you might have
multiple risk assessments for a single control and those risk assessments might have multiple
owners for the systems. each of these risk assessments might have been done at a slightly
different date which means that they might have different review dates. And if you want to keep
on top of all these risks, you need to make sure that you can quickly and easily identify that all
of your risk assessments have been completed and reviewed at the required (annual)
frequency
Will Everyone Have to Do All these TRAs?
Thankfully, not everyone will have to do each type of risk assessment / TRA.For most
organisations you’ll need to do a TRA for the tasks that you perform at a “periodic” frequency.
But that might still mean you’re doing at least several risk assessments every year. And for
many of the SAQs, including a risk assessment will be quite a new requirement.
For more complex organisations such as those using SAQ D (merchant or service provider) or
completing a Report on Compliance (merchant or service provider), you’ll likely be looking at all
the types of TRAs – possibly excluding the one for the Customised Approach.
Need Help?
Where do you start? If need help with PCI DSS, risk assessments, or how you can start
meeting the controls in PCI DSS v4.0, Talk to us to see how we can help you.
