As regulations drive enterprises to rethink security strategy, and securing traffic in motion becomes a requirement, multiple encryption methods will satisfy specific encryption standards. Here's what it will entail.

September 20, 2006
URL:http://drdobbs.com/security/survive-network-security-challenges-trav/193003800

Compliance with current and pending regulations is driving network users and service providers to rethink their network security strategy. For years, data traffic within the business environment has been trusted and considered secure as it travels over local LANs and across leased lines, Frame Relay, and ATM networks. With most of this data traveling over shared IP networks, and regulations pushing to secure vulnerable traffic, security technologies must now be enhanced to provide an appropriate level of safety.

In the near future, all network traffic, whether inside the corporate LAN, across the WAN, or over the Internet, won't be trusted. This means that all frames and packets must have their payloads inspected for malicious code and all traffic must be encrypted.

Current encryption solutions simply do not scale to support the global problem of applying data protection at all end points. New technologies are required to provide a viable answer. Organizations must implement a model to leverage a common policy definition platform, separating key management capabilities to provide a broader application of encryption technology.

In some ways, large organizations are already preparing for the demands of untrusted networks by integrating security into their networks. These organizations are using firewalls and IDS/IPS technologies to inspect traffic, searching for malware and permitting or denying access to intellectual property. Much more is needed. Traffic must be secured as it moves throughout the network.

Consider that:

• VLAN technology separates users into communities of interest, but in no way offers confidentiality, data integrity, and source authentication of traffic flowing within the VLAN.
• MPLS services separate customers sharing the network, but do not provide for confidentiality for data in transit. Any recipient of data traffic, either due to a misconfiguration or criminal intent, may access the sensitive data from customers.
• Securing multicast traffic is difficult at best, and in large implementations operationally not feasible. Imagine corporate updates, future roadmap presentations or field training being broadcasted over a shared IP network. Ensuring confidentiality of this traffic is a real problem.
• Large, secure mesh networks are operationally impossible to administer. The administration of security policies for large mesh networks is a real nightmare, with policy numbers quickly rising to the thousands if not tens of thousands.

There are a number of encryption solutions deployed today to solve portions of the problems. There are, for example, application level encryption tools, SSL VPNs, IPSec VPNs, Layer 2 encryption (IEEE 802.1ae), file transfer encryption tools, telnet encryption, e-mail encryption tools--the list goes on. These diverse technologies do indeed provide solutions for pieces of the security requirement. Yet, the encryption tools are complex, too granular in their capabilities, and almost impossible to manage. The market today needs a solution that provides a broad scope in the applications it secures, satisfies the necessary regulations and, reduces the management and operational overhead caused by the other "solutions."

Protecting data in motion
Four primary data protection technologies are currently deployed to provide portions of the available security solution. They are:

• Application Encryption
• SSL VPNs
• IPSec VPNs
• Link Layer Encryption

These approaches are very different in their implementation and provide varying advantages and disadvantages to the enterprise.

One major distinction between these implementations is the location in the application stack where the technologies are applied. Looking at the application stack:

The application layer provides end-user application and data access. These applications may be e-mail, telnet, FTP, and any other user applications (banking, engineering, etc.) The transport layer sets up end-to-end connectivity, providing both connectionless and connection-oriented protocols. TCP is a connection-oriented transport protocol that provides reliable packet delivery, error recovery, and packet reordering capabilities. The network layer is responsible for delivering the packet to a communicating peer in the network. It uses routing functions to transmit the packet across a network or the Internet. The link layer is responsible for packet delivery across a specific link, Ethernet segment, SONET segment, Frame Relay, etc.

Application encryption
For application encryption, specific applications provide the encryption end points securing traffic. E-mail is one application example that uses encryption technology today. End-to-end encryption tunnels are built from e-mail clients to e-mail servers. The end points negotiate security parameters, authenticate each other and exchange keying material. Traffic flows in a secure manner.

Database applications are also employing encryption to secure traffic on the disk or to secure specific data fields in a database. These technologies require encryption key storage and archival, offering the capacity to secure traffic at rest, but still may be open to attacks when data is in motion.

Specificity enables application encryption to be very granular in its implementation, securing specific data fields, e-mail addresses or any sensitive data. This has some real advantages if the security need is application specific such as a company that only needs to encrypt a CEO's e-mail or one Social Security number on a database. There are, however, some real tradeoffs. As the use of encryption technology grows, the specificity of application encryption becomes impossible to administer and implement on a large scale. So, if e-mail security is all that is required then this is a great solution. With regulations driving the use of encryption on a large scale, applying application encryption to all applications would be a huge obstacle to overcome.

TLS/SSL
So, if it is very difficult to encrypt data in motion for all applications, is there a subset of applications that use a common communications platform so that encryption technology can be applied in a more general way? Enter TLS/SSL.

Transport Layer Security (TLS)/Secure Sockets Layer (SSL) is implemented between the application layer and the transport layer. Using TCP for reliable delivery, TLS/SSL primarily secures Web-based applications, although any TCP application can be secured. Figure 2 shows the positioning of TLS/SSL.

