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.

Chief Technology Officer/Chief Information Officer (CTO) – The CTO, also known as CIO, is the head of the company’s technical assets

The CTO’s focus should be on making certain that the Enterprise is running as smoothly as possible and it set up to support the key business objectives.  Depending on the size of the company, the departments under the CTO umbrella have a wide range of responsibilities that have some aspect of building and supporting electronic products and/or business processes. In a nutshell, the CTO is the person that translates the executive plans for the company into “technical speak” and controls how the IT related staff works to support those executive plans.

Chief Information Security Officer (CISO – sounds like See So) – The responsibility of this position is the integrity of the technical systems

The CISO, in most situations, will report to the CTO.  IT Security is the primary driving point of this person/department.  Again, depending on the size of the company the title may change some (Director of IT Sec, VP of Cybersecurity, etc.), but the function will remain the same.  A number of companies I work with also “outsource” some of the work to internal operations or third-party companies to manage the day to day efforts, while serving in an oversight and advisory manner.  The where and how the work get’s done is less important than making sure that it is done correctly.  This group also tends to be the primary point of contact when working with external auditors/assessors on compliance related efforts.

Data Privacy Officer (DPO) – Tasked with representing the customer’s interest within the environment

This position is a relatively new position that is quickly becoming one of, if not the most important leadership position in the enterprise.  It also has a much different approach to the focus of their mission.  The Data Privacy Officer’s main focus is on the integrity and management of the customer data.  I know what you may be thinking right now.  “Didn’t you just say that was the job of the CISO?” Well, yes.  I did say something similar to that.  Let us look again.  The DPO’s main focus is on the integrity and management of the CUSTOMER DATA.  There are two subtle differences in the approach between a CISO and DPO.

1. Customer Data – The DPO’s approach is that as a representative of the customer.  Their job is to make certain that the company isn’t doing anything that places the customer at risk or acts in a way that is outside of the agreed upon terms between the company and the customer that provided their personal data.  This is a direct response to the focus of privacy acts and regulations popping up around the globe, such as GDPR (EU Privacy) and CCPA (California) and the expectation of many more governments passing similar laws.
2. Hierarchy – Typically the DPO is outside of the IT department.  While they are a technical resource, and require technical knowledge to do their job properly, due to the nature of them being a voice on behalf of the customer they usually report outside of IT to avoid conflicts or internal pressure that may sway them from doing their job correctly out of fear of losing it.  In larger companies the DPO will report to the legal department.  In companies that don’t have legal departments in house, they can also report directly to the President/CEO.  Of course, that does not mean there is a need to do a reorg if this isn’t how you have the structure within your company.  If things are working well and the DPO is a Rockstar – then don’t fix something that isn’t broken.

conclusion – What does this mean for the data privacy needs of your organization? 

To be honest, I cannot give a specific answer on that (without talking to you.)  My best suggestion would be to have the round table discussion with the leadership of your company and confirm that you have someone that is designated as the “voice of the customer” and get them trained on how the relevant security regulations will affect your business operations.  You can also hire a DPO.  According to Glassdoor, the average salary for a DPO (as of Sep 2022) is right at $113,000, ranging up to $277,000.  This is a national average, so cost will vary drastically based on the market.  You can also hire consultants if looking to save money on annual spending.  You could probably get a good privacy consultant for a third of the cost of a full time DPO, that can work with  your IT and HR leadership to build, design, and implement your privacy program in a compliant manner across all areas you are doing business.

As always, if you have any questions reach out to us via social media or the contact information listed on the website.

Thanks for reading.  Talk to you soon!

Shawn Adams – @TBF_shawn (twitter)

The post Decluttering the IT Sec Alphabet for Data Privacy appeared first on Shawn's Blog.