| |
| 1. What data security features does your network offer? |
| |
| ] |
Be aware of the difference between private and public satellite networks. Private satellite networks imply a level of security because only your sites share the allocated bandwidth for your network. In contrast, with a public satellite or broadband satellite network, you share the bandwidth with all the other customers that the satellite provider has signed up for the shared network. Whether public or private, satellite data transmissions, by virtue of traveling through the air (as compared to buried fiber or copper), are easily accessible to everyone that uses the same hardware from a given provider. Since access to your network is not solely under your control, it is imperative that your data be encrypted.
|
| ] |
Encryption options for satellite networks (public and private) are: none, single direction (downstream) or bi-directional (downstream and upstream). Between the satellite links, many satellite service providers provide either no encryption at all (common for private networks) or only downstream encryption (see Diagram 1). Again, since the data is traveling through the air and accessible to everyone, unencrypted data is an easy target for would-be intruders.
|
| ] |
Encryption between the satellite links (described above) is often combined with a Virtual Private Network (VPN) from the service provider’s Network Operations Center (NOC) to your HQ (commonly referred to as a “VPN backhaul”). This VPN backhaul requires two devices: one at the NOC and one at your HQ. What the service provider fails to mention in this scenario is that your data is unencrypted at the NOC as it travels from the satellite link to the backhaul VPN device (see Diagram 1). This means the satellite service provider, their vendors and any personnel with access to the NOC become de facto trusted members of your network since they could gain access to your unencrypted data.
|
| ] |
Another critical point is control of the encryption process. In most cases, the encryption across the satellite links takes place within the service provider’s hardware (ex. inside the satellite modem) — outside your control. Additionally, with a VPN backhaul, you must share control of the VPN appliance in the NOC with the service provider. Remember — you have neither knowledge nor control over what happens in the satellite provider’s NOC.
|
| ] |
Data is transported in packets that are comprised of a header and a payload. The header contains all the protocol information for the packet and the payload is the application data. VPNs come in two basic flavors: tunnel and transport mode VPNs. Tunnel mode encrypts both the header and payload while transport mode encrypts only the payload. Transport mode VPNs suffer from the glaring security flaw of leaving the TCP/IP header information (including the source and destination addresses) unencrypted. This weakness exposes your corporate network to any number of well known “spoofing” and “man in the middle” attacks because only the payload data is encrypted.
|
| ] |
Many VPN appliances, including TCP accelerator devices, that claim to function over satellite require the VPN to be configured in transport mode. Do not accept anything less than a VPN solution that operates in tunnel mode, encrypting both the header and payload, for maximum security.
|
| ] |
Best practices also dictate that you control your WAN security independently from the carrier infrastructure to avoid elevating the carrier to a trusted member of your network. |
| ] |
Do not accept anything less than a true site-to-site IPSec VPN that offers bi-directional, end-to-end data security using devices on your premises that are solely under your control. . |
| Diagram 1 - Traditional Satellite VPN Solution |
| |
 |
| Weaknesses |
| |
| ] |
Desktop VPN clients can cause conflicts with other security software (e.g., anti-spam, anti-virus, personal firewall, intrusion detection and IPSec VPN clients). |
| ] |
Piecemeal encryption creates security flaws - Your data is unencrypted in the NOC |
| ] |
You have no control over satellite personnel and NOC security |
|
| |
| 2. What type of VPNs function on your satellite network? |
| |
| ] |
You also need to be aware of the difference between standards-based (IPSec) and proprietary encryption methods. Some VPNs that claim to work over satellite use proprietary encryption to protect your data. Aside from requiring you to deploy an additional device (see Diagram 2), proprietary encryption methods are suspect for the following reasons: 1) you must trust the integrity of the encryption scheme used by the vendor since proprietary encryption methods have not been validated by the IT community (unlike IPSec), 2) proprietary encryption methods may not be compatible with other firewall appliances and 3) your applications may not run properly due to conflicts with the encryption technology.
|
| ] |
Application level VPNs are fundamentally different than IPSec site-to-site VPNs. Some application VPNs require that a software client be installed on every PC on the LAN at the remote site. SSL-type VPNs utilize a browser for access and encryption, but are only useful for web-enabled applications.
|
| ] |
Many VPNs only offer 3DES (pronounced “triple dez”) as their standard level of encryption and often require hardware acceleration to meet performance requirements. 3DES is an obsolete encryption method that has been replaced by the Advanced Encryption Standard (AES) mandated by the US government. To upgrade a 3DES VPN device requires the purchase and field installation of an AES accelerator chipset, or more often, a whole new VPN appliance.
|
| ] |
Make sure your VPN solution is IPSec compliant and offers at least AES-128 as standard with AES-256 as an option (even better is a solution that uses AES-256 as its standard level of encryption). |
| Diagram 2 – Proprietary Satellite VPN Solution |
 |
