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

How to pass PCI Compliance scan when RED (tcp/3400) uses a weak cipher?

Our recent PCI Compliance scan came back failed because the RED service uses RC4-SHA. This is also one of the issues that the scanning company (Trustwave, who is used by our credit card processor, FirstData) will not allow to be overridden. If this is the opinion of a major credit card processor such as FirstData, you can assume that this is the opinion that much of the industry is going to have soon.

The ciphers used by RED aren't configurable, and the RED service is conspicuously absent from Sophos' SSLv3 mitigation document (https://community.sophos.com/kb/en-US/121509). I've already contacted premium support, and their response was basically, "we're aware of the issue." (Of course they're still selling RED devices as a secure means of extending your network.) They offered no advice on mitigation, other than the implied advice to wait for the patch...which any long time customer know could mean anything.

Since my remote locations that use RED have static IPs, I attempted to just add firewall rules to fix this (only allowing my IPs, drop all others). Except that RED communication must be handled prior to firewall rules, so they're completely ignored.

So the only thing left I can think of, is to go out and purchase another firewall to put in front of the UTM. Certainly not the conversation I'd like to have with those that approve large purchases such as that.



This thread was automatically locked due to age.
  • Just heard back from support again, they are not aware of any workarounds until 9.4 is released.

    Maybe I'll fire up an old ASG220 I have laying around and put it in front of the UTM320 (...only half-kidding)
  • Almost all PCI compliance scans have a process to exclude results where the traffic is not used to process credit info.
    This is common practice. You'll need submit a request to exclude the RED traffic (as Credit Info can be submitted via the RED port)

    We do this all the time for our customers.
  • That is typically the case, but Trustwave has stated for this particular issue, "Please note that this vulnerability CANNOT be disputed using a Risk Mitigation and Migration plan."

    On top of that, credit card info does go over the RED links, from point-of-sale PCs back to a main server that processes the transactions.

    Their position makes since, this is a vulnerability that causes RED to be somewhat insecure, not a false-positive. Sophos has to have been aware of this issue for a long time, since they have a fix for every other SSL service, and a timeframe of "months away" for a security company to fix a well known vulnerability isn't comforting.
  • Hi, Jon, and welcome to the new UTM Community!

    Check #2 in Rulz. You'll see that you want DNATs instead of firewall rules.  You will want to NoNAT the IPs you allow and then DNAT packets from "Internet" to a non-existent IP.

    It's hard to imagine that Support didn't suggest this.  Please PM me with your ticket number.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • Thank you, Bob!

    Your solution worked perfectly, and I'm now receiving a passing grade on the scan.

    Community forums: 1
    Premium support: 0
  • It sounds to me like you have successfully blocked Trustwave from detecting the security issue, but of course you cannot fix the vulnerability that Trustwave was identifying, which is that the traffic flow is at risk of interception and decryption by a determined adversary. You have mitigated the risk by ensuring that traffic is only accepted from the expected IP addresses, which is a good thing to do in any scenario and is a better defense than doing nothing. But I don't think that the attacks on weak ciphers require altering the source or ip destination of the traffic.
  • Hi, Douglas, and welcome to the UTM Community!

    I'm not convinced that the RC4-SHA cipher is used in RED in a way that would allow such an interception. In fact, RC4-SHA is fine when used with SSLv3 or TLSv1.

    Jon, please submit a support request to have this confirmed by Sophos one way or the other.

    Cheers - Bob

     
    Sophos UTM Community Moderator
    Sophos Certified Architect - UTM
    Sophos Certified Engineer - XG
    Gold Solution Partner since 2005
    MediaSoft, Inc. USA
  • I note that there is now a kb article that givrs dtro by step for fixing RED 4to be pci compliant