"Most audits that I went through, including PCI, required the organization to define their risk tolerance in a security policy and then the org needed to adhere to it. At my prior job, we had a Vulnerability Management policy and we embedded the Kenna risk scores in it and defined an SLA for certain scores. If we did not do that then we would have to follow whatever the CVSS requirement was by the regulator. Audits actually became much easier with Kenna because using the risk based methodology is better in the long run."
- Katie Conners, Kenna CSE and former Fortune 500 Vulnerability Program Manager
These are the considerations for PCI compliance:
PCI compliance is not a set of hard and fast rules, but recommendations. It is asset-based, not vulnerability-based, and therefore requires determining which assets are in scope and adopting a policy for remediation that will satisfy auditors. The PCI guide uses the CVSS scoring system as one basis for policies. It mentions scores of CVSS 4 and above require fixing because they are considered a "fail", but customers have the choice to create a policy that uses a different scoring methodology. If using the CVSS score, you are going to have to fix a lot more vulnerabilities to be compliant than if using Kenna, and even more if using CVSS 3 (see "CVSS3: When Every Vulnerability Appears To Be High Priority"). Kenna helps you focus in on vulnerabilities that are actually risky and likely to be exploited. Customers can and have implemented remediation policies using Kenna scoring.
From the PCI guide:
“All applications that store, process, or transmit cardholder data are in scope for an entity’s PCI DSS assessment, including applications that have been validated to PA-DSS. The PCI DSS assessment should verify the PA-DSS validated payment application is properly configured and securely implemented per PCI DSS requirements. If the payment application has undergone any customization, a more in-depth review will be required during the PCI DSS assessment, as the application may no longer be representative of the version that was validated to PA-DSS.”
While there is a vulnerability filter in Kenna called "PCI Related", this comes from PCI vulnerabilities in a cardholder data environment and is based on information from the Qualys Knowledge Base. It is based on CVSS of 4 and above and will not be applicable for non-Qualys scanners. This flag is not related to asset scope. Analysis specific to your organization is needed to confirm which assets are in scope and your policy dictates which vulnerabilities must be remediated.
The phrase "PCI Compliance" should be reserved for PCI QSAs. Kenna can provide guidance on how to use Kenna for PCI compliance, but Kenna is not in a position to guarantee compliance as that depends on your organization's actions. Kenna lives in PCI DSS Requirement #6 and there are many requirements that need to be met in order to receive a clean ROC. Customers choosing to use Kenna scoring will need to follow the steps below and document their decision, in order to evidence answers from a QSA around risk methodology, vulnerability scoring and risk tolerance.
- Determine which assets are in scope
- are they sufficiently segregated or do you have a flat network?
- Decide on the risk methodology you will use and create a documented and approved policy
- Will you use Kenna score? What is the lowest Kenna score you will require fixing to be compliant?
- Will you stick with CVSS score? Reporting and Top Fixes in Kenna will not function with this methodology because it is based on the Kenna score, but you can still group the assets in scope for PCI.
- Identify PCI assets in Kenna with tags from your scanning or asset management tool.
- Create a risk meter in Kenna for those assets based on how you identify them
- Require patching based off of your risk score methodology (what is the lowest score you require fixing?)
- Create SLA rules to assist with enforcing the patching policy in line with PCI remediation guidelines.