Tag Archives: compliance

PCI Vulnerability Scans – Part I : Severity Levels (Risk Rankings)

PCI requires you to have both external and internal vulnerability scans. We will discuss them in detail later. Today I will focus on the risk rankings that PCI uses for vulnerabilities.

PCI DSS requirement 6.2: Establish a process to identify and assign a risk ranking to newly discovered security vulnerabilities.

Notes:

Risk rankings should be based on industry best practices. For example, criteria for ranking “High” risk vulnerabilities may include a CVSS base score of 4.0 or above, and/or a vendor-supplied patch classified by the vendor as “critical,” and/or a vulnerability affecting a critical system component.

The ranking of vulnerabilities as defined in 6.2.a is considered a best practice until June 30, 2012, after which it becomes a requirement.

6.2.a Interview responsible personnel to verify that processes are implemented to identify new security vulnerabilities, and that a risk ranking is assigned to such vulnerabilities. (At minimum, the most critical, highest risk vulnerabilities should be ranked as “High.”

6.2.b Verify that processes to identify new security vulnerabilities include using outside sources for security vulnerability information.

Himm, as you see with PCI version 2 there is a change in the vulnerability severity categorization. Now PCI asks us to use CVSS and telling that CVSS will be a standardized severity level for PCI vulnerability scans after June 30, 2011.

The table above should give you a very clear idea of which severity category that a vulnerability will be assigned.  For example a vulnerability that has CVSS score of 5 will be a medium level vulnerability that should be fixed to pass PCI compliance.

In order to pass PCI compliance all the vulnerabilities should have 3.9 or less CVSS. There are four exceptions for this rule:

1. The vulnerability is not included in the NVD (National Vulnerability Database): If it is a new vulnerability you have a chance that you don’t have the vulnerability in the NVD.

You can still use CVSS system to calculate the risk ranking score. PCI also asks you to reference to other external resources of information about the vulnerability.

2. You disagree with the CVSS score noted in the NVD: Sometimes the CVSS score may not make sense for your organization for a specific vulnerability. In this case PCI asks you to provide followings:  Score in the NVD, your score, and why you are disagree with the score provided in the NVD.

3. It is a denial of service (DoS) vulnerability:  If it is a purely DoS type of vulnerability you have found, you can ignore it regardless of CVSS score since it is not in the scope of PCI compliance.

4. It is one of the “automatic failure” type of vulnerability: Like DoS vulnerability, you will not care CVSS score (this time it is other way around, the CVSS score is lower than 4.0 but due to the nature of the vulnerability system cannot be PCI compliant)

Here are the all automatic failures:

  • Operating system has no longer supported by the vendor
  • There is an open access to database from internet
  • Built in accounts (OS, DB, Web, Application, Network, etc…)
  • Unrestricted DNS zone transfer
  • SQL injection, XSS, director traversal, HTTP response splitting/header injection
  • The presence of well-known, remotely detectable backdoor applications installed on the servers.
  • If server supports SSL 2.0 or older, or SSL 3.0 with 128-bit encryption

In my next PCI post, I go over wireless requirements and how to detect rogue APs.