Why and how to align vulnerabilities with business risk for PCI-DSS compliance

It is well known that any organization that handles payment card data, must comply with the PCI DSS regulatory framework.  This standard comprises 12 main requirements which cover areas including security policies, technologies, and ongoing processes that protect payment systems from breaches and theft of cardholder data.

An important element of those 12 main requirements is requirement 6.1, which mandates that organizations must establish a process for identifying security vulnerabilities, using reputable sources and up-to-date vulnerability information.  Put simply, this means that organizations must undertake vulnerability scanning – at least on the servers that are in the scope of the PCI regulation (although we’d recommend doing this as security best practice regardless).

The great vulnerability overload 

To achieve compliance with this standard, if you haven’t already, you will need to source an external, reputable, third-party vulnerability scanner solution.  Each scanner deployed will then target a specific server, or list of servers based on a list of IP addresses.  The solution will then scan its assigned servers, producing a report detailing all the vulnerabilities found and rating them by severity.

However, as new vulnerabilities are discovered every day, this ‘laundry list’ of problems is very dynamic, and constantly being updated.  Furthermore, it’s also extremely granular and detailed, as the information is provided on a per-server basis.

This creates another challenge when it comes to ensuring you are PCI compliant: how to assess and prioritize the remediation of vulnerabilities that directly impact your compliance status?  If several servers have ‘critical’ vulnerabilities, how do you choose which one to fix first?  Which of the less serious vulnerabilities can you afford to live with the most? And if you take a server offline to patch it, what will the impact on your business be?

These choices, crucially, are all trade-offs, with costs and risks associated with both fixing a vulnerability as well as risks involved in not fixing it. Moreover, there is also the fact that patching a vulnerability could disrupt services in other areas of the network.

The context, and scope, of PCI

These questions are a matter of balancing operational risk with security risk – and the vulnerability scanner cannot give you both sides of this equation.  It only speaks the language of security risk.  Understanding the operational risk requires knowing exactly what purpose each server is performing and what applications rely on it.

For instance, you will know that a particular server is within the scope of PCI, however, based on the information provided by the vulnerability scanner, you will not know what the implications will be for the business of remediating that risk.  If a server is supporting the main ecommerce application that handles your credit card processing – and if ecommerce is a key revenue stream for your business – then taking that server offline for two hours to patch it could be hugely damaging for your business. It would be far better to wait and conduct the remediation overnight. Conversely, if that server is supporting your backup database server (and your primary database server is operational), then taking that original server offline would be less problematic.

A new approach

AlgoSec helps address these challenges by presenting vulnerability scanner data in the context of the business processes that rely on each server.  The solution provides a vulnerability score for each individual application, not just the server that are within the PCI scope.

In this way, we have taken PCI requirement 6.1 one step further. Instead of receiving a report stating ’10 IP addresses have vulnerabilities on them’, you now know that ‘the specific ecommerce application has a vulnerability score below threshold, however the credit card issuing application has a vulnerability score that is acceptable’.

This has two key benefits.  First, it brings far more visibility and actionable recommendations to the personnel in charge of fixing the vulnerabilities on your network, and second, it brings far more clarity to the auditor reading your PCI compliance report, as they can understand where the risks exist within your network in terms of the wider business context.

Understanding both the security and the operational risk of each vulnerability on your network will enable you to ensure that you are continually meeting PCI-DSS requirements without impacting business agility.

Watch me explain this in detail in my new whiteboard video lesson.