Month: October 2022

In PCI the focus of requirement 8 is on authentication/user account management.  Making certain that the people using credentials are the ones that are the account holders.  With one of the primary concepts of IT security being the “need to know” process, this feeds right into that.

Overall Thoughts

When I am chatting with my peers in the realm known as “IT Security-landia” (I know, I know. I panicked), one of the common thought processes is around how to mitigate the biggest area of risk in most environments – the human factor.  Not just from external threats, even those are real and need to be part of the overall equation, but also from internal threats.  To get even more granular, internal threat doesn’t just mean an employee who is acting in what I call “bad faith”, or counter to the benefit of the company.  Most of your internal risk comes from employees that just make mistakes.  This can happen via weak passwords, poor management of their own personal information, or being to naïve/trusting of others.  Requirement 8 is designed to help the company reduce the impact from these people (and the others mentioned as well).

What’s New for Req 8 in v4

The new controls in requirement 8 of v4 are:

• 8.1.2 – Roles and responsibilities for performing activities in Requirement 8 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 7 (which was cut from 6, etc.)
• 8.3.6 – Minimum level of complexity for passwords when used as an authentication factor. – Most of the changes are for internal/non-consumer accounts, with an exception for companies with a technology barrier (look this one up)
• 8.3.10.1 – If passwords/passphrases are the only authentication factor for customer user access, passwords/passphrases are changed at least every 90 days, or the security posture of accounts is dynamically analyzed to determine real-time access to resources.
• 8.4.2 – Multi-factor authentication for all access into the CDE.  (ALL ACCESS – this will have heavy impact on call centers and client support groups – plan ahead and start working on the workstream planning and training)
• 8.5.1 – Multi-factor authentication systems are implemented appropriately. (aka, increased assessment requirements and documentation needed)
• 8.6.1 – Manage interactive login for accounts used by systems or applications. (A lot of the system accounts that the enterprise views as “set it and forget it” will require a more active management philosophy.)
• 8.6.2 – Passwords/passphrases used for interactive login for application and system accounts are protected against misuse.
• 8.6.3 – Passwords/passphrases for any application and system accounts are protected against misuse.

Requirement 8 is changing not only how user accounts are managed, but also how system accounts are as well.  Between the changes to system accounts and MFA needed for all users that access the cardholder data environment, you can see where they are forcing companies to exert additional effort into preventing unauthorized users from gaining access to sensitive data.

• 8 – Clarification/guidance – Standardized on terms “authentication factor” and “authentication credentials.”
• 8 – Clarification/guidance – Removed “non-consumer users” and clarified in the overview that requirements do not apply to accounts used by consumers (cardholders).
• 8 – Structure/Format – Removed note in overview that listed requirements that do not apply to user accounts with access to only one card number at a time to facilitate a single transaction and added that note to each related requirement.
• 8.1.1 – Now 8.2.1 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.5 – Now 8.2.2 – Evolving Requirement – Changed focus of requirement to allow use of shared authentication credentials, but only on an exception basis. (Rejoice Root users! Rejoice!)
• 8.5 – Now 8.2.2 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.5/8.5.1 – Now 8.2.2 & 8.2.3 – Structure/format – Moved requirements for group, shared, or generic accounts and for service providers with remote access to customer premises under Requirement 8.2.
• 8.1.8 – Now 8.2.8 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.2 – Now 8.3.1 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.1.6 / 8.1.7 – Now 8.3.4 – Structure/format – Merged requirements and moved under Requirement 8.3. Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.1.6 / 8.1.7 – Now 8.3.4 – Evolving Requirement – Increased the number of invalid authentication attempts before locking out a user ID from six to 10 attempts. (Woohoo!  The helpdesk is happy)
• 8.2.6 – Now 8.3.5 – Clarification/guidance – Clarified that this requirement applies only if passwords/passphrases are used as an authentication factor to meet Requirement 8.3.1
• 8.2.5 – Now 8.3.7 – Structure/format – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.4 – Now 8.3.8 – Structure/format – Moved content about communicating user authentication policies and procedures under Requirement 8.3.
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Clarified that this requirement applies if passwords/passphrases are used as the only authentication factor for user access (i.e., in any single-factor authentication implementation).
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement is not intended to apply to user accounts on point-of-sale terminals that have access to only one card number at a time to facilitate a single transaction.
• 8.2.4 – Now 8.3.9 – Clarification/guidance – Added a note that this requirement does not apply to service providers’ customer accounts but does apply to accounts for service provider personnel.
• 8.2.4 – Now 8.3.9 – Evolving Requirement – Added the option to determine access to resources automatically by dynamically analyzing the security posture of accounts, instead of changing passwords/passphrases at least once every 90 days.
• 8.2.4.b – Now 8.3.10 – Structure/format – Moved content from a former testing procedure to a requirement for service providers to provide guidance to customers about changing passwords/ passphrases.
• 8.6 – Now 8.3.11 – Structure/format – Moved requirement about authentication factors such as physical or logical security tokens, smart cards, and certificates under Requirement 8.3.
• 8.3 – REMOVED (all components covered by other requirements)
• 8.7 – Moved to 7.2.6 Discussed in previous post)

