The rise of the Internet created a new chapter in human civilization. People are no longer tied to static information sources such as libraries. The seemingly exponential growth of people looking to access wide varieties of content also spurred the desire for mobility. If a person can search for information residing halfway around the world from home, why not be able to do the same from the local coffee shop or while sitting at an airport during a business trip? This information revolution offered an opportunity to provide information and services to consumers, businesses, and employees at virtually any point on the globe.

32.1.1 Borders Dissolving.

Prolific Internet access redefined the dynamics of network and perimeter protections. Previously, companies needed to focus on protecting the internal network as well as systems exposed to the Internet. A perimeter firewall was sufficient to keep the digital predators at bay. The greater challenge then became how to maintain the security of the internal network when employees use mobile technologies from home or while traveling. Further complicating the issue is how to allow other business partners to access the systems and information that require protection.

Organizations large and small can no longer expect to maintain a competitive ad-vantage by restricting employee network and information access to the confines of the workplace. The days of lost productivity due to these restrictions are long over. Traveling employees can now maintain direct communications with those at the office. Employees stranded at home due to inclement weather can continue to function, with access to necessary information. Organizations now have a viable way to maintain a geographically diverse workforce that allows people to work in closer proximity to customers and partners.

As an organization's network of vendors, suppliers, and partners grows, so does the necessity to share information. No matter the specific reason, the organization must look for methods that allow these outside entities the ability to access relevant information without exposing nonrelevant information. Information sharing is not the limit of partner involvement. Businesses may have situations where in-house staff does not have the necessary experience to develop or support certain information systems. Although having a consultant on staff or on call may be cost prohibitive, the company may opt to allow a vendor to access specific parts of the internal network remotely, to provide the necessary levels of service.

Customers continue to demand increasing levels of convenience. The banking industry is a useful example of how consumer demands increase and how business responds to meet these needs. Instead of having to go to a local bank, the ability to conduct certain inquiries and transactions were possible over the telephone. The limitations of this technology demanded an even greater opportunity, provided by account access and banking services through the Internet. Now the consumer has a visual, point-and-click interface instead of computerized voice and numeric menus. The same convenience requirements are present in the sale of goods and services. Consumers may not want to go to the local mall to make purchases, but by having an online presence, a company can meet this demand by providing an e-commerce Web site that gives the consumer the ability to view and purchase items at the consumer's time and place of choosing.

32.1.2 Secure Remote Access.

While the implications of not meeting consumer demands are obvious, organizations conduct a great deal of planning and review to ensure that meeting these demands does not jeopardize the underlying safety of the information systems that drive the business. The two primary technologies leading to secure remote access are the virtual private network (VPN) and the extranet.

A virtual private network is a secured connection allowing a client the ability to access the internal network through an encrypted tunnel. VPNs also have the ability to extend all or only selected portions of the network to other locations in the organization. Each has dramatic implications on information assurance requirements and goals.

An extranet meets some of the same goals as the VPN with the emphasis being information sharing and e-commerce. Instead of connecting to the internal network, the client establishes an encrypted connection to a web application server sitting on an external service network. Extranets can introduce additional complexity because the external-facing systems normally require access to one or more information assets within the internal network.

32.1.3 Virtual Private Networks.

The theory behind a VPN seems simple: Create an encrypted tunnel into the internal network to protect the transmitted data. In reality, the concepts underlying VPN technologies are complex and require a great deal of planning to ensure the best possible implementation. VPNs normally fall into two categories: secure client VPNs and trusted VPNs. Each VPN type has multiple avenues of implementation, with each having unique requirements.

Allowing people to access internal network resources remotely has major information assurance implications. The main information assurance goals of VPNs are securely extending the internal network, protecting data during transmission, and minimizing the security impact of the process.

The days of focusing on protection at the network perimeter are over and have been for longer than people may realize. Laptops led the initial mobile force charge. Although access to the full processing power of the laptop is useful in some instances, even the lightweight versions are bulky to travel with and have relatively limited battery life. Personal digital assistants (PDAs) and smart phones, fitting in the palm of a hand, now provide the power to access more commonly used applications. These devices may also have the ability to establish a VPN tunnel. No matter the type of mobile device, the organization must meet the requirements for remote access while accomplishing the least amount of additional risk.

When properly architected, managed, monitored, and secured, the internal network can provide a relatively safe environment to transmit data. However, the Internet is an openly hostile environment. The mobile device can no longer count on the internal network protections as a digital comfort zone. Internet access points, such as airports and hotels, can provide even greater challenges to information assurance. These public locations (many configured for open access) create sites for malicious individuals to intercept network traffic with the hopes of gathering information, such as financial information and intellectual property. VPNs and extranets have the ability to thwart this type of monitoring by sending data through encrypted channels.

