This article can also be found in the Premium Editorial Download "Information Security magazine: Security 7 Award winners sound off on key information security issues."
Download it now to read this article plus other related content.
There are countless mechanisms available for protecting data as it flows across a network. Windows Server provides IPSec encryption. Mobile users accessing a Windows network through a Windows-based VPN can be protected by PPTP, L2TP or SSL encryption. Of course, these are just software-based encryption solutions native to Windows. There are also third-party encryption solutions that work at the hardware and software level.
There are two major drawbacks to encrypting network traffic. First, network encryption has traditionally been difficult to implement.
| For example, using IPSec encryption usually requires an organization to install an enterprise certificate authority. An administrator will also have to understand the key management process, and know how to set group policies that require network computers to use IPSec encryption. Additionally, IPSec encryption will fail unless network clients are using an operating system that supports IPSec.
The other major drawback to network traffic encryption is that it can degrade performance. Every time a client needs to communicate over the network, the client must establish a session and encrypt the data that is to be transmitted. The recipient must then decrypt the data. This process increases the amount of traffic flowing across the network, and forces network client machines to spend additional time and CPU resources encrypting and decrypting data.
Network cards exist that can offload the encryption and decryption process from the CPU. This doesn't decrease the traffic flowing across the network, but it prevents network clients from suffering from decreased performance.
Many products on the market include application-level encryption capabilities. Some of the best known are file compression utilities such as WinZip, which allows a user to create an encrypted archive file. This file remains encrypted whether or not it is stored on a hard drive that has encryption enabled. Likewise, the file remains encrypted even if transmitted across the Internet using a non-encrypted session. This is because the encryption algorithm is applied directly to the data within the file and is independent of the storage medium or network connection being used.
Application-level encryption works well for augmenting your existing security but tends to be difficult to manage. Every application with built-in encryption capabilities works differently, but generally most require the user who creates a file to enter a password to access the file. This password is treated as an encryption key. The problem is that there is usually no way to centrally manage these passwords. If a user forgets the password they assigned to a file, the user loses access to the data in the file.
Furthermore, many encryption-enabled applications are not multi-user aware. This means that a user who wants to share a file with another user typically must also share the password to access the file.
Whatever solution you choose needs to be "end user proof." In most cases, applications that offer built-in encryption capabilities require users to choose to encrypt the data. Given a choice, they will often take the easy way out and not encrypt.
This was first published in October 2008