Securing MPLS VPNs requires assessing the risk

I’ve been asked often whether Multi-protocol Label Switching VPNs are secure. The answer depends on how you define security.

I’ve been asked often whether Multi-protocol Label Switching VPNs are secure. The answer depends on how you define security.

As with any shared VPN technology — including frame relay and ATM — MPLS VPNs inherently lack the built-in privacy of wholly owned and managed facilities (private lines).

So the question is: Are MPLS VPNs as secure as wholly owned facilities? The answer is: absolutely not.

But if the question was: Are MPLS VPNs as secure as ATM or frame relay services? The answer is: absolutely.

A much better question is what can be done to make MPLS VPNs secure enough for companies to rely on them without fear. The good news is that there are plenty of options. The bad news is that not all these options are necessary — and selecting the right options takes work.

To determine the right configuration for your organization, you need to invest in upfront risk analysis. (In a later column I’ll explore how you could use the results of this analysis to design a highly secure MPLS VPN network.)

First, you should quantify your risk from various quarters. Specifically, ask yourself which entities categorically should not have the ability to read your data, no matter what. Then ask yourself which entities should have the ability, but be precluded by policy from doing so.

Confused? Here’s an example. A manufacturing company in the U.S. might decide that under no circumstances should its competitors, the press and Wall Street have access to internal corporate data. However, it’s OK if employees and the telephone company are able to access the data, but are precluded from doing so by either internal policy or U.S. government regulation.

This company might be satisfied with a configuration that encrypts its traffic while on the VPN (so other VPN customers have no way of accessing it). Furthermore, this company might be willing to rely on the telco to provide that encryption at the network layer, because it trusts the telco to abide by U.S. law.

An international pharmaceutical company might have a totally different perspective. Some of its traffic might travel across telcos in countries with questionable privacy protection — making it extremely risky to rely on the telcos to provide encryption. Furthermore, traffic might be extremely confidential (for example, information about the development of a new vaccine against bioterror attacks), requiring protection not only from the telcos and third parties, but also from internal employees. The best solution here might be desktop-to-desktop encryption. That way, even traffic on the corporate LAN is protected from prying eyes.

A final issue to address is your organization’s vulnerability to denial-of-service attacks. Exactly how bad is it if networked resources are down? For some, the solution is to develop policies that let them function offline. For example, a large check-clearing company simply has as a policy that if the network’s down, all checks less than $100 are automatically cleared. Other companies (for example, Nasdaq) can’t function without being online — and these companies have quadruplicate and quintuplicate redundancy scenarios.