As the need to increase stricter security measures continues, so does the potential to interfere with the end user experience. It does not take long for a user to figure out that disabling local security measures can have perceived advantages. Without the client firewall running, the connection speed may increase. Worse yet, by disabling another security protection measure, the user is now able to install and run software otherwise blocked from use. The goal must be to maintain a high level of security in a manner transparent to the user. The process of establishing a VPN tunnel or accessing internal resources should be fluid and perceptively uninhibited, while the background security infrastructure provides the necessary levels of protection.

32.1.4 VPN Technology Concepts.

Describing the multitude of conceptual intricacies of VPNs warrants many thousands of pages. This chapter provides only a foundation of information that will allow understanding of the different types, terminologies, and uses for VPNs.

32.2 SECURE CLIENT VPNs.

The most common use of a VPN is for secure, client-remote access. This allows an authorized remote user to connect to a VPN and gain access to internal resources while maintaining the security of the transmission. Secure client VPNs are waging an ongoing battle between traditional Internet Protocol Security (IPSec) and the increasingly popular and powerful Transport Level Security/Secure Sockets Layer (TLS/SSL) VPNs. Each type of VPN has certain distinct advantages, and each warrants thorough investigation prior to selecting the technology that best fits organizational needs.

32.2.1 IPSec.

IPSec is a suite of IP layer protocols, designed to set up and protect VPN transmissions. This traditional VPN implementation uses a client-resident application or embedded service to establish a VPN tunnel into the internal network.

32.2.1.1 Key Exchange and Management.

One of the most complex aspects of IPSec is key exchange and management. IPSec uses Internet Key Exchange (IKE) to facilitate the establishment and management of a Security Association (SA). The NIST “Guide to IPSEC VPNs” provides ample information regarding all aspects of IPSec VPNs; the next two paragraphs paraphrase the key points of IKE Phases 1 and 2 (NIST Special Publication 800-77).

Phase 1 can use main mode or aggressive mode to create the initial IKE Security Association. Main mode—consisting of three pairs of packets—is the most common implementation. The first pair negotiates the four-parameter protection suite: encryption algorithm (e.g., 3DES or AES), integrity protection algorithm (e.g., HMAC-SHA-1), authentication method (e.g., preshared key or PKI certificate), and Diffie-Hellman group. The second pair exchanges encryption keys using Diffie-Hellman. The third pair authenticates each side of the connection to the other. Aggressive mode accomplishes the same task by using only three packets. According to NIST Special Publication 800-77: “The first two messages negotiate the IKE SA parameters and perform a key exchange; the second and third messages authenticate the endpoints to each other.”

Phase 2 uses quick mode to establish the IPSec SAs. Each side of the connection will maintain an IPSec SA in its Security Association Database (SAD). The initiating device creates and sends its SA proposal to the VPN device. The VPN device replies with its SA selection and another hash to authenticate the connection. The initiating device then replies with the hash it generates from the previous request. If the hash matches the challenge from the VPN device, the SA goes into the SAD and the connection proceeds.

32.2.1.2 Authentication Header versus Encapsulating Security Payload.

IPSec provides two security protocols for protecting encapsulated data. Authentication Header (AH) protects the integrity of the packet header and payload by using cryptographic hashing to ensure data do not change. Encapsulating Security Payload (ESP) is the more common implementation because it not only provides the integrity protection of AH but also protects the confidentiality by encrypting the entire original packet and creating a new IP header.

32.2.1.3 Transport versus Tunnel Mode.

AH and ESP can transmit data in either transport or tunnel mode. Transport mode preserves the original IP header information while providing payload integrity and confidentiality payload protection. Tunnel mode provides integrity and confidentiality protection for the IP header and payload. Since transport mode uses the original IP header information, this creates incompatibilities with Network Address Translation (NAT) because of TCP integrity checks. NAT causes the IP address of the packet to change during transit and, in turn, will cause the integrity check to fail. Thus, tunnel mode is the primary method for host-to-gateway and gateway-to-gateway VPN connections.

32.2.2 Transport Layer Security.

The Transport Layer Security (TLS) protocol provides a method for protecting client/server communications. One of the most identifiable implementations of TLS is Secure Sockets Layer (SSL), which provides the basis for the HTTPS protocol. Although this chapter uses “TLS” and “SSL” interchangeably, because many products support both, there are some differences. TLS is the next evolution of the Netscape-developed SSL because it is an open standards protocol supported by the Internet Engineering Task Force (IETF) (IETF—Transport Layer Security).

The implementation of TLS/SSL is much less complicated than IPSec. This method provides 128-bit encryption capabilities that already exist on virtually all Internet-connected systems. The host provides SSL-related parameters to negotiate a HTTPS connection with the server. The server then replies with the negotiated SSL-related parameters as well as its digital certificate. The client then uses the certificate to authenticate the server. If authentication is successful, the client and server establish the encryption keys used to protect the session and begin encrypted communications.

