What is the target infrastructure?

External PCi scans are next to useless for anything meaningful.  It is quite easy to make an external pci scan "pass". If you do have to open something up to the world and you fail you need a competent security analyst who can look at things and then explain to PCI that the version numbers they are seeing are not neccessarily grounds for a failure.  These external scans go only by the announced version numbers with no accounting for why.  Case in point...a client of mine "fails" pci routinely until i tell them that the Apache server they think they are seeing is from RHEL and the version number doesn't mean it is vulnerable.  I then have to explain the practice of backporting and once I do that the client gets passed....until the next scan and a different analyst doesn't take the time to read the notes on the account and we get to explain it again.

External PCi scans are next to useless for anything meaningful.  It is quite easy to make an external pci scan "pass". If you do have to open something up to the world and you fail you need a competent security analyst who can look at things and then explain to PCI that the version numbers they are seeing are not neccessarily grounds for a failure.  These external scans go only by the announced version numbers with no accounting for why.  Case in point...a client of mine "fails" pci routinely until i tell them that the Apache server they think they are seeing is from RHEL and the version number doesn't mean it is vulnerable.  I then have to explain the practice of backporting and once I do that the client gets passed....until the next scan and a different analyst doesn't take the time to read the notes on the account and we get to explain it again.

Happy Easter to you, Mr. HesComingSoon!

My scanning service remembers things after I prove it to them, but it is tedious to get things proven.  They need me to collect and provide evidence for each CVE individually, for whatever CVEs are known now, and next month for whatever ones appear next time.   Assume 5 or 6 products, with perhaps an average of 5 to 10 CVEs per product.  Would I rather collect these 25 to 50 pieces of evidence, or simply know it will not be necessary?

Will Sophos include a set of scripts for documenting all of the backports that have been applied to whatever infrastructure is delivered in 9.5?  That would certainly help.

Infrastructure also has implications for functional capabilities.  

• Websites that incorrectly send a root certificate (such as UTM WAF) are rejected because the older versions of OpenSSL cannot ignore a root certificate in the downloaded chain.   I think the OpenSSL version that fixed that problem is at least 18 months old.  Most system managers don't even know how extensive the problem is because the standard reporting won't tell you.  Maybe that is why Sophos has felt no urgency to fix either OpenSSL or WAF.
  
  
• Another poster to either the community or Ideas.sophos.com has complained about the functional impact of the very old version of embedded Firefox.

Configuration control is an important part of security.   These questions are things we should know as a matter of good governance.  PCI helps to force the issue.

I agree with hcs, Doug.  These PCI scanners are lame as they only look for the simple things, they don't actually try the exploit which would be blocked.  One customer failed when the scanner thought the SMTP Proxy was a web server.  There's a reason these services are so cheap.

The Sophos Up2Date blog mentions CVEs fixed, e.g., UTM Up2Date 9.358 Released where CVE-2016-5696, CVE-2016-2776, CVE-2016-5195, CVE-2016-7397, CVE-2016-7442, CVE-2016-2108 & CVE-2016-2107 were fixed.

That said, it would be nice if Sophos would provide a KnowledgeBase article that they updated with each Up2Date or pattern release and the CVEs it addresses in the version of the particular UTM component in use.

Cheers - Bob