Monday 15 October 2012

Vulnerability Scanning for PCI DSS compliance - Part 2


How do you know you’re doing it right?

You need to scan all IPs which are allocated to systems which are in scope for assessment.  Scope of assessment is based on systems storing, processing or transmitting cardholder data or being connected to systems handling cardholder data. For your external vulnerability scan, you must use an Approved Scanning Vendor (ASV) and scan all public facing interface addresses of in-scope systems.

If you do not know the full extent of your scope then you need to take a step back and review your network diagrams and data flows to understand the scope of compliance requirements. If your scope has not been reduced based on the issued guidance on network segmentation or removal of cardholder data, the chances are that your entire network is in scope and all systems and interfaces must be scanned.

'Doing it right' for PCI means having a passing vulnerability scan for all in-scope systems per quarter.
This means you have achieved a 'pass' according to the risk ranking used for internal vulnerabilities, based on CVSS scoring. For external scans, it means the ASV has not identified any 'PCI Fail' vulnerabilities on your external interfaces and websites.

Depending on your risk appetite and management of security, 'doing it right' may mean something quite different. Performing more regular scans and remediation exercises on systems in-scope and out-of-scope should mean the following:

  •          You will identify vulnerabilities across all environments
  •          You will identify vulnerabilities earlier
  •          You will not face a backlog of vulnerabilities to remediate prior to the end of the quarter

All of the above can help to reduce the overall security risk to the business for cardholder and non-cardholder systems.

Scan profiles
A practical approach to achieving passing scans for PCI while maintaining a vulnerability scanning strategy for your entire organisation is to use scanning profiles. You could use a single profile for in-scope environments and alternate profiles for other environments, perhaps based on criticality to the business. For PCI scans, a passing scan result can be submitted for compliance quarterly, reporting requirements are based on the categorisation of the business. For other scans, reducing risk using an internally agreed risk ranking system, documenting a baseline and reducing the risk of that baseline over time may be a sensible objective.
Using schedules, you might alter scan frequency for various environments depending on identified risk factors.

False positives
The following is extracted from the PCI SSC issued ASV program guide…
The scan customer may dispute the findings in the ASV scanning report including, but not limited to:
  •          Vulnerabilities that are incorrectly found (false positives)
  •          Vulnerabilities that have a disputed CVSS Base score
  •          Vulnerabilities for which a compensating control is in place
  •          Exceptions in the report
  •          Conclusions of the scan report
  •          List of components designated as segmented from PCI-scope by scan customer

A false positive means that a vulnerability has been identified in a system which could not or does not exist on that system. For example, an IIS vulnerability identified on an Apache server or an openSSH vulnerability identified where you can evidence the vulnerability is not present on the version in use. When you have identified and proven a false positive, inform your ASV (or flag as a false positive in your scanning tool). The false positive flag should not identify this vulnerability for 1 year. At that point, you'll need to flag it as a false positive again (if it is still identified as such).

Compensating controls
A compensating control for a vulnerability scan is the same as any other compensating control. There must be a valid business or technical justification as to why you cannot meet the requirement and the compensating control in place must at least satisfy the intent and vigour of the original requirement. You must also have a methodology for validating and maintaining the compensating control.  It is the responsibility of your QSA to approve any compensating controls in use as part of the assessment process.

3 comments:

  1. Hi Andrew,

    Your posts are very informative.

    I want to ask you, for some reason if I am unable to patch one of my server because it relies on specific version of OS. So if I upgrade it will cost me time, money and I will have to upgrade rest of the components associated with that server. That will require some serious amount of time and effort in testing and then deploying in production. So is there a way, to report such vulnerabilities as false positive or what sort of compensating control can be leveraged to mitigate this issue.

    Thank you

    ReplyDelete
  2. Hi,
    Great post! This post clearly confirms the fact that it is important you know how to implement the right strategy of link building.
    Attestations Certificates

    ReplyDelete
  3. This content is written very well.Your use of formatting when making your points makes your observations very clear and easy to understand.Thank you. GDPR toolkit

    ReplyDelete