32.2.3 User Authentication Methods.

Before allowing unfettered access to internal resources, the client must authenticate to the VPN termination device. The simplest authentication method is the common user name and password combination. Some typical ways for validating user credentials are through RADIUS, LDAP, or Kerberos. To combat the ease of stealing or guessing user names and passwords, most vendors provide alternative or complementary authentication mechanisms. With an existing Public Key Infrastructure (PKI) this opens the possibility for using dual-factor authentication by requiring a user or machine PKI certificate. (See Chapter 37 of this Handbook for more information on PKI.) Another multifactor option is to use a cryptographic token such as an RSA SecurID or smartcard.

32.2.4 Infrastructure Requirements.

As described in Chapter 26, VPN networks are an opportunity to use the service network principle. Since the VPN connection device must be Internet facing, the service network principle would call for two different networks connected to the firewall. The external, Internet-facing interface would contain inbound and outbound encrypted traffic only. The second network is for unencrypted traffic moving to and from the internal network. By using this principle, the firewall policy would restrict the external, inbound connections to the VPN connection device using only the few required protocols. The firewall policy would restrict all external connections to the unencrypted network while allowing the appropriate level of access into the internal network. This unencrypted network would also provide a security inspection point.

32.2.5 Network Access Requirements.

IPSec and TLS/SSL Secure Client VPNs provide avenues for secure remote access, but each has unique challenges and opportunities.

32.2.5.1 IPSec.

IPSec VPNs typically provide full network-level access to the internal network upon successful connection and authentication. However, it is possible to restrict access to internal hosts and networks through a RADIUS, VPN connection device, and a firewall policy. One consideration that affects client traffic is split tunneling. With split tunneling enabled, only traffic destined for the internal network flows through the encrypted tunnel. As such, network traffic bound for the Internet takes the most direct route instead of traveling through the tunnel. This can help to reduce bandwidth by not having nonessential traffic flowing through the tunnel. However, the main disadvantage to this is losing the ability to inspect the Internet-bound network traffic.

32.2.5.2 TLS/SSL.

The original implementation of TLS/SSL VPN was far from its IPSec predecessor. These early connections focused on network pass-throughs to specific hosts and protocols as well as a crude, difficult-to-configure dashboard of simple links to internal files shares and Web sites. The dashboard concept for remote access is unique to the TLS/SSL VPN. The current dashboards are more robust and flexible, allowing the administrator to feed specific content and network access depending on a user's classification. The true breakthrough for TLS/SSL VPNs was its match of IPSec's ability to allow full network access, without the necessity for a client-resident VPN application.

32.3 TRUSTED VPNs.

VPNs are not purely for client remote access. Trusted VPNs provide the ability to facilitate internal communications needs. VPN technologies exist that can create meshed, virtual WAN networks, while providing alternatives to traditional WAN implementations.

32.3.1 Multiprotocol Layer Switching.

The increasingly popular multiprotocol layer switching (MPLS) is not a traditional encrypted VPN, but it does provide a similar type of service. This section will not cover most MPLS intricacies because deployment must meet organizational requirements, and because each service provider has different offerings. However, MPLS does have several distinct, advantageous characteristics.

32.3.1.1 Purpose.

A typical WAN environment exists in a star, a hub-and-spoke, a point-to-point topology, or some combination. Instead of hosting the head-end of the WAN network internally, MPLS creates a meshed, routed virtual network at the service provider level. The MPLS network is then free to route packets directly from one WAN endpoint to another within the confines of its virtual network. WAN sites are able to communicate directly, eliminating the hub as a single point of failure. MPLS networks may also provide multiple levels of quality of service (QoS). QoS provides the ability to prioritize network traffic, allowing certain protocols more bandwidth during high utilization periods.

32.3.1.2 Requirements.

As with all WAN routing technologies, the routing hardware and software must support the necessary routing and/or MPLS protocols. In addition, the service provider must already have the technology available. Moving to MPLS may require a significant rearchitecture of the existing routing infrastructure.

32.3.2 Site-to-Site VPNs.

Another common use of an IPSec VPN is for intersite communications through the Internet.

32.3.2.1 Purpose.

Although geographic diversity allows the organization closer proximity to customers and materials, traditional WAN implementations may not be available or practical. Site-to-site (S2S) VPNs provide an avenue for bridging this gap.

32.3.2.2 Alternative WAN.

WAN connections, as with most other technologies, are not cheap. It can be cost prohibitive to run a WAN connection (e.g., Frame Relay, T1, etc.) into a leased office space. In addition, even a lower-bandwidth leased line may be overpriced and underpowered to provide a direct WAN connection to a small branch office. A S2S VPN may provide the necessary level of connectivity without the high cost of a leased line. Since the S2S VPN will travel over an Internet connection, it may be possible to provide a higher bandwidth for the price.

32.3.2.3 Backup.

