PCI DSS compliance for a small business--part 2

Mark Pimperton tackles stubborn weak ciphers and mysterious port scan failures to pass external vulnerability scans and maintain compliance.

In my first post on PCI DSS compliance I described the steps we took to gain initial compliance by passing external scans and completing a self-assessment questionnaire. Since the questionnaire has to be recertified annually, I have to spend time on PCI DSS at least once a year. But in the last few months I also had three quarterly scan failures to deal with. This can happen when your internal systems change, as you might expect, but it seems the scanning algorithms also change over time and will pick up vulnerabilities they just didn't see before.

SSL 2.0 and weak cipher failure on IIS

For our initial compliance we'd had to make changes to IIS7 on a Win2k8 server, ensuring that SSL 2.0 was disabled and that weak ciphers weren't allowed. We later opened up an IIS6 Web site on one of our Win2k3 servers to the Internet, so inevitably the next PCI DSS scan failed with the same problems.

I confidently went back to the articles I'd used before: this one about disabling SSL 2.0 and this one about disabling weak ciphers. (I also found an IIS6-specific article which looked even better.) After adding or altering the relevant registry entries I reran the scan but it still failed, claiming that "DES-CBC-SHA:TLSv1/SSLv3:56-bit" was still enabled. Even more confusing was the fact that ServerSniff suggested that all was well.

More research suggested that sometimes it just takes several attempts to get these registry changes to work. (See, for example, the articles here and here.) I also tried adding a couple more registry entries for good measure. Sure enough, after five attempts my scan passed! (Based on this Microsoft article I had thought the server just needed a reboot but wasn't in a position to do that. In the end no reboot was needed.)

Proprietary Web server failure

We have a CCTV system accessible to authorized staff from outside the network. It has a character-based interface and a Web interface. Our PCI scan began to fail on the obscure port number used by the Web interface. This was an example of a new failure which hadn't come up before. Since the interface wasn't user-configurable (unlike IIS), our only option was to shut it down. (An alternative would have been to change our firewall to only allow traffic on that port from specified IP addresses so that the PCI scan would have been blocked on that port. We just decided to live without it instead.)

Weak ciphers on a non-standard port

Three months later yet another new failure surfaced, without us having changed our systems. Apparently we were allowing weak ciphers on port 51003. Because this was on the IP address used for our remote access SSL VPN appliance, I assumed the finger pointed at that device.

When we first addressed PCI DSS we were getting failures on this device and had a bit of a battle with the manufacturer to get them to change the firmware. Eventually they were convinced and added settings to specify only strong ciphers and to disallow anonymous connections. My first response with this new failure was to log in to the appliance, double-check the settings, reapply them for good measure and try the scan again. No dice.

I then went back to the manufacturer and, to their credit, they ran their own test and sent me a screenshot showing that on port 51003 they were getting a response not from the SSL VPN box but from our ADSL modem! So I'd been looking in the wrong place. (I'd also been indignantly sending the PCI scanning vendor screenshots from various SSL-checking sites, proudly showing how we passed their tests. They politely pointed out that the tests did indeed pass on the standard port 443 but failed on port 51003. Oops.)

We finally discovered that the ADSL modem had a Remote Support function that used HTTPS on port 51003. In the Web interface it looked as though it was already disabled but clearly that port was still open. We resorted to the Thomson SpeedTouch manual and command line interface to really disable HTTPS altogether. Finally the PCI DSS scan passed.


Passing PCI DSS external vulnerability scans can entail some detective work. Even when you get the scan to pass, expect some surprises each quarter - either because you changed your systems or because the scan finds something new.

About Mark Pimperton

Mark Pimperton BSc PhD has worked for a small UK electronics manufacturer for over 20 years in areas as diverse as engineering, technical sales, publications, and marketing. He's been involved in IT since 1999, when he project-managed implementation ...

Editor's Picks

Free Newsletters, In your Inbox