PCI Requirement 6.1 – Establish a Process to Identify Security Vulnerabilities

by Randy Bartels / October 13th, 2017

What is PCI Requirement 6.1?

PCI Requirement 6.1 states, “Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking to newly discovered security vulnerabilities.” The purpose of PCI Requirement 6.1 is to ensure that your organization is up to date with new security vulnerabilities that could impact your environment. Assessors will look to see that you have a formal, established process in place to identify security vulnerabilities. When considering how to establish a process to identify security vulnerabilities, we recommend taking it in three steps: notification of security vulnerabilities, risk ranking security vulnerabilities and security patches, and then implement security patches.

1. Notification of Security Vulnerabilities

We recommend that you subscribe to a third party for notifications of security vulnerabilities. The PCI DSS states, “Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing lists, or RSS feeds.” When using something like Microsoft, Oracle, or Linux, it’s important to note that they do not publicly disclose security vulnerabilities within their application until there’s a security patch. If you use something like Secunia, you could be notified of new security vulnerabilities earlier and have an opportunity to fix them, instead of leaving your system vulnerable.

2. Risk Ranking Security Vulnerabilities and Security Patches

Once you’ve identified a security vulnerability or a manufacturer’s patch, you need to rank that risk. The PCI DSS explains, “Classifying the risks as ‘high,’ ‘medium,’ or ‘low’ allows organizations to identify, prioritize, and address the highest risk items more quickly and reduce the likelihood that vulnerabilities posing the greatest risk will be exploited.” We recommend the Common Vulnerability Scoring System (CVSS). Vulnerabilities and patches, once identified, are given a score between 1 and 10, 1 being “informational” and 10 being “needs to be addressed immediately”. Most of the vulnerabilities in today’s world are published with a CVSS score. Risk ranking is incredibly important because it gives your organization the chance to consider how a security vulnerability or security patch would affect your environment. If the manufacturer says it’s a critical or urgent security vulnerability, it’s absolutely appropriate to accept that and immediately patch for those things. However, there might be situations where a manufacturer considers a vulnerability or patch low risk, but once you’ve ranked that risk within your unique environment, you might realize it’s actually urgent or high. Risk ranking security vulnerabilities and patches can help your organization from believing common misconceptions, like:

• Just because there is an available security patch doesn’t mean that I have to install it immediately.
• If a vendor says an update is medium risk, then it’s not critical to my environment.
• If Microsoft, Oracle, or Linux doesn’t report a security vulnerability, my organization is immune from attack.
• Keeping my system patched will keep it free from all vulnerabilities.

3. Implement Security Patches

The PCI DSS requires that when you have identified a critical or urgent security patch, it needs to be implemented within 30 days. An assessor will need to examine your vulnerability program, your policies and procedures, the sources that notify you of security patches, the security patches on your system and applications, then compare all of that to your current patch level to discover if any additional patches need to be installed.

For more information on security vulnerabilities and security patching, check out our Hardening and System Patches webinar.

Starting off in Requirement 6, we have 6.1. 6.1 says that you have a program or process in place where you look to identify vulnerabilities within your applications. There’s several testing requirements around this, but effectively what we’re looking for is that you have third parties that you subscribe to help notify you of when there’s an issue. One of the things that I would generally recommend is, of course, using the Microsoft, the Linux, the Oracle, and other branded sites, but also try to find third parties that do this as a profession, like Secunia, for instance. The reason why I recommend that is because Microsoft will not publicly disclose that there’s a vulnerability within their application until they release the patch. There might be situations where your applications are left vulnerable for a period of time, but you might have had the opportunity to fix that, had you subscribed to these other third parties.

Once you’ve identified that there’s vulnerability, secondary to that is the manufacturers release a patch. You need to take that patch and vulnerability and you need to perform risk ranking within your environment. Most of the vulnerabilities in today’s world are published with a CVSS score. As part of that, the CVSS score (Common Vulnerability Scoring System) is really a starting point. You can accept that. If the manufacturer says it’s critical or urgent, it’s absolutely appropriate to accept that and go ahead and patch for those things. However, there might already be situations where an organization delivers a patch and they might say it’s low. When you risk rank that vulnerability within your environment, you might come to realize that’s urgent or high vulnerability and that patch might need to be deployed soon than later.

The PCI DSS requires that when we have a critical or urgent patch identified, that patch needs to be deployed within 30 days. From an assessment perspective, what the assessor is going to do is we’re going to look at your vulnerability program, look at your procedures, look at the fact that you are subscribing to third parties or outside sources for that information. We’re then going to pull a list of all of the patches for your applications, servers, really everything in your environment and compare that to patches that need to be installed or the patch level of your current infrastructure. What we’re looking for is that anything that highly critical or urgent has been deployed within 30 days.