An S2S VPN is also an alternative means for WAN backup. The traditional ISDN backup lines have two main disadvantages. ISDN service providers normally charge based on the number of connections and the duration of the call, as well as requiring separate hardware. In addition, ISDN bandwidth is normally limited to 128 Kbps. This may be insufficient if the site requires heavy access to systems and information across the WAN. S2S provides a means for higher bandwidth using existing hardware. The S2S connection provides additional redundancy by providing a standby, routable link. If architected properly, the site should notice little to no outage if the primary WAN link fails.

32.3.2.4 Requirements.

S2S VPNs require an Internet connection as well as VPN and encryption enabled endpoints. A typical S2S deployment could be between two routers. Some other potential deployments include a router and a VPN-enabled gateway security device (GSD), or GSD to GSD.

32.3.3 Information Assurance Considerations.

Although the ability for people and remote sites to connect to internal resources provides mobility and increased productivity, the organization cannot lose sight of the fact that this creates many information assurance caveats. Each implementation will have its own unique requirements, but addressing the main concerns presented in the next sections can make for a more informed decision.

32.3.3.1 Client-Secure VPN Considerations.

Hosts connecting through client-secure VPNs are at greater risk due to the uncertainty of the network the end user system will be using to connect. All uncontrolled networks deserve to be treated as insecure, thus hostile, computing environments. This understanding will require the security administrators to focus on the necessary precautions to protect all of the company's systems.

32.3.3.2 Fidelity of the Mobile Device.

Since there is no absolute control when mobile systems leave the confines of the internal network, the fidelity of the mobile device is of concern. The risk of compromise at every level—from physical, to operating system, to applications and beyond—can expose the internal network during a VPN session.

There are several ways to reduce the likelihood of a loss of fidelity. Protections may include any combination of host firewall, antivirus, antimalware, intrusion prevention, and current patch levels. Proper deployment and configuration of these protection measures will help to reduce the possibility of compromise.

Even if the fidelity of the device is acceptable during the initial connection, that does not mean this status cannot change at a later time during the connection. Another more complicated means for ensuring the health of the device is through network access control (NAC). NAC provides the ability to interrogate a connecting device before and during the connection, to determine such information as patch levels, status of security protections, and memory-resident malware. Unfortunately, the NAC option is not just a plug-and-play proposition. There are many other implications and requirements—such as inline versus passive and client-based versus client-less solutions—associated with effectively deploying NAC at any point in the network.

32.3.3.3 VPN Client Management.

Client administration plays a crucial role in the success of a VPN solution.

IPSec requires the use of a client-side application or embedded operating system mechanism such as the Windows Network Connection Wizard. The primary implications of this include configuring and maintaining the client. The intricacies surrounding a hard-client installation include the necessity of local administrative permissions, potential user interaction, and dealing with a corrupt VPN client application. As with all other applications, there will come a time when the client will require updates due to new enhancements, unsupported versions, and vulnerabilities. In keeping with the goal of minimizing negative user experience, administrators need a way to update client software with little to no user interaction or side effects. One primary question is to determine if the VPN vendor has a mechanism to push configuration and other client software updates upon connection. Without this functionality, it becomes more difficult to change client-side parameters. For example, a VPN using a preshared key for VPN authentication gets hard-coded into the VPN software. This makes changing it difficult without having the end user enter a new key.

TLS/SSL VPN clients do not suffer from the same pitfalls as IPSec regarding client management. Instead of a hard client, the TLS/SSL VPN normally uses a small Java or ActiveX-based dynamic client. In certain VPN systems, the administrator may have the choice to leave the dynamic client resident or remove it upon disconnection. If the client becomes corrupted, the user can delete the control, and it will automatically download upon the next successful connection. Having the dynamic client remain resident has two advantages. First, it may provide the ability to have a local, encrypted workspace to store working documents and other files or to provide access to other resources. Second, it keeps the remote system from having to download the client with each connection. The TLS/SSL client also has an advantage by always checking to see if a resident client is current. If not, the VPN system will force a download of the newest client, helping to minimize client-side management.

32.3.3.4 Protection of the VPN Device.

The heart of being able to provide VPN services revolves around the existing network security infrastructure. This has direct implications regarding perimeter protection, since the VPN connection devices must be Internet and internal facing. These devices must also follow the service network principle discussed in Chapter 26 of this Handbook. The device itself is another part of the overall network security profile.

It is important to remove all ancillary exposures. The primary protection method is to configure the firewall to allow access only to the necessary ports on the VPN device. All unnecessary protocols, services, and configuration options should be shut down. If DES and MD5 are unacceptable cryptographic protocols in the environment, these and all other weaker alternatives must be removed from the negotiable IKE options. If a network management tool uses ICMP and/or SNMP to monitor the VPN device, firewall rules or onboard access control lists (ACLs) should only allow access to these protocols from a specific set of monitoring hosts. Although network reconnaissance and attacks are still possible on these ports, this method drastically reduces the attack profile.