Conclusion

As you read over the list of changes to requirement 8 you will see there is a lot of them.  Don’t let this intimidate you however, as a lot of the changes are changes to the control number and/or just a note to be specific about the personnel that are in scope for it (ie it shouldn’t be applied to retail workers that have access to a single payment card at a time, etc.)  The areas to spend time looking into the impact of your environment are going to be mostly found in the new items.  Not that you can ignore the changes to existing controls, but the new ones have some changes that from a PCI perspective would be on the fundamental level.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  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.  Thanks for taking the time to read my thoughts on PCI v4 Requirement 8.  We will continue to work through each of the PCI requirements each week.

~ S

In PCI requirements 7 and 8 seem to go hand in hand with each other, and if there weren’t so many bleeding changes to 8 going into v4 I would have combined them into a single blog post (but there are, and I didn’t).  Requirement 7 is about access management and 8 authentication/user account management.  Two halves of the same coin.  For this post we are going to just stick with R7, not to be confused with CR7 (if you know you know).

Overall Thoughts

So, as we have discussed in previous posts the council is working to mature the standards in a way to add additional accountability and limit risk associated with human error.  In requirement 7 for version 4, we see a continuation of this mindset.  As you will notice when we run through the changes most of them are focused on some form of oversight. 

What’s New for Req 7 in v4

The new controls in requirement 7 of version 4 are:

• 7.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 6 (which was cut from 5, etc.)
• 7.2.4 – Review all user accounts and related access privileges appropriately.
• 7.2.5 – Assign and manage all application and system accounts and related access privileges appropriately.
• 7.2.5.1 – Review all access by application and system accounts and related access privileges.

Changes to the existing controls 

Requirement 7 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it.  This is very evidence in the changes to requirement 5 existing controls.

• 7 – Clarification/guidance – Updated principal requirement title to include system components and cardholder data.
• 7.1 – Now 7.2.1 / 7.2.2 / 7.2.3 – Clarification/guidance – Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement. (Expanding the requirements within the company documentation, which by its nature will require more involvement from management and business owners).
• 7.1.1 – Now 7.2.1 – Clarification/guidance – Clarified requirement is about defining an access control model.
• 7.1.2/7.1.3 – Now 7.2.2 – Structure/format – Combined requirements for assigning access based on job classification and function, and least privileges.
• 7.1.4 – Now 7.2.3 – Clarification/guidance – Clarified requirement is about approval of required privileges by authorized personnel. (This is one I have clients with long tenured employees having difficulty providing evidence on during their assessments.  If you know you are going to have to provide proof of approval on your administrative staff’s access levels, make a point to have an annual review that is thoroughly documented, in a format that can be exported into an evidentiary document.  Don’t just fall back on using an email from their manager saying “Yup.  Looks good.”
• 8.7 – Now 7.2.6 – Structure/format – Moved requirement since it aligns better with the content in Requirement 7. (Aligns with our earlier comments on the two requirements being two halves of the same coin.)
• 7.2 – Now removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).

Conclusion

