Thursday 4 October 2012

Vulnerability Scanning for PCI DSS Compliance


Maintaining compliance with PCI DSS requirements for vulnerability scanning can present a number of challenges for companies.  This blog post is aimed at tackling the challenges of vulnerability scanning and present ideas for managing the process, as well as evidencing it to your QSA.

The best starting point is to define the process for vulnerability scanning.  PCI DSS requires the following:
  • Scans are performed at least quarterly
  • Scans must be performed by a qualified resource for internal scans (not required to be an ASV) and by an Approved Scanning Vendor (ASV) for external scans
  • External vulnerability scans must satisfy the ASV program requirements
  • Scans must be performed after significant change in the environment
  • Scans must achieve a passing score (as defined in ASV requirements for external scans, and by having no vulnerabilities ranked as ‘high’ for internal scans)

These guidelines provide the control requirements for the vulnerability scanning process within an organisation. Establishing a process to satisfy those requirements can be difficult, because of size, complexity or architectures that have been implemented.

When it comes to vulnerability scanning, it is much like any other job you would rather ignore; the longer you leave it the more time, effort and interruption it causes when you want or need to be doing something else.  Scanning more regularly, such as monthly, is often touted by QSAs as being a good way to manage the process (and it is) but it will not deliver the added benefits unless configurations and security patching are managed correctly. 

In order to perform a scan, you need to have identified what systems are in scope for your internal and external scans and to have created the appropriate profiles in the scanning configuration. Implementing network segmentation can reduce the number of systems which need to be scanned.  For the ASV scan, your ASV provider, under the PCI SSC ASV Program Guidelines requires the following:
  • Information about any scoping discrepancies must be indicated on the Attestation of Scan Compliance cover sheet under heading "Number of components found by ASV but not scanned because scan customer confirmed components were out of scope ". This information should NOT be factored into the compliance status:
  • Include any IP address or domain that was previously provided to the ASV that has been removed at the request of the customer
  • For each domain provided, look up the IP address of the domain to determine if it was already provided by the customer
  • For each domain provided, perform a DNS forward lookup of common host-names – like ―www,‖ ―mail,‖ etc. – that were not provided by the customer
  • Identify any IPs found during MX record DNS lookup
  • Identify any IPs outside of scope reached via web redirects from in scope web-servers (includes all forms of redirect including: JavaScript, Meta redirect and HTTP codes 30x)
  • Match domains found during crawling to user supplied domains to find undocumented domains belonging to the customer

I mention this because I can only name a few ASVs that I have worked with through my clients who have demonstrated the processes identified above.  Just to note the requirements of the vulnerability scanning processes require the organisation or scan customer to acknowledge its responsibility to manage scope, and obligation to properly inform the ASV provider about your environment, including any local or external load balancers that may impact the scanning process.

For internal vulnerability scanning the chosen solution should be managed by someone who is able to demonstrate sufficient knowledge to perform the process.  In order to achieve this, the scope of scanning should be approved within the governance framework of the organisation, and implemented within the chosen solution.  The reports should always be passed back to the team responsible for the process.
There are a number of tools available, from managed and hosted solutions to customer implementations and free open source tools.  I have been to clients with 100+ servers in scope for PCI DSS assessment and have observed they are using scanning tools which do not facilitate ease of issues review or remediation management. If you want to scan large environments, investing in a tool which provides the business useable reports is a must as, in the early days of this process, remediation will likely be rather time consuming.  All of the findings within the reports should be considered for action, even if they are informational issues.  

When assets are identified for scanning they should be assigned an owner; this is the person who investigates the remediation plan for the identified issue and documents the relevant change control documentation to ensure the fixes are implemented.  This is where functionality of the tools selected to assist the business in maintaining compliance has to be considered. I am always amazed at how limited the functionality is of some solutions, such as only providing a PDF report, or CSV format download. It just makes the job harder!  A solution that can mirror the internal governance structure of an organisation can save time, meetings and other resources by just adding some work flow. 

Managing the identified issues from a scan is important, especially when a failure is noted.  Failures, as mentioned above, are in the instance of external scans anything with a CVSS baseline score over 4.0 and for internal scans any issues identified as ‘high’.  The ASV program guide suggests organisations attempt to address issues based on the CVSS scoring.  Any issues that have a failure implication need to have the following:
  • Root cause analysis (newly identified issue, security misconfiguration etc
  • Action plan for remediation
  • Communication and assessment of compensating controls (for external scans this is completed with   the ASV)
  • Change Management documentation

It is not just the changing security landscape that needs to be managed for vulnerabilities.  Changes made to the environment, such as addition of new servers, or new applications should always result in security testing being completed.  Prior to any other security testing, a full vulnerability scan on internal and external changes should be completed.  This should be the case even if you are going to complete penetration testing, as this will ensure that the tester’s time is spent on harder tasks rather than on the ‘low hanging fruit’.

Where an organisation has established and embedded change management procedures and governance structures such as a Change Advisory Board, these should be closely aligned and involved in the vulnerability scanning process. The ability to manage changes in the environment securely and in line with company processes will provide key documented evidence to the QSA that robust processes are in operation.

Part two of this post will cover the following item in more detail than they have been touched on in this post:

  • How do you know you’re doing it right?
  • Scan profiles
  • False positives
  • Compensating controls



1 comment:

  1. Hi,
    Nice thought with this blog I enjoy studying and I conceive this website got some truly utilitarian stuff on it!
    Attestation Of Compliance

    ReplyDelete