Administrative device access should never use insecure protocols such as Telnet, FTP, or HTTP. Instead, administration should occur using encrypted protocols, such as Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS). Administrative access should at a minimum be protected with a strong user name and passwords or, better yet, require certificate-based protection. To minimize administrative access, only a specific network or host(s) should be able to access the administrative console directly. To reduce administrative exposures further, it may be possible to use a proxy device for all administrative access. This does carry the potential for a single point of administrative failure if the physical device is not available.

32.3.3.5 Traffic Inspection.

Inspection of network traffic plays a crucial role in keeping the internal network secure. Since the goal of the VPN is to provide secure data transport, this can be a hindrance when attempting to evaluate inbound, encrypted traffic. Network traffic inspection can occur on the VPN connection device or on the unencrypted side leading to the internal network. While the network traffic is one step closer to the internal network, this provides a valid inspection point in which to detect and protect against malicious traffic. Certain VPN devices and GSDs may provide the ability to view data inside the tunnel, evaluate network traffic (providing a troubleshooting point), and inspect data before passing onto the unencrypted network. However, doing all of the inspection on the VPN device can have significant performance implications.

32.3.3.6 Processing Power.

Encryption and decryption of VPN tunnels requires sufficient processing power. This issue escalates as the number of clients increases. For situations where there are only a few remote-access clients, it may be possible to use a GSD to terminate VPN connections and provide security services. The higher the number of remote-access clients, the greater the need for dedicated VPN devices. To ease the processing demands on these units, it is possible to install hardware encryption accelerators. Larger organizations may have thousands of concurrent users that could require multiple VPN devices.

32.3.3.7 Trusted VPN Considerations

32.3.3.7.1 Infrastructure Design.

MPLS can be a wholesale change in how the WAN functions; it also has troubleshooting and security implications.

Since an MPLS network can provide any-to-any functionality, it becomes more difficult to troubleshoot network issues. In a hub-and-spoke configuration, it is possible to deploy probes to monitor and troubleshoot WAN issues. It is unlikely that organizations with many locations would invest the time and money to deploy these types of monitors in all locations. The service provider may be able to provide additional services that assist with this type of troubleshooting.

MPLS networks also add to the overall network security burden by requiring an increase in the number of network security devices. This is largely because the sites can establish direct communications instead of going to the hub first. MPLS places the security of the WAN infrastructure in the service provider's hands. This is a reminder to ensure the MPLS provider has a robust network and strict processes for keeping MPLS networks separate. One added protection against provider-side errors would be to deploy the Border Gateway Protocol (BGP) routing security, where both sides of the connection would authenticate before becoming part of the routing table.

S2S VPNs carry additional risk by placing the Internet directly against the internal network at remote sites. If the Internet connects directly to the site's router, there are several protection options. It is possible to create an access control list (ACL) to restrict communication to this interface only to the other side of the S2S VPN connection. Another option is to enable security features on the router. However, this may require a code upgrade and may increase processing demands on the router. A more secure but expensive option is to deploy a GSD that provides security and VPN services. This puts another level of protection between the Internet and the internal network.

32.3.3.7.2 Cost.

MPLS adds cost on many fronts. These include the cost of new or converted circuits and other services, such as quality of service (QoS), or monitoring capabilities. In addition, the equipment running the network must be able to support the new MPLS and routing architecture. There also may be a significant time investment required to redesign the network routing infrastructure.

S2S VPNs using routing devices require ample processing power (e.g., RAM and encryption modules) and a software revision that supports encryption. In certain cases, it may cost more to get to a level of code supporting encryption. S2S VPN deployments using GSDs will go up in price as the number of security services increase and based on the number of clients that will connect. If deploying GSDs to remote sites, there is not only a monetary cost, but also higher administrative costs for managing this new piece of the routing and security infrastructure.

32.3.3.7.3 Availability.

VPNs are less of a convenience and more of a necessity. There can be disastrous implications for highly mobile workforces when VPN access is unavailable. Even with layers, points of failure do not disappear. If the organization deems VPN as a necessity, high-availability solutions are a requirement. One such solution is to load-balance inbound connections to distribute them across multiple devices. If one device fails, the other devices will continue to service previously connected clients and will provide a place for new clients to connect. Another option is active/standby failover. This may be as simple as if one device fails, the other will be available for new connections. A preferable method would be for the active member to replicate connection information to the standby member. This way, if the active member fails, the standby member can continue servicing the existing VPN tunnels and can provide new connections. This whole strategy also hinges on the main VPN connection points having redundant Internet links, power, and network infrastructure.

32.3.3.7.4 Implications of Illusive VPNs.