As the use of SSL continues to grow there is a need to expand its use to other than Web-based applications. Some vendors have developed SSL gateways that are basically conversion tools to convert a browser based session to another application. In order to expand the use to other applications, SSL VPN providers are delivering client software that converts SSL to operate at the IP/Network layer. This enables security for a broader set of applications--especially important for non-TCP based applications such as VoIP that is UDP based.

However, with its placement above the transport layer, TLS/SSL requires either all applications to be "Webified" (either through protocol conversion or application change) or clients to be loaded on each end-station. Webifying all applications can be very costly. In addition, SSL technology was designed for end-client security. Many of today's needs are from remote branch to data center, data center to remote backup facility, secure communication over MPLS or Metro Ethernet. As the need to protect all data grows, protecting this traffic requires a more global approach to security and can not be solved by client to server browser-based encryption solutions.

Is there an encryption technology that can secure all applications over any network architecture?

IPSec
IPsec (IETF RFC 2401--2409) is a standard defined to secure selected traffic over an IP network. Figure 3 highlights its placement in the application stack.

The stack placement enables IPsec to secure all IP traffic, Web, non-Web, VoIP, FTP or Telnet. IPsec is well understood and provides for confidentiality (encryption), source authentication, data integrity, and anti-replay. Today, IPsec is used for remote access client access and site-to-site communication.

IPSec has advantages over the other approaches:

• IPSec can be implemented either on the client or in a gateway appliance or router. As a gateway, IPSec can be used to secure many clients with a single policy and a single set of encryption keys.
• Users can be grouped by IP addresses or Transport layer port number enabling security on a specific IP stream or specific application without any workstation impact or change.
• IPSec can secure all IP traffic, whether it is FTP, Telnet, IPTV or VoIP.
• IPSec enables a full set of security services and functions as a stateless firewall enabling or denying access to secure resources.

IPsec also comes with disadvantages:

• Network-wide IPsec implementations tend to be complex to configure and manage.
• IPsec requires client software for remote access environments.

Link layer encryption
Link layer encryption is applied to protect specific network segments. These segments could be frame relay DLCIs, DWDM wavelengths, or Ethernet segments. Link layer encryption secures all traffic and can be used in cases where traffic is not IP.

The advantages of link-layer encryption are based on ease of implementation. Everything is encrypted between two end points and usually no security policy definition is required. Link layer encryption is perfect for point-to-point applications with no IP/Network layer instance.

Therein lies the problem of link-layer encryption. Over IP networks, to implement link-layer encryption, encryptors (or encryption) would be required between each network layer device. A new draft standard IEEE 802.1AE has been defined to implement link-layer encryption between communicating devices over any link segment. In this approach, each link segment would encrypt and decrypt traffic using separate keys for each secure link operation.

The solution?
As regulations push enterprises to rethink security strategy, and securing traffic in motion becomes a requirement, multiple encryption methods will be implemented to satisfy specific encryption standards. However, a new model is necessary to implement and manage a cohesive security strategy.

First and foremost, security policy must be consolidated to one entity. Today, security policy is split between all the technologies providing security services: firewalls; IDS/IPS; data protection; and, identity management. For data protection, common security policy should be in place to implement encryption whether application, SSL or IPSec. A common policy platform would enable a global set of rules such as resource entitlement (access based on groups of users, applications, or devices and implementation specifics).

Secondly, for data protection, key negotiation and exchange can not limit network or application services. Encryption implementation today requires two end points to authenticate each other and exchange keying material. This sets up a point-to-point communications tunnel between the end points. As the need for data protection implementation grows the scalability of this approach is questionable. Imagine point-to-point tunnels to hundreds, if not thousands, of end points. Point-to-point key management is extremely difficult at best, and impossible in large mesh networks tying together thousands of end users.

The security model must separate key management from the end point devices. Key management should: leverage policy rules to enable grouping of end points, storing and archiving keys; generate and distribute keys to end points; and, provide the security policy interface to the end points.

Third, we need to start looking at security end points as any device or application (PDA, cell phone, software, router or switch). As we move to a security model where all end points are security enforcement points, the model needs to accommodate any type of device or software and reduce complexity as much as possible.

This security model would appear as:

The model leverages a common policy of separate encryption key management, thus improving data protection. New technologies and an improved enterprise data protection architecture are necessary to provide this model of data protection.

About the Author
Rod Starrett has over 30 years experience in data networking and security in technical, marketing and sales roles. Prior to joining CipherOptics, he helped develop Cisco's Internet content strategy for service providers and led the delivery of Cisco's first content offerings. In earlier product management roles at Cisco, Mr. Starrett was responsible for product strategy and development of IBM SNA/IP migration solutions. Prior to Cisco, Mr. Starrett was the Director of Sales at Netlink Inc. where he led an international sales team, including technical sales and business development. Prior to Netlink, he held a number of product development and engineering management roles in startups in the Raleigh, NC area. He can be reached at: [email protected]

See recent related articles by Rod Starrett at Network Systems DesignLine:

Protect critical customer data in 15 minutes

How to protect data in an IP world

Terms of Service | Privacy Statement | Copyright © 2024 UBM Tech, All rights reserved.