PCI DSS 3.2 and Vulnerability Intelligence. Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information… It’s one of the requirements of PCI DSS v3.2 (The Payment Card Industry Data Security Standard). It’s not about regular scans, as you could think. It is actually about monitoring web-sites and mailing lists where information about vulnerabilities is published. It’s very similar to what Vulnerability Intelligence systems have to do, isn’t it? A great opportunity for me to speculate about this class of products and deal with related PCI requirement. In this post I will mention following solutions: Flexera VIM, Rapid7 Nexpose NOW, Vulners.com and Qualys ThreatPROTECT.

Term “Vulnerability Intelligence” is almost exclusively used by only one security company – Secunia, or how it is called now Flexera Software. But I like this term more than “Threat Intelligence”, a term that many VM vendor use, but historically it is more about traffic and network attacks. Let’s see how Vulnerability Intelligence solutions was developed, and how they can be used (including requirements of PCI Compliance).

From the VM vendor’s perspective we have the following situation: vendor has a good vulnerability database, almost every vulnerability check was added manually, carefully tested, etc. So, thinks vendor, why not to make additional product that will give to end-users only one feature – an ability to search in the vulnerability base? Thus, vulnerability database without scanning engine becomes Vulnerability Intelligence product.

Flexera VIM – well-known Vulnerability Intelligence product. Motto from youtube video: “Knowing what software products contain identified risks and what those specific risks are”.

But what about the end-users? Do they really need a product of this kind?

Maybe not. In a perfect world of Vulnerability Management vendors, where all systems of are scanned regularly, scanner detects all vulnerabilities, and vulnerability reports are used in patch management.

In a real life you will need to answer the question whether your  systems are have this vulnerability everybody are talking about. This may even drive whole vulnerability scanning and patching processes. Why some vulnerabilities cause a hype, and others not? This is such a complex issue related to PR and information security journalism. But it is not so often depends on the criticality of vulnerability.

And, if you need to start from potential vulnerabilities, and not from regular scans, it would be nice to have some meaningful and formalized process. Vulnerability Intelligence solutions, which allow you to track new vulnerabilities and assess their criticality, can really help.

Now let’s look at the PCI DSS. Best practices are great but it is always better when they correlates with the requirements of mandatory standards.

Vulnerability Intelligence related requirements are located at “Requirement 6: Develop and maintain secure systems and applications”. The authors did not use the term Vulnerability Intelligence. It sounds like this:

6.1 Establish a process to identify security vulnerabilities, using reputable outside sources for security vulnerability information, and assign a risk ranking (for example, as “high,” “medium,” or “low”) to newly discovered security vulnerabilities.

This “identify security vulnerabilities” could be attributed to vulnerability scan, but the Guidance says:

This is not achieved by an ASV scan or internal vulnerability scan, rather this requires a process to actively monitor industry sources for vulnerability information.

This requirement describes exactly how vulnerability risk should be ranked:

Note: Risk rankings should be based on industry best practices as well as consideration of potential impact.

Risk level should depend on external assessments of vulnerability and on specific conditions in the organization.

For example, criteria for ranking vulnerabilities may include consideration of

• the CVSS base score,
• and/or the classification by the vendor,
• and/or type of systems affected.

Methods for evaluating vulnerabilities and assigning risk ratings will vary based on

• an organization’s environment and
• risk- assessment strategy.

It’s good to use CVSS or vendor’s classification (severity of security bulletin). In any case, the method of ranking must be fixed and clear: “The organization must therefore have a method in place to evaluate vulnerabilities on an ongoing basis and assign risk rankings to those vulnerabilities.”

Risk rankings should, at a minimum, identify all vulnerabilities considered to be a “high risk” to the environment.
In addition to the risk ranking, vulnerabilities may be considered “critical” if they

• pose an imminent threat to the environment,
• impact critical systems,
• and/or would result in a potential compromise if not addressed.

Examples of critical systems may include

• security systems,
• public-facing devices and systems,
• databases, and
• other systems that store, process, or transmit cardholder data.