| Problems |
| |
| ] |
You have no control over satellite personnel and NOC security |
| ] |
Additional device and remote management of equipment in satellite NOC |
| ] |
Obsolete, non-standard encryption methods |
| ] |
Enterprise applications do not run remotely through proprietary VPN (Not IPSec compliant) |
|
| |
| 3. Where are the firewalls to protect my remote offices from the Internet and who controls their configurations? |
| |
| ] |
In the traditional VPN solution, the endpoint of the backhaul VPN is also a firewall and resides in the NOC of the satellite provider. Usually the satellite provider requires access to device, so that management of the firewall is not completely under your control. Furthermore, it must be managed remotely since it does not reside in your facilities.
|
| ] |
Some proprietary encryption devices have no firewall functions; others contain simple packet filters. At a minimum, you should demand a full, stateful packet inspection firewall with a complete feature set including: filtering on all packet attributes and complete Network Address Translation (NAT) functionality.
|
| ] |
Application level VPNs and SSL-type VPNs do not provide any firewall protection of the remote office LAN from the Internet, so a separate device must be installed and managed, adding to the “device creep” problem in the remote office. |
| |
| Performance |
| |
| 4. Will my enterprise applications work over satellite through your VPN and, if so, what will the end user experience be like? |
| |
| ] |
Many current VPNs (i.e., appliances that function over DSL or cable) will not even sustain a connection over broadband satellite. Those devices that are able to sustain a VPN connection degrade satellite broadband performance resulting in a user experience similar to dial-up for enterprise applications such as SAP, Lotus Notes, Citrix, etc.
|
| ] |
Some satellite providers now offer TCP accelerator devices to restore the performance losses caused by VPNs. Be careful — accelerators will usually only improve performance in large data transfer applications (such as file transfer and video streaming). TCP accelerators do not improve the performance of interactive, low bandwidth, client-server applications such as SAP, Lotus Notes or Citrix.
|
| ] |
Ask your VPN solution vendor to provide you client references that you can contact directly to verify they have successfully run your mission critical applications over satellite with an acceptable user experience. |
| |
| Complexity |
| |
| 5. How many devices are required in the remote office to connect to the headquarters? |
| |
| ] |
If a TCP accelerator device is required, you will have a minimum of three (3) separate devices (satellite modem + accelerator + firewall/VPN) from multiple vendors at your remote site. |
| ] |
The accelerator device costs anywhere from $1,500 to $3,000 for each site and you will still need to procure, install and manage a Firewall/VPN security appliance at each site.
|
| ] |
Satellite VPNs that rely on proprietary encryption methods require that you deploy an additional device at the satellite provider’s NOC (see Diagram 2). This additional device not only increases the complexity to your network; it poses a major security risk, as you have no control over the satellite provider’s NOC personnel or security.
|
| ] |
With fewer network devices deployed, network management becomes simpler while associated network costs drop. The satellite modem and a single, integrated security device is the ideal solution for remote offices. |
| |
| 6. Who installs and supports each device? |
| |
| ] |
Many VPN devices require expensive certified network engineers to be dispatched to the site to install and configure the VPN solution. In many cases, repeated site visits by different engineers are required to complete the installation.
|
| ] |
Multiple devices from different vendors ensure you will experience frustrating finger pointing when trying to troubleshoot your network.
|
| ] |
Make sure your remote office staff can deploy your VPN solution and that it is easy to configure, manage, and troubleshoot remotely. |
| |
| 7. How do I manage the VPN solution and what kind of training will I need? |
| |
| ] |
Most VPN solutions require a network security professional to configure and manage VPN connections. You must train your IT staff, hire the expertise or outsource your network security. In all cases, it is important to factor these ongoing expenses into the Total Cost of Ownership (TCO) of any VPN solution.
|
| ] |
Make sure you understand the cost of training and the man-hours required to manage your VPN solution. Learning yet another command line interface syntax is an expensive and costly way to manage your WAN. |
| |
| 8. Does the VPN solution touch the desktop PCs at the remote site? |
| |
| ] |
Here you need to be aware of the difference between Application Level and IPSec VPNs. Application level VPNs require client software to be installed on every desktop PC that will access the VPN. Extending the VPN functionality to the desktop level exposes you to a different set of complications. For example, installing application level VPN client software on a Windows 2000 or XP desktop yields the following problems:
|
| |
| ] |
Desktop VPN clients can cause conflicts with other security software (e.g., anti-spam, anti-virus, personal firewall, intrusion detection and IPSec VPN clients).
|
| ] |
Desktop VPN clients can cause incompatibilities with application client software such as Oracle, SAP, Lotus Notes, etc.
|
| ] |
Exploitation of well-known security loopholes on the desktop operating system can give intruders VPN access to your network.
|
| ] |
VPN connection reliability is dependent on the user not altering the desktop configuration.
|
|
| ] |
Application level VPNs using desktop client software offer little firewall protection. SSL VPNs also require a firewall appliance to protect the LAN from the Internet, and some application level VPNs conflict with in-line firewalls.
|
| ] |
To avoid the above pitfalls, look for IPSec VPN solutions which allow you to adhere the best practice of separating your remote site and desktop security. |