Unfortunately, VPNs occur in more places than most people realize. These illusive VPNs range from legitimate VPN services, such as GotoMyPC, to malicious VPNs, such as botnet command-and-control channels or reverse tunnels. Although VPN sites such as GoToMyPC can be useful, it is up to the organization to decide if this is an acceptable means of remote access. Some of the key issues to consider with this type of VPN service are that it bypasses internal security controls such as packet and content inspection, and the third party is creating and managing the VPN connection.

Malicious VPNs are a source of continuing concern. Botnet command-and-control channels can use encryption to evade network defenses and protect information. A reverse tunnel works by redirecting network traffic destined for a listening port to the same port on another host. For example, if a compromised FTP server had an active reverse tunnel, any user attempting to connect to that FTP server would redirect to another FTP server. Beyond the compromised host theory, malicious people already on the internal network may establish an outgoing VPN connection or a legitimate VPN in an effort to hide insidious behavior or network traffic.

The most elusive of all are applications that provide embedded VPN-like services. Peer-to-peer (P2P) networks tunnel file sharing through proprietary and encrypted protocols. Skype not only has the ability to create encrypted voice calls, but also has VPN-like capabilities that allow encrypted file transfers. Network defenses should be able to detect the setup of these sessions and stop them before the connection is completed.

It is up to the organization to develop the internal network security defenses and policies to protect against all elusive VPNs.

32.3.3.7.5 Impact of IPv6.

Mass migration to IPv6 is still not occurring at the time of writing (2008) even though IPv6 was developed in the late 1990s. The Department of Defense (DoD) is requiring all of its networks to be IPv6 compliant by the end of 2008. Discussion of whether to use IPv6 is beyond the scope of this chapter. However, IPv6 does have some specific implications for VPNs. First, all devices must be able to support the IPv6 protocol. Second, if the entire infrastructure is not IPv6 end to end, devices will need to be able to translate IPv6 traffic into IPv4 and vice versa. Last, IPv6 provides native support for IPSec. The network stack will be able to provide per-packet encryption, potentially eliminating the need for hard clients.

32.4 EXTRANETS.

As the necessity for convenient access to data continues to increase, so do the challenges associated with providing the protections required to secure this type of access.

32.4.1 Information Assurance Goals.

Allowing external entities to access internal data remotely has major information assurance implications. The main information assurance goals of extranets are protecting shared information assets, preventing information exposure, and minimizing ancillary risks.

32.4.1.1 Protecting Shared Information Assets.

Much of the current in-formation security market focuses on protecting hosts and networks from digital threats. Although the loss of a server or portion of the network undoubtedly causes issues, there may be areas of greater concern. Organizations develop and sustain competitive advantage by manipulating data collected or created into valuable and actionable information. By mitigating the risks associated with external access, there is less chance for a breach of information security to occur.

32.4.1.2 Preventing Information Exposure.

The concept of least privilege should be paramount in designing access to systems. One would not expect a financial analyst to have access to proprietary product specifications. The same holds true when apportioning access to external entities. Identity management provides an accountability mechanism for providing rights and monitoring actions of issued accounts. Access management provides the enforcement mechanism that keeps those accounts from viewing or changing data not explicitly necessary. The fusion of these two principles reduces the risk of inappropriate or unexpected access.

32.4.1.3 Minimize Ancillary Risks.

It does not take long for Internet-facing systems to come under attack. Minimizing attack vectors occurs from the network layer to the application layer. The extranet servers are not all-purpose systems. The network protection policies should restrict access to these services, so that the Internet community only has access to the specific service(s) advertised. Extranet services require greater consideration, as network protection devices are rarely suitable for the protocols and customizations routinely occurring at the application layer.

32.4.2 Extranet Concepts

32.4.2.1 Service Network versus DMZ.

The DMZ architecture places systems on a network between the external router and the external interface of the perimeter firewall. The external router provides packet filtering to reduce access to the DMZ network and hosts, but lacks additional security capabilities. In essence, these systems are accessible from the Internet while not quite trusted to access the internal network. This is hardly a place to put servers requiring robust security at multiple layers.

As described in Chapter 26 in this Handbook, extranet networks are another opportunity to use the service network principle. This is largely because extranets make extensive use of resources on the internal network. Instead of residing in the DMZ, the servers move to a separate firewall interface. This segmentation allows administrators to be more granular on the services allowed into the network, as well as providing another place to put additional security mechanisms.

32.4.2.2 N-Tier Architecture.

If an extranet system provides all aspects of a service, there exists a single point of failure and compromise. N-tier architecture provides the ability to distribute different aspects of the service offering to additional systems. The extranet system will provide the front-end user interface, the application server facilitates the logic and processing necessary to access data, and the back-end database server stores and provides the data. Since the extranet server resides on a service network, the firewall policy must allow that server to connect to its next-tier servers on the internal network. When possible, access from the extranet server should be restricted to the internal network or to only necessary systems and services. This architecture helps to create a more robust infrastructure that reduces unnecessary exposures.

