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.