I\u2019ve been asked often whether Multi-protocol Label Switching VPNs are secure. The answer depends on how you define security.I\u2019ve been asked often whether\u00a0Multi-protocol Label Switching\u00a0VPNs are secure. The answer depends on how you define security.As with any shared\u00a0VPN\u00a0technology \u2014 including\u00a0frame relay\u00a0and\u00a0ATM\u00a0\u2014 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 \u2014 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\u2019ll 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\u2019s 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\u2019s 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 \u2014 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\u2019s 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\u2019s down, all checks less than $100 are automatically cleared. Other companies (for example, Nasdaq) can\u2019t function without being online \u2014 and these companies have quadruplicate and quintuplicate redundancy scenarios.