As I mentioned at the start of the post, most of the changes to requirement 7 in version 4 have to do with making certain the access management aspect of your environment.  The new areas of 7 are focused on account management and review for user and system accounts and the controls that have been modified are moving around to require a deeper dive into those areas to show compliance with the PCI standards.  Developing proper management policies and processes will be key in improving your security stance in this realm.  In a perfect world you will implement new processes for reviewing accounts (of all kinds) and find out you were already doing everything as you should.  I suspect that some of you are going to have some amount of enlightenment when you start putting together an inventory of system level accounts. (Because if you don’t have an accounting of these accounts, how can you perform the needed reviews on their access each year, as required in 7.2.5.1?)

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  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.  Thanks for taking the time to read my thoughts on PCI v4 Requirement 6.  We will continue to work through each of the PCI requirements each week.

Requirement 6 focuses on application security management.   Some of the terminology (i.e. word choice) has changed in this section, but a lot of the focus is in areas that fall in line with the overall v4 changes towards visibility and accountability.

Overall Thoughts

It feels like the overall vibe of R6 is making sure the people outside of the development shop know what they are doing behind the curtain to me.  Changes towards automation and more detailed record keeping.  Outside of the tech sector (and even inside it for a lot of companies), how many members of the executive team actually understand the processes involved in software management?  I am including not only customized coding for internal applications, but also vendor managed patches and other third-party software solutions.  For most of these people their responsibilities is outside of this space and it makes sense for them to pay attention elsewhere.  However, with privacy laws springing up and maturing globally the days of execs being able to claim ignorance are quickly going by the wayside.  PCI is moving closer to this mentality with v4.  You will see in the changes for Six some of this shift in thinking and maturity.

What’s New for Req 6 in v4

With that said, here are the changes in the form of new controls in requirement 6 of version 4 are:

• 6.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 5 (which was cut from 4, etc.)
• 6.3.2 – Maintain an inventory of ‘bespoke’ and custom software to facilitate vulnerability and patch management.  “Bespoke” is now how we refer to applications purchased from outside of the organization for use with in-scope processes.
• 6.4.2 – Deploy an AUTOMATED technical solution for public-facing web applications that continually detects and prevents web-based attacks.  If you have a solution that monitors and alerts you, so you can act, you need to upgrade it or change it out for a full service WAF.
• 6.4.3 – Manage all payment page scripts that are loaded and executed in the consumer’s browser. This is going to require companies to do some form of the following:
  • Confirm that payment page scripts are authorized.
  • Validate the scripts, to ensure the integrity or trustworthiness of the payment page scripts.
  • Track the scripts used in the PCI payment process through a formal inventory process, complete with a business justification associated with each.

Requirement 6 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it.  This is very evidence in the changes to requirement 5 existing controls.

• 6 – Clarification/guidance – Updated principal requirement title to focus on ‘software’ instead of applications.
• 6 – Clarification/guidance – Clarified that Requirement 6 applies to all system components, except for Requirement 6.2, which applies only to bespoke and custom software.
• 6.3 – Changing to 6.2.1 – Clarification/guidance – Replaced “internal and external” with “bespoke and custom” software.  Clarified that this requirement applies to software developed for or by the entity for the entity’s own use and does not apply to third-party software.
• 6.3 – Changing to 6.2.1 – Structure/Format – Moved requirement for developing software securely to align all software development content under Requirement 6.2.  (Basically 6.2 will not be the content area for development)
• 6.5 – Changing to 6.2.2 – Clarification/guidance – Moving the requirements for training the development staff under 6.2
• 6.3.2 – Changing to 6.2.3 and 6.2.3.1 – Clarification/guidance – Moving requirements for code testing prior to release under 6.2 and split into secondary control if manual code review is in use instead of automated. (Note – if you have an automated syntax checker and a peer review process, both of these will be in-scope for you.  Syntax checkers do not meet the requirements for automated code reviews.)
• 6.5.1 – 6.5.10 – Changing to 6.2.4 – Clarification/guidance – Moving development controls under 6.2 and FINALLY condensing the list of common coding vulnerabilities into a single control.  (So glad for this one)
• 6.1 & 6.2 – Changing to 6.3 – Structure/Format – Moved requirements for identifying security vulnerabilities and protecting system components from vulnerabilities via patching under Requirement 6.3.
• 6.1 – Changing to 6.3.1 – Clarification/guidance – Added a bullet to clarify applicability to vulnerabilities for bespoke and custom and third-party software.
• 6.6 – Changing to 6.4.1 – Structure/Format – Moved requirement for addressing new threats and vulnerabilities for public-facing web applications under Requirement 6.4.
• 6.3.1 / 6.4 / 6.4.1-6.4.6 – Changing to 6.5.1-6.5.6 – Structure/Format – Moved and combined requirements for changes to system components under Requirement 6.5.
• 6.4 – Changing to 6.5.3-6.5.6 – Clarification/guidance – Removed requirement for specific documented procedures and added testing procedures to verify policies and procedures to each related requirement.
• 6.4.1 – Changing to 6.5.3 – Clarification/guidance – Changed term from “development/test and production” to “production and pre-production” environments.
• 6.4.2 – Changing to 6.5.4 – Clarification/guidance – Changed term from “development/test and production” to “production and pre-production” environments.  Also, changed term “separation of duties” and clarified that separation of roles and functions between production and pre-production is intended to provide accountability so that only approved changes are deployed.
• 6.4.3 – Changing to 6.5.5 – Clarification/guidance – Changed term from “testing or development” to “pre-production” environments and clarified that live PANs are not used in pre-production environments except where all applicable PCI DSS requirements are in place.

