In my first TechRepublic post about the Payment Card Industry Data Security Standard (PCI DSS), I described the steps our company took to gain initial compliance by passing external scans and completing a self-assessment questionnaire. In my second post about PCI DSS, I wrote about successfully tackling the causes of external vulnerability scan failures. As I suggested back then, changes to your systems and the scanning algorithms, coupled with the ever-evolving threat landscape, mean that passing the scans can never be taken for granted.

And so it’s proved for us over the last few months. We managed to fix two scan failures but have no less than three outstanding issues. I was waiting for them all to be resolved before writing this but figured I could be waiting a while that way. Besides, the reality in IT is that we don’t get everything nailed overnight.

Fixed: Weak hash function for an SSL certificate

My clue to this one was the non-standard port number on which the scan failed: 4433. This was the number we chose when experimenting with the SSL VPN on our SonicWALL router (because we use the standard 443 for other purposes). The certificate in question was probably a built-in self-signed one provided with the device, but there was no need to investigate in depth. Since we haven’t deployed SSL VPN on the SonicWALL, the fix was simple — just turn off the SSL VPN service.

Fixed: SSL/TLS protocol initialization vector implementation information disclosure vulnerability

This time I knew the problem lay on our Exchange server because the reference was to port 443, which we route there for use with Outlook Web Access (OWA). The full description of the problem looked frightening, and I still didn’t understand it after reading it several times. Resorting to good old Google, I pulled out what I thought would be key phrases to use as search terms. These included references to:

  • SSLv3/TLSv1
  • The “BEAST” attack
  • Security update MS12-006
  • Block ciphers
  • PCI DSS

I soon found relevant discussions and articles. One possible fix was to only allow TLSv1.1. This Stack Exchange article warned that “both endpoints have to support TLS 1.1 before you can establish a TLS 1.1 connection,” so I was afraid that just disabling TLS 1.0 on the Exchange server could stop some browsers connecting to OWA.

The description of the failure referred to a registry fix known as the “record-splitting workaround.” I then found a Microsoft article warning of problems with the fix. Oh good.

I decided to head down the road of disabling TLS 1.0 and seeing if anything broke as a result. As I went looking for details on which registry keys to change, I came across a couple of recommendations for a tool called IIS Crypto. As you can see in Figure A, IIS Crypto has a specific PCI button for applying a predefined template of settings.
Figure A

IIS Crypto tool

Although other people seemed to have a good experience with IIS Crypto, I still took a cautious approach. I took screenshots of IIS Crypto before making any changes and after clicking the PCI button but before applying the changes. I also backed up the HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\schannel registry key, as that is where IIS Crypto would make significant changes.

After applying the changes, IIS Crypto warned that a reboot was necessary. A reboot wasn’t convenient at the time, so I left for the day and checked from home that I could still access OWA from IE9 and Safari. I’d also kicked off a PCI rescan, which passed.

Failed: FTP issues with FileZilla Server

Here’s where the story goes downhill a little. The scan reported several FTP-related failures on a Windows 2003 server running FileZilla Server. Looking at the available settings in FileZilla Server, it seemed that FTP over SSL/TLS (or FTPS) would be the way to go. Although FileZilla can generate an SSL certificate, this would almost certainly fail the scan as well, so we needed to install our newly bought wildcard SSL certificate.

Importing the certificate into FileZilla wasn’t easy (from my point of view), but we got there. I won’t go into detail because, in the end, it didn’t help.

After importing the certificate and upgrading to the latest version of FileZilla Server, we passed the scan! Unfortunately we then discovered that our customers couldn’t access the FTP site anymore. Realising this had turned out to be one of those “safe but useless” fixes, I dug a little deeper into trying to understand secure FTP. This is what I found:

This StackExchange post makes clear that (a) sFTP is different to FTPS (b) FTPS is “difficult to do with firewalls” and (in some opinions) not very good anyway. FTPS is what FileZilla Server offers. Furthermore, this StackExchange post agrees that sFTP is the way to go compared to FTPS, but it doesn’t seem possible to set up with FileZilla server.

Our strategy with this one is to wait because fortunately this FTP server is due to be retired in the not-too-distant future.

Failed: SSL VPN appliance and IPSec VPN

Back in 2009 the manufacturer of our SSL VPN appliance (Billion) made firmware changes to get the system to pass PCI scans. In 2012 the appliance failed again with four new issues related to the security of SSL and TLS. After several weeks of correspondence, Billion concluded that the hardware couldn’t support the necessary changes to fix these issues. To get compliant again, I have to replace the Billion appliance. One job added to the to-do list.

A while back, we started using the IPSec VPN function on our SonicWALL NSA 240 to provide an alternative method in case of problems with the SSL VPN. Ironically, this too has now fallen victim to a PCI scan failure, owing to its use of a pre-shared key (PSK) with Aggressive Mode. It seems my only options to fix this are to switch to Main Mode (which requires the VPN to be site-to-site) or to use certificates instead of PSK. Job #2 for the to-do list.

Summary

External vulnerability scans are a good risk management practice for any organisation, whether or not they are required for PCI DSS compliance. The steps needed to pass the scans, however, aren’t always straightforward, and the activity must be regarded as ongoing rather than a one-off exercise.