Thread Info
  • State Verified Answer
  • +1 person also asked this people also asked this
  • Locked Locked
  • Replies 12 replies
  • Answers 1 answer
  • Subscribers 28 subscribers
  • Views 4326 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

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

John Woodall

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.



This thread was automatically locked due to age.
  • +1

    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

  • 0

    Hi  

    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,

  • 0 in reply to FloSupport

    Still curious about this point.

    Because UTM uses the same method for years and this question did not came up much in the past years for UTM. 

    This came up quite frequently lately. Most of the time, if i talk to partner / customers, they can create exceptions for our RED Product. Because it relies for years on this mechanism of using self signed certificates. 

  • 0 in reply to FloSupport

    It is possible the guide I followed previously was for UTM, which caused the REDs to not reconnect after an event.

    I can try the new procedure for XG - however we are awaiting a response from TrustWave.  Unfortunately my time to work on this particular issue is limited, but I hope to do so on 1/15/19.

    Trustwave wants proof that only RED appliances will use the self-signed cert (and that no card-holder data will pass through this connection); this proof was not offered by Sophos, only a statement.  And while in our case, no card-holder data does, if it did - I fear it would be a compliance fail.

  • +1

    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?

  • 0 in reply to Emile Belcourt

    I tried to get that information - but was only presented with the above information, which was like saying "trust me".

    Hence my frustration - and yes, I understand that some compliance organizations are simple knee-jerk reactions, but they're the ones put in charge of checking and the ones the customers have to answer to.  Like it or not, we have to play their game. 

    We are not given the opportunity to educate them about WHY they're wrong.  Just have to provide vendor information on why it's mitigated.

    I will forward your response along. 

    Thank you,

    John

  • 0 in reply to John Woodall

    I agree it's a massive pain in the butt. If you want to use my contestation i used last time, it was this:

    "Sophos RED tunnels are end to end encrypted Layer 2 tunneling devices that use strong AES encryption standard ensure data is secure with an appropriate hashing algorithm. The connection between the RED appliance at the remote aite and head office is secured using public-private key encryption using digital certificates to ensute that the RED device only connects to the head office Next Generation Firewall Appliance.

    This certificate is generated and distributed using Sophos internally trusted Certificate Authorities to ensure no public exposure risk. This certificate can be revoked by the appliance in use at any time.

    This system is as secure, if not more so, than an IPSEC site-to-site tunnel using digital certificate authentication to marry our remote site into head office.

    Added security from our RED box implementation is if the box is stolen then it will be automatically deauthorised to prevent compromisation."

    One of our customers has 23 shops all with card machines that run through a RED and this passed a contestation. If Trustwave do not accept that, ask what mitigation/security details they will accept and apeak to your partner/account manager.

    Hope that helps!

    Emile

  • 0 in reply to Emile Belcourt

    On a side note, Support may not have the best knowledge in this area so would have been best going to engineers knowledgeable in this area. It was pretty poor show of them to brush off. Which team did you speak to?

  • 0 in reply to Emile Belcourt

    Premier Partner Support.

    I have also provided the other information to our customer to send to TrustWave.  I appreciate your efforts at detailing the WHY.  I believe this is thorough enough for them and will put our customer at ease that this is a TrustWave issue, not a lack of security on Sophos part.

  • 0 in reply to John Woodall

    Happy to help!

    RED boxes are my most favourite feature of the UTM/XG and i have resolved many problems using a red from circumnavigating weird routing to assisting small offices for businesses who don't want to dish the cash for a bigger firewall because the beancounters are mean.

    The most I've ever deployed was over 60 in one sitting, after the first 7 i went out and got a usb barcode scanner because i couldn't be bothered to type the serial in!

    Fingers crossed you get better support in the future, support team access for partners got collateral damaged by a global change. So if you have problems not directly related to a broken box and are like this, i would recommend asking your account manager to put you in touch with a sales engineer to discuss the issue :)

    Emile