Risk assessment is important for remediation: “Classifying the risks (for example, 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.”

As you can see, there is always a reference to the environment and criticality of vulnerable systems. See notes: “The intent of this requirement is that organizations keep up to date with new vulnerabilities that may impact their environment. […] Once an organization identifies a vulnerability that could affect their environment, the risk that the vulnerability poses must be evaluated and ranked“.

How to get information about environment? Well, information about assets may be added manually or imported it from some other monitoring system. For example, in Flexera VIM information about installed softs or added manually, imported through the csv, or through synchronization with Microsoft SCIM. Another obvious answer: by scanning. in this part, traditional Vulnerability Management (scanning) vendors has has a natural advantage.

This year Vulnerability/Threat Intelligence topic was very popular among Vulnerability Management vendors. Qualys introduced ThreatProtect, which allows end-user to search for vulnerabilities and related information in context of the asset list. The same asset representation is used for vulnerability scanning in Qualys Cloud Suite.

Introducing Qualys ThreatPROTECT from Qualys, Inc. on Vimeo.

Rapid7 recently introduced a new version of the Vulnerability Scanner (or perhaps a new product?) – Nexpose Now. They are focusing on Remediation – “deliver prioritized tasks and context directly to IT” and Threat (~Vulnerability) Intelligence – pretty dashboards updated in real time. Information is collected through Adaptive Security or Rapid7 Agents. Here you can see demo: “See Nexpose Now In Action”.

Nexpose Now is a scanner, but, as you can see, in a live demo it solves classical Vulnerability Intelligence task: analyst finds an interesting critical vulnerability in a feed, scans potentially vulnerable asset, and then creates a remediation task.

What Testing Procedures offers PCI DSS 3.2.

6.1.a Examine policies and procedures to verify that processes are defined for the following:

• To identify new security vulnerabilities
• To assign a risk ranking to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.
• To use reputable outside sources for security vulnerability information.

6.1.b Interview responsible personnel and observe processes to verify that:

• New security vulnerabilities are identified.
• A risk ranking is assigned to vulnerabilities that includes identification of all “high risk” and “critical” vulnerabilities.
• Processes to identify new security vulnerabilities include using reputable outside sources for security vulnerability information.

As you can see, testing is pretty formal: check the documents, talk with people, check that a process of searching and ranking of new vulnerabilities exists, and all information sources are reputable. All such operations in such process can be done manually. But is it an option for large organizations?

PCI DSS standard does not define the list of sources. Standard gives some examples in Notes: “Sources for vulnerability information should be trustworthy and often include vendor websites, industry news groups, mailing list, or RSS feeds.” And it’s seems to be impossible for a large organization to collect and manage all this data manually.

Can Vulnerability Intelligence database help to solve this problem? Technically, yes. But it is necessary to understand that if this database was made by Vulnerability Management vendor, it is likely repeats it’s detection plugin database. If vulnerability can not be detected automatically, it won’t be probably there. And what can be detected automatically will appear in such database with a delay (time required to write a plugin). Detection plugins make possible to quickly confirm the presence of vulnerabilities in the system, but probably some vulnerabilities in such highly formalized database will be absent.

Solutions that do not limit themselves only to highly formalized data, usually contain more information about the vulnerabilities. Vulners.com is a good example of such solution (see my post Have you heard about vulners.com?).

Vulners shows all information related to the vulnerability, such as exploits, detection plugins, topics on hacking forums, etc.

Routine tasks can be automated with Vulners REST API, it is also possible to subscribe to custom vulnerability feeds via RSS or instant Telegram bot. The entire list of Vulners data sources is open and presented on a page Stats. Many other Vulnerability Management vendors are just say “we know vulnerabilities for all systems”, which is of course not true.

Why Vulnerability Intelligence product segment is growing rapidly? I think the main reason is that analyzing the lists of vulnerabilities becomes ineffective. What is really matters is not the vulnerability itself, but how it can be used by attacker. Also there are some problems with vulnerability scanning. Scanning takes lot’s of time and does not cover everything. That’s why I think we will see an exciting development of the systems that will make effective exploitation forecasts based mainly on vulnerability feeds (and related exploits, malware, etc.) and asset data.