So, what exactly is this and how is it different?

At first glance most of you see this and think to yourselves, “I already do risk assessments, so I am good.”  That line of thought would be a fast pass (don’t sue me Disney) to non-compliance.  This new process is not the same thing as the current risk assessment you are required to do on an annual basis.  Let’s look at the change in terminology and discuss what that means for you.  The annual risk assessment is now a targeted risk analysis.  An assessment is a form of judgement.  To perform an assessment, you need a set of prescriptive controls, or standards (like PCI) that can be used as a guide to measure against.  In the end, a summary finding, or judgement, can be issues on if the control requirements were met.  This is how PCI works under version 3.2.1.  They say, “passwords need to be at least 7 characters” and your environment password settings are judged against that required standard and found compliant or lacking (non-compliant).  How does this relate to the TRA?  Directly it doesn’t (unless it does for you specifically, but more on that later), but is just an example of what an assessment is in its purest form.

Ok, so that is an assessment.  What is an analysis?  My favorite way to answer this question, as it pertains to PCI is from the 2^nd listing at dictionary.com: “this process as a method of studying the nature of something or of determining its essential features and their relations”.  Looking at the nature of the risk for a specific system to better understand the “essential features and their relations”.  What are the risks to this system and let’s track them, dig into them, and determine the true likelihood and impact of a compromise.  In a nutshell, you are now going to look at potential attack vector points through the microscope of “How, what, when, WHO, and how bad” to determine individual system/environment threat appetite. 

Ok, so there is a difference.  What do I do with this information?

Great question internet user!  In PCI v4, the TRA is the gatekeeper for doing a customized approach for any of your controls.  To use the customized approach, it requires that the entity being assessed has performed a TRA for EVERY control addressed by a method of compliance that is outside of the standard control language/requirements.  With the change of approach for PCI coming in version 4 (meeting security objectives over just meeting the standard – for you TTRPG gamers it is RAI v RAW), the ability to document and justify why security in place is sufficient for PCI compliance is required.  Any (all) TRAs in use within the entity must be developed, tested, and implemented prior to the start of your annual PCI assessment.  On top of that, the QSA that works with you to develop the TRAs within your environment CANNOT be the one performing your assessment (checks and balances).  My advice would be to take that aspect seriously and engage a secondary QSA-C for development of the TRAs from the one doing your assessment, if you can find one doing this level of work. 

There are also some situations where the TRA can be used to determine how often security reviews need to take place.  It is no longer a default to do everything on an annual basis, instead companies are expected to understand their risk in enough detail to make the judgement call on how often these take place.  Sometimes, due to system isolation and lack of modifications (or system delicacy) you may not feel it is needed to do security reviews more than every couple of years.  Other systems, due to sensitive nature of the work being done and possibly high turnover of the workforce with access to the data, you may need to do some formal review process quarterly – or monthly.  I know this was written vaguely, but I want you to be aware of this so a conversation with your QSA of choice can take place, not influence you in any specific direction.

Conclusion

On initial glance the TRA looks to be less work than the current risk assessment being conducted for v.3.2.1.  This, however, isn’t the case.  To do a proper job, with sufficient environmental coverage, requires you to start with the current risk assessment process most likely as a way of identifying the area in need of the TRA.  There isn’t a requirement for a risk assessment to be conducted for the identification of areas needing a targeted risk analysis.  You can just use them when your security team opts for the customized approach, or as a justification method for modifications to some of the PCI annual reviews (FYI – this would also be considered a customized approach process).  However, which ever path you take the TRA is going to require that extensive knowledge in the areas of risk analysis, your environmental factors (technical, process, human factors), and possibly threat modeling and custom security control creation.  These are all the areas utilized when using the targeted risk analysis in your toolbox to assist with achieving compliance, and overall security.

As always, thank you for taking the time to read my thoughts on this.  I know we could go much deeper into the topic, and I would love to provide any details that interest you on this (or any other topic).  If you already have a trusted security expert in your organization and/or as a third-party consultant, reach out to them and seek a better understanding of this process ahead of the implementation of PCI v4 in your environment as the assessed against standard.  Most companies won’t (and shouldn’t) use customized approaches during their assessment.  That is something for the truly mature security programs, but that doesn’t mean you shouldn’t talk it over with your relevant sources and make the determination that is best for you and your company.

Feel free to reach out to me directly with questions or to have a conversation via my email and/or social media information on the TBF website.

Cheers – Shawn!

The post PCI v4 – Targeted Risk Analyses (TRA) appeared first on Shawn's Blog.