Posted on by TBF_Shawn

Intro to PCI version 4 Requirement 6

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.