Category: Shawn

Well, you thought we had come to the conclusion of our PCI v4 journey last week (probably because I said as much), but you were wrong! (or I was and you just went along with it).  We should also discuss changes to the appendixes, which are the “requirements” as the end of the document (just before the compensating control worksheet).  These won’t be applicable to most, but since we are discussing the changes and additions, we should include them.  This will be a pretty short one compared to some of the others (looking at you 12).

Overall Thoughts

Almost all of the items here are only applicable for service providers.  If that is not you, it still may be worth the 2 minutes it takes to read this post to make sure you know what to expect from any service providers engaging with you in these areas.

What’s New in the appendixes for v4

• A1.1.1 – The multi-tenant service provider confirms access to and from customer environment is logically separated to prevent unauthorized access. Deeper dive into the management of the hosted (now called ‘multi-tenant’) environment. 
• A1.1.4 – The multi-tenant service provider confirms effectiveness of logical separation controls used to separate customer environments at least once every six months via penetration testing. Make sure you are including this in your pen testing now.
• A1.2.3 – The multi-tenant service provider implements processes or mechanisms for reporting and addressing suspected or confirmed security incidents and vulnerabilities.
• A3.3.1 – Failures of the following are detected, alerted, and reported in a timely manner:
  • • Automated log review mechanisms
  • Automated code review tools.

None of the existing controls within the appendixes are being adjusted or modified.

Conclusion

So, as I stated at the start of the post, almost every change to appendixes is focused on service provider.  As you can see, it is even more specific to “multi-tenant” (or what we used to call shared hosting) service providers.  The goal here is to make sure that the QSA is doing the proper due diligence when looking into the environment’s client access management, to prevent one customer from being able to access and view information from another.

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 Appendix changes.  Now that we have gone through the incremental changes to the requirements for PCI v4, we will start a series on some of the other changes coming up as we come to the end of the year.

We have come to the end of our PCI version 4 by requirement journey.  I know it has been a thrilling experience, full of ups and downs (mostly filled with bullet points, but whatever.)

Overall Thoughts

Requirement 12 has been the backbone of the PCI program management process.  The majority of the focus is on the management of processes, risk, and third parties.  In v4 this does not change, but there are some changes and updates worth mentioning.

What’s New for Req 12 in v4

The new controls in requirement 12 of v4 are:

• 12.1.2 – So unlike all the other requirement updates, the SSC does not add in a new control for 12.1.2.  Then why do I mention it?  Only as an anchor to reference the lack of it, so you aren’t confused and thinking I forgot it (as if!)
• 12.3.1 – A targeted risk analysis is documented to support each PCI DSS requirement that provides flexibility for how frequently it is performed.  Where TRAs are used, you need to determine the “R” and impact probabilities to use as the determining factor for how often you perform the TSA.  Some areas this might be annually and others it could be quarterly, monthly, or every couple of years.
• 12.3.2 – A targeted risk analysis is performed for each PCI DSS requirement that is met with the customized approach. (ie – if you are going to use the customized approach towards compliance, you need a TRA for EACH control.  Not one per assessment, but one per control).
• 12.3.3 – Cryptographic cipher suites and protocols in use are documented and reviewed. – Basically, you need to create an inventory type record of the different cipher suites and protocols in the environment, along with a review process to ensure that it is stays accurate.
• 12.3.4 – Hardware and software technologies are reviewed. Be MORE proactive with your inventories and manage support contracts/models.
• 12.5.2 – Requirement to document and confirm scope of PCI compliance annually. Prior to your PCI assessment, the company needs to review the cardholder data environment (CDE) to validate the scope is accurate.  This does not replace the scoping efforts required of the QSA but should make the process significantly easier (if done correctly).
• 12.5.2.1 – PCI DSS scope is documented and confirmed at least once every six months and upon significant changes. Additional requirements for service providers.  In a nutshell this is the same as 12.5.2, but the frequency has changed.
• 12.5.3 – The impact of significant organizational changes on PCI DSS scope is documented and reviewed and results are communicated to executive management. Another service provider control, focusing on changes to employee resources.  If administrative staff leave, document what was done to manage the impact to the environment.
• 12.6.2 – The security awareness program is reviewed at least once every 12 months and updated as needed. On top of doing the required training within the company, you must also formally review the training program itself and document the process.  Looking to improve and make corrections that have such a major impact on the security culture of the company.
• 12.6.3.1 – Security awareness training includes awareness of threats that could impact the security of the CDE, to include phishing and related attacks and social engineering. Adding in requirements for employees to be taught about the different entry points they have some form of risk associated to them.
• 12.6.3.2 – Security awareness training includes awareness about acceptable use of end-user technologies. (Same as above, but different topics).
• 12.9.2 – TPSPs support customers’ requests to provide PCI DSS compliance status and information about PCI DSS requirements that are the responsibility of the TPSP. This one is something I am glad about.  It is service provider only and requires for a process to provide the proof of compliance to your clients AND the ever-elusive Responsibility Matrix.  It is very common for me to have clients that can’t get this from their providers and must create one for themselves.  If the service provider doesn’t agree with what is written, this responsibility matrix isn’t worth much.
• 12.10.4.1 – A targeted risk analysis is performed to determine frequency of periodic training for incident response personnel.
• 12.10.5 – The security incident response plan includes alerts from the change- and tamper-detection mechanism for payment pages. The expansion of FIM, or something similar in functionality for payment pages.  Some could make the argument that even if you are using iFrames to outsource this, you should be monitoring the pages with the links to those as well, to prevent someone from changing that page and redirecting to their own iFrame for card capture.
• 12.10.7 – Incident response procedures are in place and initiated upon detection of PAN.