Conclusion

So, as you can see by all them lovely bullet points in this post, Requirement 6 has a lot going on.  Luckily, some of it is long overdue structural changes to the report (I’m looking at you 6.5.1-10).  Don’t let that lull you into a false sense of readiness on the new v4 R6 though.  Some of these changes are significant from an overall approach to security (automation > manual) and can potentially be the starting point for some projects with hefty workstreams associated with them.  You should start having conversations along these lines ASAP to make sure nothing sneaks up on you and potentially causes security and compliance issues.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  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.  Thanks for taking the time to read my thoughts on PCI v4 Requirement 6.  We will continue to work through each of the PCI requirements each week.

In the past requirement 5 has been approached from the mindset of “just install McAfee and be done with it” (or whatever your AV solution happens to be).  The new direction in v4 expands on the concepts of protecting against “malware” to encompass malicious intent that wouldn’t be captured by your AV solution directly, without possibly some configuration changes.  The council also continues down the path of automating as much as possible to remove the risk of human error (or intentional internal actions).

Overall Thoughts

Personally, I like the changes to R5.  I have been preaching to any client that will listen (and sometimes to random people on the streets) that they need to put more effort into building a secure culture to reduce the human risk factor, since that is the largest attack vector in most environments.  The changes in 5 don’t directly change the culture of your company, but it can reduce the decision points presented to employees, by lowering the risk of phishing, which does have a positive impact on the overall environment.

What’s New for Req 5 in v4

With that said, here are the changes in the form of new controls in requirement 5 of version 4 are:

• 5.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and past this line from the post on requirement 4 (which was cut from 3, etc.)
• 5.2.3.1 – A targeted risk analysis is performed to determine frequency of periodic evaluations of system components identified as not at risk for malware – No longer able to just declare systems as “not at risk” and right them off to focus on other items.  Targeted Risk Assessments (TRAs) MUST be done prior to the assessment starting, so be mindful of that when getting ready to start your first v4 assessment cycle.
• 5.3.2.1 – A targeted risk analysis is performed to determine frequency of periodic malware scans.
• 5.3.3 – Anti-malware scans are performed when removable electronic media is in use.  This one is potentially HUGE.  How many of your employees use USB drives to move files between work and home?
• 5.4.1 – Mechanisms are in place to detect and protect personnel against phishing attacks.  Anytime you see the word “mechanisms” read it to say, “automated solutions”.  As I mentioned previously, a reduction in the amount of phishing attempts that make it to your internal user community will obviously lead to a more secure environment, allowing employees to focus on their actual work.

Requirement 5 is maturing along with the rest of the controls to expand not only the controls but the overall mindset and philosophy behind it.  This is very evidence in the changes to requirement 5 existing controls.

• 5 – Clarification/guidance – Updated principal requirement title to reflect the focus on protecting all systems and networks from malicious software.
• 5 – Clarification/guidance – Replaced “anti-virus” with “anti-malware” throughout to support a broader range of technologies used to meet the security objectives traditionally met by anti-virus software.
• 5.1.2 – Clarification/guidance – Changed to 5.2.3 and clarified requirement by changing focus to “system components that are not at risk for malware.”
• 5.2 – Clarification/guidance – Split this requirement into three separate ones (5.3.1, 5.3.2, 5.3.4) – Split one requirement into three to focus each requirement on one area:
  • Keeping the malware solution current via automatic updates
  • Performing periodic scans and active or real-time scans (with a new option for continuous behavioral analysis)
  • Generation of audit logs by the malware solution.

