PCI Compliance with connected REDs. Auto-fail. Sophos gave up.

Question

We have a recorded instance of a Sophos XG (v17+) failing a PCI compliance scan (by a major provider) because they use RED appliances. I asked if Sophos could provide me with mitigation policy or something I could give the PCI compliance vendor an exception basis. 
 Support eventually came back with: 
 Sophos RED communication is designed to use self-signed certificates between the XG and RED devices. Self-signed certificates will fail/warn on PCI scans as they are not trusted. We do not have a document to mitigate this design as there is no vulnerability with using self-signed certificates. 
 Now, the last sentence is laughable, but the concept that a firewall vendor can't make a PCI compliant hardware-accelerated VPN tunnel is mind boggling.

TimHansen · Accepted Answer

John, please see this knowledge base article which explains how to pass PCI compliance when using a RED with XG. 
 https://community.sophos.com/kb/en-us/127451 
 Tim

Emile Belcourt · Answer

Self Signed Certificates can be just as trustworthy as publicly trusted certs. I have successfully got PCI Compliance agencies to accept the response/contestation and overrule their own fail and warn due to the nature that you are in control of the Certificate Authority that generates the certs. 
 Support is correct in their response, there is no more vulnerability using a self signed certificate (generated by a self signed Certificate Authority) than there is one that is publicly trusted (with caveats). Hell, Comodo has had theirs compromised on numerous occasions and I don't see Comodo being flagged by PCI compliancy. 
 PCI Compliancy is fairly ridiculously broad and some of their "warns/fails" and are as bad as PSN/OFSTED restrictions which have been made by those with little understanding of the system at hand. 
 You can contest Self Signed Certificate issues as long as you can provide them information that you are in control of the CA, in this case, is Sophos (Sophos red.astaro.com IIRC) so therefore is a functional certification system. 
 To label Sophos with inferred incompetency is unfair as it is the compliance scanning system that is incompetently flagging a warn/fail. 
 The exception to the above is if a certificate is generated with no CA (fully self signed) then yes, it is unsafe for use because it cannot be revoked and if there is no way to validate the certificate with its CA. I believe the RED system complies with both. 
 
 In response to TrustWaves request, the RED appliance can only establish a tunnel with the appliance holding that certificate and private key which was generated and provided as part of the provisioning service. The RED appliance will also only be set to connect to an target IP/DNS that also holds that Cert. This also means that the RED appliance will reject the connection if any form of interception on the path to the XG is done as it is a fixed variable. If they cannot accept this answer, I would recommend getting a statement from a Sales Engineer via the account manager on the operating principles of RED and why it is a secure connection. Tbh, the RED tunnel is as secure as using digital certificate security on an IPSEC site to site and they accept those for transfer. In fact they allow cardholder data to flow across an MPLS which is even less secure than IPSEC/RED However, it depends how you mean about cardholder data flowing through it?

FloSupport · Answer

Hi John Woodall 
 Thanks for reaching out and my apologies for your negative experience. 
 I was able to locate your support case and review the activities within. Has your third-party compliance scanning provider responded back to you regarding this exception? 
 For reference to our community, this was the KB article and information shared: 
 
 Sophos UTM: RED configuration for PCI DSS compliance 
 Here's the Sophos XG article: Sophos XG Firewall: RED configuration for PCI DSS compliance

RED devices use a self-signed certificate in a private trust model rather than the public CA trust model, so there is no danger of a Man-in-the-middle attack fooling the RED device or the Sophos UTM. Also certificate pinning techniques are used to ensure that only our RED devices can connect to the RED server on Sophos UTM. For more reading about certificate pining, please visit Certificate and Public Key Pinning . 
 However the self signed certificate can be flagged as a problem on some security audits that don't take the full context of it's use into account. If this is the case, the following steps can be used to ensure that RED server port is only accessible from the source IP addresses of the RED devices themselves. 
 We need to create a DNAT rule in Sophos UTM which takes any inbound connections over TCP 3400, and route them to a null interface (any non-existent IP). We then create a second rule to exempt the expected RED traffic from being sent to this null interface / IP. 
 First, we need to add a rule that matches the traffic from the internet on port 3400, and sends it to NULL. The NULL object is a host object with a non-routable IP address. This rule ensures that any RED traffic not coming from the branch office address is dropped at the first module in the pipeline.

Please don't hesitate to PM me if you would like to discuss this issue or your support case further. 
 Regards,