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.

Overall Thoughts

Keeping with the general direction of the maturation of PCI with version 4, Requirement 1 is all about expanding the language to be more encompassing of changing technologies and assuring management takes ownership of the program.  One of the common shortcomings within security programs is figuring out who will own each aspect of the program.  The more complicated the environment, the more complicated the organization structure, and the number of security standards effecting the company all play into a (sometimes) overwhelming jumble of chaos that requires numerous specializations among the staff (PCI, HIPAA, SOX, FedRamp, GDPR, etc.)  Not wanting to get lost in the shuffle, PCI is making a point (that you will see mentioned in every post in this series) regarding not losing site of the importance of protecting consumers and their cardholder data.

What’s New for Req 1 in v4

The only net new item in version 4 for requirement 1 is the new 1.1.2, which states “Roles and responsibilities for performing activities in Requirement 1 are documented, assigned, and understood.”  This goes back to what I was mentioning in the previous paragraph.  A formal document stating who is “responsible”.  An interesting note though about how this is worded.  It doesn’t say to document who is responsible for requirement 1, but rather “for performing activities” are “documented, assigned, and understood”.  In short, for each requirement in section 1 of the PCI DSS you have to list who is responsible for actually doing the work, confirm it has been assigned to someone, and they have to demonstrate understanding of the processes, as the apply to PCI.

Changes to the existing controls 

A decent number of items have been changed between v3.2.1 and v4.  To keep track of them all, I am going to bullet them out for you and give a (very) brief note on them.

• 1 (in general) – Evolving Requirement – Changing the terms “routers” and “firewalls” for a more open “network security controls”.  This is done to allow for an expansion of acceptable technologies that do the work normally associated with firewalls and traditional networking equipment.  It also opens the door for some outside the box solutions, for those wanting to use the customized approach for any areas.
• 1.1.5 – Evolving Requirement – Now will be covered under 1.1.2
• 1.1 – Clarification/guidance – Now will be 1.2.1 and focus on defining and maintaining configuration standards.
• 1.1.1 – Clarification/guidance – Now 1.2.2 and has additional clarification that change control documentation in Req 1 must match those of Req 6 (6.5.1 specifically)
• 1.1.4 – Clarification/ guidance – Removed, as the SSC deemed it redundant.
• 1.1.6 – Clarification/ guidance – Split into two separate requirements (1.2.5 and 1.2.6) to allow for specific intent of each to be clearer.
• 1.1.7 – Clarification/ guidance – Is now 1.2.7 and adds more specific language around requirement to review configuration files every 6 months.  (NOTE – Do NOT read this to be twice a year, but actually every 6 months.)
• 1.2 – Structure / Format – Removed.  The SSC felt this was covered in other areas and no longer needed.
• 1.2.2 – Clarification / guidance – Renumbered to 1.2.8.  Additional clarification on intent of securing configuration files.
• 1.2.1 – Clarification / guidance – Split into 1.3.1 and 1.3.2 to provide clarity around the intent.
• 1.2.3 – Clarification / guidance – Changed to 1.3.3 and provides additional details on the intent behind security controls between the CDE and wireless networks.
• 1.3 – Clarification / guidance – Renumbered to 1.4.1 to add specifics on the need for security between “trusted” and “Untrusted” networks.
• 1.3.1/1.3.2/1.3.5 – Clarification / guidance – Combined these three previous requirements to provide a focused intent on restricting ‘inbound’ traffic from untrusted networks.
• 1.3.4 – Clarification / guidance – Removed.  SSC also felt this one was redundant.
• 1.3.6 – Clarification / guidance – Is now 1.4.4 to provide clarity around security that prevents direct access to cardholder data stores from untrusted networks.
• 1.4 – Clarification / guidance – Now listed in the DSS as 1.5.1 and provides clarity for securing devices that connect to both the CDE and any untrusted networks.

Conclusion

Whew!  If you are still with me, then congratulations.  You have shown a dedication to IT security, specifically PCI security that makes you a true leader in your environment.  I don’t currently have a fancy plaque to present to you but know that I am proud of you.  Now, as I stated at the start of our road through requirement 1, it was going to be dry and full of bullets.  I feel like I delivered as promised (sorry).  As PCI continues to mature and adapt to the ever-changing threat landscape, we will continue to discuss it and make sure you have a base understanding of the changes.

As always, if you have additional questions or feel the need to discuss payment card security (or data privacy or any other IT security/risk/privacy topic) feel free to reach out to us to continue the conversation.  If you already have a trusted consultant, good for you on finding someone that you can rely on for counsel.  Either way, make sure you are having conversations to build a better understanding of the changes happening that will have an impact on your organization.

~ Shawn

The post Intro to PCI version 4: Requirement 1 appeared first on Shawn's Blog.