Data protection over WANs: Security

Posted on January 01, 2006

Security should be a primary consideration when implementing a WAN-based backup-and-recovery system.

By George Hall

In the November 2005 issue of InfoStor (see “Data protection over WANs: The network,” p. 32), we described the issues that need to be considered when you are planning to implement backup and recovery over wide area networks. In this article we continue our investigation into backup/recovery over WANs by focusing on security and how it applies to several areas of service delivery, and more specifically to the process of disaster recovery and archival operations using digital transmission methods. These areas include network security, the Internet and private lines, and physical storage security.

Network security: The Internet

The Internet is not secure. That is stating the obvious. What is not so obvious is how to secure Internet-based services or applications. Protecting data during transmission is not enough; it must be secure during storage as well. All too often security discussions begin and end with the network, when in fact there is much more to consider.

From a technology perspective, encryption is the solution to WAN-based security. For example, FedWire, which is the universal medium that all US banks use to exchange financial data, uses encryption to secure transfers of digital data between banks. This is the standard that IT professionals should aim for in regard to digital transmission of customer data. The type of encryption that FedWire uses is classified, but equivalents to it in the commercial sector are available with varying degrees of efficiency depending on implementation methodologies. FedWire transmissions can be characterized as high-transaction volumes and small file sizes. In contrast, disaster recovery and archival transmissions typically involve low-transaction volumes and large file sizes (with the exception of desktop file-level recovery).

The current standard, Advanced Encryption Standard (AES), is a 128-bit block cipher with a key size of 128, 192, or 256 bits. AES was adopted as an encryption standard by the US government in 2001. It is expected to be used worldwide, as was the case with its predecessors-the Data Encryption Standard (DES) and Triple DES. DES was successfully hacked by the Electronic Freedom Foundation (EFF) in 1999 and Triple DES was a short-term fix to solve that problem, although it created other problems. For example, it took three times longer to encrypt data with triple DES than with simple DES.

Encryption methodology

There are two methods for encrypting digital data streams: software and hardware.

Software-based encryption with DES, and Triple DES especially, was extremely slow. AES was designed to increase protection while at the same time improve processing efficiency. However, it is important to note that even if a data stream is encrypted it can still be captured from the Internet by hackers. Thus a new concept needs to be considered: the time value of information.

Most commercial business transactional data has a short half-life. In other words, its value diminishes rapidly over a short period of time. If hackers can get at encrypted archival data, but it takes more than the half-life of the information to decrypt it, then by the time the information could be decrypted it could be worthless. Disaster recovery and archival data has archival value but not transactional value.

Therefore, archival data typically has relatively low value to interceptors. Of course, there are dramatic examples of events such as credit card theft, but these types of longer half-life archival information have a time value as well. If the data is properly protected by encryption it will be secure.

In general, hardware-based encryption is the way to go. A number of vendors have hardware-based encryption devices with custom silicon specifically for doing AES encryption. The reason that hardware is better than software for encryption is that it is faster, more efficient, and more difficult to hack, and for larger data sets it’s less expensive than burning up dedicated servers.

Network security: Private lines

Virtually all transactions in the financial industry operate over dedicated private line services with encryption. While this is more expensive than using the Internet, it is far more difficult to intercept. Enterprise-class users of networked disaster recovery and archival services should insist on direct private line services. Large companies may also have their own systems and networks in place for restoring transaction engines in the event of a loss at the primary location.

Private line services are more secure because they are not shared by anyone outside of the origin or destination end points. Furthermore, because of this one-to-one relationship, compared to the Internet’s many-to-many relationship, users are free to determine capacity planning, conformance to corporate policies on digital data security, and many other issues.

An effective security solution will take into consideration the need for flexibility in disaster recovery and archival planning and implementation. What should be most important is the ability to plan with a full understanding of the variables and necessary network and service capacities required to support various types of disaster-recovery applications and network payloads.

Digital storage and security

IT managers should spend time with line-of-business managers to understand their DR and archival needs. Once a plan is developed, IT can create a cost and chargeback model for the infrastructure.

Physical storage security: Disk

Let’s assume that you want to move away from tape-based disaster recovery and archiving and instead deploy a tiered archival configuration for near-real-time restoration of transaction systems (in other words, mirrored storage over a network). This is common at the high-end of the market (and is very costly) and in many cases is done entirely on an internal basis without a service provider in the middle. The need for transaction storage services is growing, however, and they are expanding as implementation costs continue to drop.

Security and integrity of data (encrypted or not) in a shared resource environment needs to be clearly demonstrable to non-technical end users. Disk farms, network-based filers, and SANs are all most cost-effectively managed as a shared resource.

Physical storage security: Tape

There is little difference between current “sneakernet” movement of computer tapes and the transmission and replication of tape-based data over a network, encrypted or not. One distinct advantage of network-based tape transmission is that the audit trails are more precise with respect to what was received and how and when it was received. The IT organization will still be faced with the issues of tape libraries and wrestling with physical tapes, chain of custody, and recovery, but it may also then be necessary for the disaster-recovery and archival applications to ensure the long-term integrity of the newly created tape volumes. This is a potential liability that is not currently accounted for in many IT shops.

A good rule of thumb is that anything kept more than 10 years on magnetic media is in jeopardy of data loss at the bit level. If there is a strong desire to continue to support tape archival services, it would be far more cost-effective to set a baseline for end users using existing tapes and encryption techniques and then incrementally add to these tape volumes on a recursive basis over the network. In this fashion the daily data volumes would be much more manageable, and it would give end users the ability to batch jobs on a disk-to-tape basis over the network and after hours.

It is not enough to secure network connections with encryption and physical security; archival systems must be configured to store encrypted data seamlessly as well.

In the next article in this series we will explore effective methods for planning data recovery over WANs.

George Hall is a technology partner with Ridge Partners LLC (www.ridgellc.com).

Please enable Javascript in your browser, before you post the comment! Now Javascript is disabled.