Changes to 12 in v4

Requirement 12 changes/modifications are mostly focused on just providing additional details in what the expectations are going to be (along with the structural changes – of course).

• 12 – Clarification/guidance – Updated principal requirement title to reflect that the focus is on organizational policies and programs that support information security.
• 12.2 – Removed – Evolving Requirement – Removed requirement for a formal organization-wide risk assessment and replaced with specific targeted risk analyses (12.3.1 and 12.3.2).
• 12.4 – Now 12.1.3 – Evolving Requirement – Added formal acknowledgment by personnel of their responsibilities. Executive management will now be required to sign a document confirming they are aware of their responsibilities.
• 12.5 / 12.5.1 – 5 – Now 12.1.4 – Clarification/Guidance – Clarified that responsibilities are formally assigned to a Chief Information Security Officer or other knowledgeable member of executive management. Merged requirements for formally assigning responsibility for information security.
• 12.3 / 12.3.1 – 9 – Now 12.2.1 – Clarification/Guidance – Clarified the intent of the requirement is for acceptable use policies for end-user technologies. Merged and removed requirements to focus on explicit management approval, acceptable uses of technologies, and a list of hardware and software products approved by the company for employee use.
• 12.3.10 – Now 3.4.2 – Evolving Requirement – Removed requirement and added new Requirement 3.4.2 for technical controls to prevent copy and/or relocation of PAN when using remote-access technologies.
• 12.11 / 12.11.1 – Now 12.4.2 / 12.4.2.1 – Structure/format – Moved requirements for reviews to confirm that personnel are performing PCI DSS tasks in accordance with policies and procedures under Requirement 12.4, to align with other requirements for managing PCI DSS compliance activities.
• 2.4 – Now 12.5.1 – Structure/format – Moved under Requirement 12.5 to align with other requirements for documenting and validating PCI DSS scope.
• 12.6 – Now 12.6.1 – Clarification/guidance – Clarified that the intent is that all personnel are aware of the entity’s information security policy and their role in protecting cardholder data.
• 12.6.1 / 12.6.2 – Now 12.6.3 – Structure/format – Merged requirements for security awareness training.
• 12.8 – Removed – Structure/format – Removed “null” requirement (all content pointed to other requirements).
• 12.8.1 – 12.8.5 – Now the same – Clarification/guidance – Replaced “Service Provider” with Third-Party Service Provider (TPSP). Clarified that the use of a PCI DSS compliant TPSP does not make an entity PCI DSS compliant, nor does it remove the entity’s responsibility for its own PCI DSS compliance.  Clarified that where an entity has an agreement with a TPSP for meeting PCI DSS requirements on behalf of the entity, the entity must work with the TPSP to make sure the applicable PCI DSS requirements are met. If the TPSP does not meet those applicable PCI DSS requirements, then those requirements are also “not in place” for the entity. Clarified that the information about PCI DSS requirements managed by the TPSP and the entity should include any that are shared between the TPSP and the entity.
• 12.10 – Removed – Structure/format – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
• 12.10.1 – Now Same – Clarification/guidance – Replaced “system breach” and “compromise” with “suspected or confirmed security incident.”
• 12.10.3 – Now Same – Clarification/guidance – Replaced “alerts” with “suspected or confirmed security incidents.”
• 12.10.4 – Now Same – Clarification/guidance – Replaced “system breach” with “suspected or confirmed security incidents.”
• 12.10.5 / 11.1.2 / 11.5.1 – Now 12.10.5 – Evolving Requirement – Merged requirements and updated the security monitoring systems to be monitored and responded to as part of the incident response plan to include the following:
  • Detection of unauthorized wireless access points (former 11.1.2),
  • Change-detection mechanism for critical files (former 11.5.1),
  • New requirement bullet for use of a change- and tamper-detection mechanism for payment pages (relates to new requirement 11.6.1).
  • (This bullet is a best practice until 31 March 2025.)

