PCI Scan Failure - SPX TLS 1.0

I'm amazed that your organization is only now failing it.  It appears that the last Up2Date applied, 9.311, was over three years ago, long before the BEAST and POODLE flaws were remediated.  The first thing you should do is apply Up2Dates through 9.605, following instructions in https://community.sophos.com/products/unified-threat-management/f/remote-ethernet-device-red/110908/solved-red15w-does-not-update-it-s-firmware-after-update-the-utm-to-9-601-5/411255#411255.

I suspect that you will not be able to do that because your root partition is too full and will cause Up2Dating to fail.  As root at the command line, run df -h|head -2 and show us the result.  If the Use% is over 80%, also show us the result of ll /var/up2date/sys.

If you're using the SMTP Proxy in Email Protection and the PCI scan fails because your minimum TLS Version is v1.1 or lower, let's work on that in a new thread in the Mail Protection forum.

Once you've applied the Up2Dates, have the PCI scan run again.  Please let us know the result.

Cheers - Bob
PS You started this thread in the Web Server Security forum.  Are you indeed using the WAF, or is traffic to your servers handled with DNATs?  And, shouldn't I move this thread to the Email Protection forum?

We haven't needed SPX until now, PCI is only failing on the SPX port, I guess that's why we never noticed. As for being behind in firmware, that's an embarrassing lapse on our end. Our firmware has always said "Your firmware is up to date." I guess because we had the firmware download option set to manual? We were aware of POODLE, BEAST, etc and had those patched on all other major systems (mostly servers). 

1. Used is only 55%. 

2. We're only failing on the SPX port

3. Not certain how I mistakenly posted here, we do not use WAF, you can move this. 

Is that thread about the RED issue the one you meant to link? 

Thanks for the quick response, and help!

The link is to instructions on Up2Dating to 9.605.  Folks that are already on 9.60x need to follow a specific procedure.

Rather than overload the root partition by turning on automatic downloads of firmware updates, I suggest that you do manual downloads from the command line.  Leave firmware downloads set to manual, then download and apply in blocks. I keep these instructions for my clients, but I had to update them because the developers have eliminated some files that jump versions.  The last one at the bottom of the last block, for example.

As root at the command line, copy and paste the following block:

cd /var/up2date/sys
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.311003-312008.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.312008-313003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.313003-314013.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.314013-315002.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.315002-350012.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.350012-351003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.351003-352006.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.352006-353004.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.353004-354004.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.354004-355001.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.355001-356003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.356003-357001.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.357001-358003.tgz.gpg
/sbin/auisys.plx --showdesc

A few minutes later, check that the Up2Dates are ready to install in WebAdmin.  When the 9.358 Up2Date is available, schedule to apply it when a downtime of 5-to-10 minutes will be least disruptive.  The earlier Up2Dates will first be applied automatically in order.

After the UTM has rebooted after applying the Up2Dates, do as above with the following two blocks, being sure to apply in WebAdmin between download sessions.

cd /var/up2date/sys
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.358003-404005.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.404005-405005.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.405005-406003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.406003-407003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.407003-408004.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.408004-409009.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.409009-411003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.411003-412002.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.412002-413004.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.413004-414002.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.414002-415001.tgz.gpg
/sbin/auisys.plx --showdesc

cd /var/up2date/sys
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.415001-505004.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.505004-506002.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.506002-507001.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.507001-508010.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.508010-509003.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.509003-510005.tgz.gpg
wget http://ftp.astaro.com/pub/UTM/v9/up2date/u2d-sys-9.510005-605001.tgz.gpg
/sbin/auisys.plx --showdesc

Cheers - Bob

Amazing, thank you for the very thorough write-up. I'll give these updates a go after hours. 

For what its worth, deprecated/insecure crypto protocols aside, any "proper" security audit (be it external or self-assessed depending on which flavor your required to run) for PCI-DSS compliance, should have flagged up several years outdated firmware on a security appliance and edge network equipment that is within the card data environment long since.  Being that it is one of the principal tenants of the PCI-DSS standards.

If it were me, I would question what value these automated scans are bringing.

Just my 2p worth.

The purpose of PCI DSS is to ensure that the banks can blame you if a breach occurs.   You will go bankrupt or go to jail, not them.    They make you sign an affidavit that you have a perfect network.  If you say that you had a perfect network, and then you have a breach, and then the forensics indicates that your network was imperfect, guess who is in trouble?

External scanning helps plug some of the obvious holes, but it also raises questions.   If the scanning services can tell so much about what products I am using and what versions of those products, the first priority should be to plug the information leakage.   But I have not figured out how to plug the leak and they have not told me.   So instead they tell me to figure out if my vendor has backported a patch for CVE-x-x on my product P version x.x.

Guys, my guess is that most of the people that run PCI scans really know very little.  They're clerks that simply keep track of whether their client has gotten assurance from his supplier that CVE-x-y has been mitigated when their imperfect scanning flags a potential vulnerability.  I'd have to agree that if the latest scan was done by the same company that's been doing them  before, it's time to find a better PCI scanner.  That's my $0.02 worth. ;-)

Cheers - Bob

Guys, my guess is that most of the people that run PCI scans really know very little.  They're clerks that simply keep track of whether their client has gotten assurance from his supplier that CVE-x-y has been mitigated when their imperfect scanning flags a potential vulnerability.  I'd have to agree that if the latest scan was done by the same company that's been doing them  before, it's time to find a better PCI scanner.  That's my $0.02 worth. ;-)

Cheers - Bob