4

We are PCI compliant as a service provider, however our service port forwards some web traffic at TCP level.

Customers use our PCI compliant service and can choose to upload a TLS/SSL certificate to us if they want their HTTPS traffic analysed. So the flows on our server would be as follows.

Without TLS/SSL Cert Uploaded by Customer

HTTP Port 80 --> Our service analyses the HTTP header data --> 
  Customer system port 80 as new HTTP request


HTTPS Port 443 --> Our service simply retransmits the TCP packets --> 
  Customer system port 443

With TLS/SSL Cert Uploaded by Customer

HTTP Port 80 --> Our service analyses the HTTP header data -->
  Customer system port 80 as new HTTP request


HTTPS Port 443 --> Our service decrypts and analyses the HTTP header data -->
  Re-encrypted using SSL/TLS to Customer system port 443 as new HTTP request

Note that there is no multitenancy and each customer will have their own set of servers with us for header analysis.

Now there's a problem in the second scenario (without cert and without HTTPS decryption) that we are failing our ASV scans because the scanning traffic hits our customer system and reports on things such as old versions of SSL used, or insecure cipher suites. As you can see, we are simply forwarding traffic at TCP level so any vulnerabilities such as these that are reported are really problems on the customer end-point rather than our system as a service provider. Port 443, and 443 alone is acting as a reverse proxy at TCP level so the scanning traffic is hitting a server that is outside of our PCI scope.

HackerGuardian will not accept these vulnerabilities as false positives because they are failing the ASV scan and are not really false positives - they are vulnerabilities reported from our in-scope system, however it is analysing traffic that is out of scope for us, but in scope for a customer.

How can we achieve a passing scan without forcing customers to fix issues that aren't really any of our concern? Could there be any leeway from an ASV or would we have to implement a compensating control to cover vulnerabilities uncovered when our system is scanned.

5

You don't so much achieve a passing scan, as work with your QSA to agree the scope of the scan, and ensure this traffic is out of scope.

This will require you have a QSA who can understand this - and a lot does depend on their opinion, but that would be the approach I would take.

If you don't currently use a QSA, ensure you have fully documented the scope and the reasons for excluding certain traffic from scope - this one does seem relatively straightforward.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.