Intro to PCI version 4: Requirement 11

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.