32.4.2.3 SSL Encryption.

The most visible marker of SSL encryption is the little golden padlock that appears in an Internet browser when connecting to a server using HTTPS. When a host attempts to connect to an extranet server, several steps occur before the encrypted session can begin. The connecting host provides SSL-related parameters to negotiate an HTTPS connection with the server. The server then replies with the negotiated SSL-related parameters and a digital certificate. The client then uses the certificate to authenticate the server. If authentication is successful, client and server establish the encryption keys used to protect the session and begin encrypted communications.

32.4.3 Types of Extranet Access.

The type of systems and services able to go onto the extranet continues to grow. Providing extranet services is always subject to the needs of the organization. The next sections provide some common examples of extranet systems.

32.4.3.1 Vendor/Partner Information Sharing.

Business is no longer just about the deal and a handshake. Businesses survive and thrive on competitive advantage, and increasingly need to share information with strategic partners. By providing access to internal information, these partners can better understand and meet the organizational needs. Enterprise resource planning (ERP) systems contain the data that serves as the digital lifeblood of an organization. On the extranet, vendors and business partners could have access to work with information stored in the ERP system.

32.4.3.2 E-Commerce.

Conducting business transactions digitally can create efficiencies and reduce costs. E-commerce occurs at the business and consumer level. Businesses can use Electronic Data Interchange (EDI), which allows two entities to exchange standardized, digital versions of documents, such as a purchase order and payments, without human interaction. The extranet provides a means to allow business partners to exchange EDI data without granting access to the internal servers that actually process and store data. Consumers access e-commerce Web sites to view and purchase goods and services.

32.4.3.3 Employee Self-Service.

Providing extranet services is not restricted to business partners and consumers. It is possible to enhance employees' access to specific internal services and systems by allowing access without requiring a full VPN connection. E-mail is the universal business tool, and providing webmail services can allow employees to access e-mail from almost anywhere in the world. Employees may find it helpful to be able to access and change benefits information from home. This may also be an opportunity to allow access to Intranet information.

32.4.4 Information Assurance Considerations

32.4.4.1 Technical Security.

Securing an extranet is not possible at a single layer or point in the network. Each layer is interdependent and requires specific protections to ensure the security of the extranet network.

32.4.4.2 Infrastructure.

Since the extranet sits behind a firewall, network layer security measures are normally the protections encountered first.

32.4.4.3 Traffic Inspection.

As reiterated in multiple parts of this and other chapters, security devices have a distinct inability to evaluate encrypted network traffic. Extranets can create additional issues as the encrypted session travels from the client directly to the extranet server. This potentially requires traffic inspection to occur on the extranet server. While possible, this method will increase the processing requirements of the server.

Another option is to terminate the SSL connections on an upstream device. This device would then use unencrypted protocols on the downstream side when communicating with the actual extranet server. This method adds an additional layer of complexity when troubleshooting, but it can relieve the extranet server of the encryption and security inspection processing burdens.

32.4.4.4 Internal Network Exposure.

Although the compromise of an extranet server is significant, it should not be a pass to unfettered access to internal resources. The firewall policy allows access to specific extranet services from the Internet; it must also granularly restrict access from the extranet server to internal systems.

32.4.4.5 Server.

Server-level protections are the true first line of defense. It is difficult for network layer security mechanisms to protect a server that is advertising a vulnerable service. System hardening is an approach to reducing the overall risk profile of the server. Nonessential protocols and services are shut down. The operating system (OS) may have additional parameters, such as file and account permissions, that further reduce the risk profile. A script can help to ensure these changes occur in a consistent manner. One well-known system-hardening script is Bastille Linux.

Due to the complexities of operating systems and applications, vulnerabilities will occur. The simplest method of remediating vulnerabilities is to update the server with a patch. It is important to test patches for adverse effects before deployment to the production environment. This practice will help to reduce the potential for unexpected results and downtime. Vendors can take weeks and months to develop and release a patch. In certain cases, third-party patches will become available for unpatched, actively exploited vulnerabilities. The ability to use these patches is an option, but it is inadvisable due to the inability to verify the integrity and safety of third-party patch code.

Even though the goal is to minimize the risk profile of the server through all of the aforementioned means, it may also be necessary to provide additional server-level protections. This may include firewall and intrusion detection and prevention software. These protections have the advantage of being contextually aware of operating systems and application functions, unlike those residing at the network layer.

Virtualization is developing rapidly and becoming a viable option for use on the extranet. Virtualization does hold promise for allowing multiple extranet systems to run on a single server, but there are many other security implications. This is another case of a single point of failure if the physical server goes down. There are ongoing concerns of escaping virtual sessions and allowing unauthorized access to another virtual session.

32.4.4.6 Application.