Conclusion

If you have been involved in a PCI assessment and had the need to review the actual report on compliance (sorry for you on that), you have probably noticed that the majority of requirement 12 just reads as the name of the QSA doing the assessment.  “Provide the name of the assessor who confirms . . .)” So, it might see like there are a LOT of changes to a requirement that is just demonstrating compliance with someone’s name.  Well, the backend work that has to be done to get that signature has always been somewhat substantial, since 12 is all about the PCI program and management thereof.  When you look over the additions and changes you can see that from the perspective of the goals behind requirement 12 not much has changed.  It is still about focusing on making sure the PCI program within each entity is something that is proactive in its approach and not something designed solely to skirt security and do the least amount possible to get the AoC.

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 12.  We will continue to work through each of the PCI requirements each week.

~ Shawn

In PCI requirement 11 the focus is on vulnerability management.  From all aspects – prevention, awareness, and remediation (and all steps in between). 

Overall Thoughts

While at the top level this sounds a lot like requirement 5, which focuses on anti-malware, requirement 11 is more in line with the concepts of anti-threat vector.  While some malware, especially the types that act as entry points for ransomware seem to fall under the auspice of “targeted attack vectors”, most are not.  Requirement 11 is designed around the concepts of making sure that as a company you do the due diligence needed to protect the environment against the impact of all forms of risk and attack vectors in the environment.

What’s New for Req 11 in v4

The new controls in requirement 11 of v4 are:

• 11.1.2 – Roles and responsibilities for performing activities in Requirement 10 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 10 (which was cut from 9, etc.)
• 11.3.1.1 – Manage all other applicable vulnerabilities (those not ranked as high-risk or critical) – The term ‘manage’ is the key to this one.  Develop a program for how you will manage anything found during your scanning and testing that ranks as medium or lower.  (HINT – Risk rankings and impact statements, as part of a targeted risk analysis, will probably be some great steps.)
• 11.3.1.2 – Internal vulnerability scans are performed via authenticated scanning – For those of you who have been running your internal scans using credentials all along, while everyone snickered at you for making compliance harder than needed – Now is your turn to have the last laugh on the matter! (Well done).
• 11.4.7 – multi-tenant service providers support their customers for external penetration testing – Service provider only, and ‘multi-tenant’ refers to the shared hosting environment used by some.  The rest is self-explanatory.  You MUST provide ways for them to do their external penetration testing (unless you are testing on their behalf as part of your service provider agreement, but that opens a whole new set of logistics).
• 11.5.1.1 – Covert malware communication channels detect, alert and/or prevent, and address via intrusion-detection and/or intrusion-prevention techniques – manage the different methods and com paths used by malware programs to coordinate internally and externally.
• 11.6.1 – A change-and-tamper-detection mechanism is deployed for payment pages – THIS.  Start looking for your vendor or having conversations with your dev team (or both) on this one early enough to properly build/purchase, test, and implement.  If you were happy about what feels like a relaxation in R6 on the OWASP related requirements (re: combined into a single versus several independent ones), this is part of why they feel good about being about to make that change.

What are the changes/modifications?

Requirement 11 changes/modifications are mostly focused on just providing additional details in what the expectations are going to be (along with the structural changes – of course).

• 11 – Clarification/guidance – Minor update to the principal requirement title
• 11.1 – Now 11.2.1 – Clarification/guidance – Clarified the intent of the requirement is to manage both authorized and unauthorized wireless access points. Clarified that this requirement applies even when a policy exists to prohibit the use of wireless technology.
• 11.2.3 – Now 11.3.1.3 / 11.3.2.1 – Structure/format – Separated requirement to perform internal and external vulnerability scans and rescans after any significant changes into a requirement for internal scans (11.3.1.3) and external scans (11.3.2.1).
• 11.3 – Now 11.4.1 – Clarification/guidance – Adding clarification around methodology, retention, addressing exposed risk, and definitions between ‘internal’ and ‘external’
• 11.3.3 – Now 11.4.4 – Clarification/guidance – Clarified that penetration test findings are corrected in accordance with the entity’s assessment of the risk posed by the security issue.
• 11.2 – Now N/A – Structure/format – Removed as previous requirements now covered by other controls
• 11.1.2 – Now 12.10.5 – Structure/format – Moved requirement for incident response procedures if unauthorized wireless access points are detected to align with other incident response items.
• 11.5.1 – Now 12.10.5 – Structure/format – Moved requirement to respond to alerts generated by the change-detection solution to align with other the incident response items.

Conclusion

