Security risks of an un-encrypted connection across an international WAN?

Question

The organisation for which I work has an international WAN that connects several of its regional LANs. One of my team members is working on a service that receives un-encrypted messages directly from a FIX gateway in Tokyo to an app server in London, via our WAN. The London end always initiates the authenticated connection, and at no point do these messages leave our WAN.

But our local security guru suggests that we should be encrypting these messages as a WAN apparently has significantly more security risk than a LAN. How much easier is it really to break into a WAN than a LAN? And what other security risks does a WAN pose in this context?

UPDATE: Many thanks for your answers. I've decided to encrypt the connection, mainly because it's clear that the WAN does introduce extra security vulnerabilities due to the hardware being outside of our physical control.

Answer 1

Any time you go through servers that you don't control there is a risk of someone either changing the data or reading the data.

You can encrypt whatever data you send that is sensitive within the application, and not be concerned with what type of connection is set up.

I would agree that encrypting is worthwhile, as it is a small price to pay if the data is sensitive enough, or if data integrity is important enough.

If data integrity is the only real issue then you can digitally sign it and just check the signature of the data when received to make certain it wasn't changed in-transit.

Answer 2

Basically, anyone controlling one network device (ie switch, router...) between A and B can intercept (and change, since FIX only implements a CRC which could be changed as well by the attacker) the content of a message.

In a WAN, there are more such devices, so more chances someone intercepts the data...

Also, WAN often use network links provided by external corps, which isn't usually the case for LANs

As a sidenote, FIX is designed to work over any transport protocol - including SSL - quite easily.

Answer 3

That very much depends on the WAN: if it is some kind of VPN connecting your various LANs (as it seems from your question) then your messages are as secure as the WAN is. The article you're linking to says:

"But there's no encryption and no additional security [with Ethernet]," Rey says. "It's just traffic separated by adding some more bits to the traffic, which brings us back to being able to modify those bits [with our hacking tool]."

If your WAN/VPN doesn't use encryption and authentication, your traffic is indeed not very secure - and you definitely should encrypt and sign your messages. If, on the other hand, you are using proper encryption and authentication on the VPN tunnels, then the messages are already encrypted once; encrypting them again would only add to the overhead.

Answer 4

You should protect traffic even on a LAN. Haven't you heard of Heartland Payment Systems and the breach of their system that processes credit cards for hundreds of thousands of merchants? Thieves were sniffing unprotected traffic on Heartland's internal network.

Do this right is cheap and easy, so the value of the data doesn't have to be that great to justify it.

Answer 5

MLPS VPN doesn't provide any sort of encryption out of the box. It provides security through isolation, not encryption. When you contract for WAN service using MLPS VPN, the telecom company is providing some guarantees that your traffic will be somewhat isolated from the rest of the traffic. AFAIK, all of this talk about the VPN encryption doesn't apply to MLPS VPN.

So really, there are two questions here: 1. If your data were compromised by someone with access to the LAN, does that pose a risk? 2. Is it easier to compromise a WAN connection?

Only you can answer #1. As others have pointed out, if any of this data is sensitive or can reveal information about other systems that can be used to compromise your network, then you need to protect it. Does it reveal anything about the gateway, it's security, behavior, users of the gateway, softwaer info, network configration, etc... then the risk of leaving it unprotected might be unacceptable.

As for #2, the answer is yes. The major vulnerability is the physical security issue. The traffic is physically outside of your control for a long distance--i.e. you are relying on the telco's physical security (badges, locked doors, buried fiber lines, etc).

The other major vulnerability is how the telco has setup the routers and other equipment that handle your WAN traffic. Are those routers physically/logically separated from other networks? What other traffic is carried by those routers? Can those routers be remotely administered remotely (perhaps via the telco LAN, another MLPS WAN, or via the Internet)?

Any of those devices can be compromised; hence, your unencrypted WAN traffic is at risk.

So, really, this comes back to #1. What are the potential consequences if your network traffic were compromised?

Answer 6

Addressing a different response, you need to be very careful to distinguish between point-to-point encryption and end-to-end encryption. HTTPS is end-to-end, nobody in the middle can see the message in plain text.

In contrast, (iirc) SMTP/TLS is a mail transport protocol that encrypts the message while "on the wire", but the message is unencrypted when it's sitting on a mail server ready to be delivered to the next system in the chain. That protects you from wiretappers but not bad actors or people who have compromised that system. The valid argument is that the mail server needs to see the message headers to know what to do with the message, but a lot of people think that the message is always protected.

Tor is another example. A lot of people had heard that the messages were encrypted between servers, but didn't realize that the message wasn't encrypted on the first and last segments. It couldn't be, not unless you could guarantee that the endpoints were running the necessary software. It didn't take long for some actors to realize that they could run Tor gateways and capture a lot of unencrypted, non-anonymous traffic from people who didn't run their own encryption layer.

You need to be very careful to verify the type of encryption offered by your VPN. A lot of the time your protocols already support end-to-end encryption channels and it may be easiest to just force people to use them even if it's 'unnecessary'. That way you're covered if somebody is fumble-fingered and accidently turns off encryption, if some node is given a court order to eavesdrop on your connection, etc.