Conclusion

From an operational standpoint not much is going to change on the daily routine based on the changes to Requirement 5.  There will be some potential upfront work to upgrade and develop the oversight processes going forward (TSAs), but once those are in place.  Best advice I have for you is to take this one seriously and put the effort in early to build processes that keep the areas of your security program which govern and manage this area in the forefront of management’s minds.  Develop KPIs that show how much the new solutions are capturing before it gets into the environment, etc.  Keep the narrative between security and management, especially finance, focused on a lack of large events is made possible by the efforts of the group on the numerous small events that happen every day.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  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.  Thanks for taking the time to read my thoughts on PCI v4 Requirement 5.  We will continue to work through each of the PCI requirements each week.

Encrypt transmission of cardholder data across open, public networks.  What is an open, public network?  There are technically (no pun intended) many different ways to define an open, public network.  For our purposes, we will just declare that an open network is one that shared connections between internal and external users that are visible to others, outside of the authorized individuals and/or systems.  In other words, if the connection type leaves your environment and does not use a locked down private connection (VPN, etc.), let’s consider it in scope for requirement 4.

Overall Thoughts

So, we can frame the conversation, I feel the need to point something out from the start – we are discussing IT security through the lens of PCI security and what it takes to be compliant with the digital security standards, specifically to point out the deltas between version 3.2.1 and 4.  The reason I say this, is to point out that from an over all security mindset, you should be working to do more than is required for compliance.  Compliance is not a sign of overall security; it is a single measuring point.  Think of compliance against any standards as one of your KPIs and develop additional indicators to achieve a higher level of security within your environment.   Once we are done with the series on changes coming up for PCI v4, I will work on one to highlight some low hanging fruit items to build on your compliant environment and start working towards a more secure stance.

What’s New for Req 4 in v4

Back to the topic at hand.  The changes in the form of new controls in requirement 4 of version 4 are:

• 4.1.2 – Roles and responsibilities for performing activities in Requirement 4 are documented, assigned, and understood.es to the existing controls (surprised?)
• 4.2.1 – Certificates used to safeguard PAN during transmission over open, public networks are confirmed as valid and are not expired or revoked. ß Something that has not been part of the assessment before, so start tracking this data now.
• 4.2.1.1 – An inventory of the entity’s trusted keys and certificates is maintained.  (Certificate inventory – see above where I say “start tracking this data now”)

It would be accurate to say there are not a lot of changes to existing controls, and there are also a lot of changes to existing controls. Generally speaking that is because there is change to the overall focus, which impacts all controls within the requirement, but no changes specifically made to the existing controls.

• 4 – Clarification/guidance – The overall focus of requirement 4 is to confirm “strong cryptography” being used to protect the transmission of cardholder data as the focus of the requirement.

Conclusion

I can already feel some of relaxing because the lack of changes in requirement 4 make it feel as though this one will be easy to manage.  Well, the good news, for those of you that only use P2PE connections, or hosted iFrame solutions, it will be really easy!  Since it is pretty much not applicable to you already and nothing new changes that.  However, as we mentioned earlier when I mentioned the difference between compliant and secure, even if you can claim N/A due to a service provider managing this aspect of security for you, it is a good idea to track this information.  Now, your service provider is probably not going to share the actual certificate details with you but part of the due diligence in requirement 12 calls for you to maintain a program to confirm service providers are working in a PCI compliant manner.  This not only gives you the authority to check their AoC to make sure there were no issues with this part of their assessment, but it is actually better to view this as a requirement on your end to do so.  Don’t let the interconnectivity of the DSS get lost on you through allowing yourself to focus on the single controls without also looking at the bigger picture.

As always, I hope this tidbit of information gives you a base to have discussions with your internal subject matter experts and your trusted external sources for IT security and PCI knowledge.  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. 

Thanks for taking the time to read my thoughts on PCI v4 Requirement 4.  We will continue to work through each of the PCI requirements each week.