Most of the changes and additions in requirement 11 are focused on additional clarification and guidance towards management of the vulnerability program overall.  For service providers, making certain they are not preventing customers from being able to manage their piece of the environment, and using proper access and mechanisms to ensure the environment is being monitored and tested in depth.  Some areas have been moved down to 12, which we will discuss next week, but for the most part the areas covered by requirement 11 are unchanged.  There is a shift on the expectations on management of the environment.

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 11.  We will continue to work through each of the PCI requirements each week.

In PCI requirement 9 is on physical security of data assets.   Protecting the physical aspect of data integrity in your environment and after it potentially leaves your environment as well.

Overall Thoughts

On the surface physical security looks the easiest.  Check IDs so that people pretending to be employees don’t walk in and take your stuff!  If only it was that easy, but that isn’t the entirety of what is ‘physical security’ in the data world.  Digital assets can be modified and/or compromised through ‘physical’ interaction with the media used for storage – which is the other part of the data security equation.  Protecting the physical equipment from actual theft is important, but so is protecting the data on equipment/items that are deemed no longer needed for business purposes.  This is the crux of physical security in the modern data era.

What’s New for Req 9 in v4

There isn’t too much new in requirement 9, from the net-new perspective. The new controls in requirement 9 of v4 are:

• 9.1.2 – Roles and responsibilities for performing activities in Requirement 9 are documented, assigned, and understood.es to the existing controls (surprised?) <- literally cut and paste this line from the post on requirement 8 (which was cut from 7, etc.)
• 9.5.1.2.1 – A targeted risk analysis is performed to determine frequency of periodic POI device inspections – The entire concept of the Targeted Risk Analysis is new to PCI.  We will cover the details in a later post.

Changes in 9 v4

Requirement 9 is following the previous requirements we have discussed by focusing on managerial accountability and awareness, but is also moving in a direction to align things in ways to make it easier to manage and make more sense for internal operations.

• 9 – Clarification/guidance – In the overview, clarified the three different areas covered in Requirement 9 (sensitive areas, CDE, and facilities). Throughout, clarified whether each requirement applies to the CDE, sensitive areas, or facilities.
• 9.1 – Now 9.2.4 – Clarification/guidance – Added a requirement to address a former testing procedure bullet to restrict access to consoles in sensitive areas via locking when not in use.
• 9.2 – 9.3.1/9.3.2 – Structure/format – Split requirement for identifying personnel and visitors into separate requirements, Requirements 9.3.1 and 9.3.2 respectively.
• 9.4/9.4.1/9.4.2 – Now 9.3.2 – Structure/format – Combined requirements for authorizing and managing visitor access together in Requirement 9.3.2.
• 9.5/9.5.1 – Now 9.4.1/9.4.1.1/9.4.1.2 – Clarification/guidance – Removed requirement for procedures to physically secure media (9.5) and merged the procedures into the related requirements. Split requirement for storing media backups in a secure location and reviewing the security of the offline backup location at least every 12 months into 2 requirements.
• 9.6/9.6.1/9.6.2/9.6.3 – Now 9.4.2/9.4.3/9.4.4 – Clarification/guidance – Removed requirement for procedures for internal and external distribution of media (9.6) and merged the procedures into the related requirements.
• 9.7/9.7.1 – Now 9.4.5/9.4.5.1 – Clarification/guidance – Removed requirement for procedures for strict control over storage and accessibility of media (9.7) and merged the procedures into the related requirements. Split requirement for maintaining media inventory logs and conducting media inventories annually into 2 requirements.
• 9.8/9.8.1/9.8.2 – Now 9.4.6/9.4.7 – Clarification/guidance – Removed requirement for procedures for media destruction when media is no longer needed (9.8) and merged the procedures into the related requirements. Clarified options for destroying media when no longer needed includes either destruction of electronic media or rendering cardholder data unrecoverable.
• 9.9 – Now 9.5.1 – Clarification/guidance – Clarified the focus of the requirement is on “Point-of-interaction (POI) devices that capture payment card data via direct physical interaction with the payment card form factor.” Clarified that this requirement applies to deployed POI devices used in card-present transactions.

Conclusion

Even though most of the changes in R9 look to be structural, since they are combining controls and moving them around, the council considers them to be ‘clarification’ or additional ‘guidance’.  This is because the movements within the order of the standard are aligning controls to be grouped with others that they feel share a common theme among them.  There are some additional changes within those areas with specifics on the expectations of the physical aspect of payment card security.  I don’t foresee a lot of expensive projects associated with the changes in requirement 9, but that is an assumption made with no knowledge of your environment.  At the risk of sounding like a broken record, it is best to start talking to your trusted experts and any external sources early to determine the workstreams you have ahead of you coming up.

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 9.  We will continue to work through each of the PCI requirements each week.

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.