Some common application layer vulnerabilities include buffer overflows, Structured Query Language (SQL) injection, and cross-site scripting (XSS). Buffer overflows existed decades ago but continue to be a favorite of malicious code developers. This condition exists because the application does not do proper bounds checking on input fields or uses functions that fail to do the same. SQL injection is a malicious attempt to insert a SQL query into server-side requests. By failing to check for and protect against this type of attack, the back-end server may return the information the malicious query requests. XSS is a type of code injection commonly used for phishing. A malicious person may send an unsuspecting person a link that redirects some or all content elsewhere.

Vulnerabilities at the application layer can easily defeat even the most secure network layer configurations. Applications developed by multibillion-dollar organizations can be just as vulnerable as something developed internally in a small facility. Developers must understand and follow secure coding practices to help minimize the number and severity of application vulnerabilities. See Chapters 38, 39, and 52 in this Handbook for discussions of programming and application security, and Chapters 25 and 33 for Web-based and wireless network security.

32.4.4.7 Policies.

Since extranets provide external entities access to internal information and systems, it would be useful to have a policy that governs the use of these systems. The policy may include information about requirements, such as needing a confidentiality agreement before allowing a business partner access to the extranet or mandating the use of TLS/SSL encryption for all extranet communications. Policies do not provide an active protection mechanism but do establish expectations when using extranet systems.

32.4.4.8 Access and Identity Management.

Access management is crucial to ensuring that only necessary and relevant information gets to the requesting user. The permissions given to this user will dictate the data the user is able to access and should follow the concept of least privilege. Identity management facilitates must ensure that only properly credentialed entities can gain access to the extranet and underlying systems. Typically, an external user will authenticate using a user name and password. Unfortunately, this is a poor way to validate an entity's identity because of the ease of stealing or guessing passwords. A more reliable method for identifying an external entity would be to issue the user a digital certificate. The certificate would then become a part of the connection and authentication process. Although it is not impossible, it is vastly more difficult to spoof or steal a digital certificate. Chapter 28 in this Handbook contains detailed information about identification and authentication.

32.4.4.9 Availability.

Extranet systems are an important part of business operations. When extranet access is unavailable, certain transactions do not occur that can cause issues at points throughout the organization. Extranet availability is a function of the network and server infrastructures.

A single Internet connection has an implied single point of failure if that connection goes down. If the network infrastructure leading to the extranet only has a single path to follow, this becomes another single point of failure. By adding redundancy to the network infrastructure, such as a second Internet connection and secondary routing paths, there is less likelihood of downtime.

Server infrastructures have the same potential to be a single point of failure. Instead, using a single server to provide an extranet service, it is possible to deploy a cluster of servers and load balancing. The cluster will protect the availability of the service if one or more servers goes down. In addition, this provides the ability to perform server maintenance with little to no effect on availability. Load balancing helps to optimize the number of connections going to each cluster member.

32.4.4.10 Impact of IPv6.

The largest impact of IPv6 on the extranet is infrastructure and application support. First, the routing infrastructure must be able to communicate using IPv6 natively or though a translation mechanism. Second, operating systems and applications must be able to accept, process, and reply to the IPv6 packets. Last, the security infrastructure must be able to evaluate IPv6 packets. A breakdown in any one of these will render the extranet vulnerable or inaccessible.

32.5 CONCLUSION.

Virtual private networks and extranets have many powerful features that can enhance an organization's ability to conduct and improve employee mobility and business functionality. Support and input must come from all levels of the organization to ensure that the secure remote access systems meet the organization's specific needs and expectations. Most important, these systems must adhere to and enhance, not diminish, the overall security profile.

32.6 FURTHER READING

Carmouche, J. H. IPsec Virtual Private Network Fundamentals. Old Tappan, NJ: Cisco Press, 2006.

Edwards, J., R. Bramante, and A. Martin. Nortel Guide to VPN Routing for Security and VoIP. Hoboken, NJ: John Wiley & Sons, 2006.

Frankel, S., K. Kent, R. Lewkowski, A. D. Orebaugh, R. W. Ritchey, S. R. Sharma. “Guide to IPSEC VPNs,” NIST Special Publication 800-77, December 2005. Available: http://csrc.nist.gov/publications/nistpubs/800-77/sp800-77.pdf.

Tan, N.-K. Building VPNs: with IPSec and MPLS. Hightstown, NJ: McGraw-Hill, 2003.

Tibbs, R., and E. Oakes. Firewalls and VPNs: Principles and Practices. Upper Saddle River, NJ: Prentice-Hall, 2005.

..................Content has been hidden....................

You can't read the all page of ebook, please click here login for view all page.

Table of Contents for CHAPTER 32: VIRTUAL PRIVATE NETWORKS AND SECURE REMOTE ACCESS

Create new playlist

Sign In

Sign Up

CHAPTER 32

VIRTUAL PRIVATE NETWORKS AND SECURE REMOTE ACCESS

32.1 INTRODUCTION.