A client of mine uses PayPal's Payment Pro system which allows them to take card payment on their website, without the user. having to go via the PayPal site.
PayPal still processes the payment, just behind the scenes.
They have been requested by PayPal to become "PCI Compliant" and recommend their "partner" TrustWave to perform a scan to check for compliance.
This scan is quite in depth and checks a lot of features and functions of the hosting server.
It did throw up a few cautions and one warning.
The cautions are easily explained away by informing TrustWave that the system is secured by ASL and their assumptions are based on a stock server.
The warning, however, deals with "Unencrypted Communication Channel Accessibility" and fails with the details:
It then offers remediation as:The service running on this port (most often Telnet, FTP, etc…) appears to make use of a plaintext (unencrypted) communication channel. Payment industry policies (PCI 1.1.5.b, 2.2.2.b, 2.3, & 8.4.a) forbid the use of such insecure services/protocols. Unencrypted communication channels are vulnerable to the disclosure and/or modification of any data transiting through them (including usernames and passwords), and as such the confidentially and integrity of the data in transit cannot be ensured with any level of certainty.
I disputed the warning and was replied with:Transition to using more secure alternatives such as SSH instead of Telnet and SFTP in favor of FTP, or consider wrapping less secure services within more secure technologies by utilizing the benefits offered by VPN, SSL/TLS, or IPSec for example. Also, limit access to management protocols/services to specific IP addresses (usually accomplished via a “whitelist”) whenever possible.
Since it is a server running (S)FTP, I don't see how I can possibly do any more security - other than key authentication, which would be impossible to implement for users.Regrettably, the evidence being supplied here is not quite strong enough for us to process this dispute. Manual investigation shows that a connection via plain text can be established. The plain text functionality is still on. Even though the system has being configured to only allow FTPS-SSL/TLS protocols, credentials are still being sent in plain text. As a result, this system can be compromised. Payment industry policies (PCI 1.1.5.b, 2.2.2.b, 2.3, & 8.4.a) forbid the use of such insecure services/protocols. As such, we have denied this dispute based on the information provided regarding how this finding has been addressed.
Has anyone else had this issue?
Is there anything I can come back to them with as a solid dispute to say "I'm secure"?
Thanks