PCI Requirement 6.5.6 – All “High Risk” Vulnerabilities

PCI Requirement 6.5.6 – All “High Risk” Vulnerabilities

What are “High Risk” Vulnerabilities?

PCI Requirement 6.1 taught us how to establish a process for identifying security vulnerabilities. The PCI DSS explained that risk ranking allows organizations to identify, prioritize, and address the highest risk items and reduce the likelihood that vulnerabilities will be exploited. Risk ranking is a vital element of PCI Requirement 6.5.6, which states that organizations must have a process in place to determine how to protect applications from “high risk” vulnerabilities. Risk ranking is malleable because what’s vulnerable today could not be a vulnerability tomorrow, but it’s still crucial to have a process in place to determine how to protect applications from “high risk” vulnerabilities.

PCI Requirement 6.5.6 is sort of the catch-all requirement for “high risk” vulnerabilities. It simply states that you must identify and address these vulnerabilities during application development, but doesn’t give a ton of guidance or restrictions on how you do this. To verify your compliance with PCI Requirement 6.5.6, an assessor will examine your policies and procedures related to application development and interview responsible personnel to see that you have indeed addressed “high risk” vulnerabilities in your coding techniques.

Video Transcript

PCI Requirement 6.5.6 states that you have to have a process in place to identify all “high risk” vulnerabilities. If you remember back in PCI Requirement 6.1, it asks that you have a program where you’re subscribing to third parties to identify vulnerabilities. If part of your application or something within your application is deemed to be “high risk”, that application needs to be addressed. PCI Requirement 6.5.6 is kind of the catch-all. It basically says all “high risk” vulnerabilities need to be addressed. You need to have a process in place to address any “high risk” vulnerabilities. Understand that what’s vulnerable today may not necessarily be a vulnerability later on, but you need to have a process or program in place to fix that.

0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply

Your email address will not be published. Required fields are marked *