Chapter 9: Securing remote access

Remote access is no longer just about a laptop or home desktop user connecting to catch up on some work or update customer and order information. The explosion of consumer devices in the hands of our employees changes how we look at remote connectivity. In addition to supporting various platforms and proprietary operating systems, traditional security controls do not provide sufficient granularity for policy enforcement. This results in either lax security or inflexibility in how we deliver business services.

In this chapter, we look at remote access challenges faced by today's competitive organizations. Further, we explore new ways to deploy access controls for traditional remote connectivity methods like IPSec and SSL VPNs.

Challenges

As we saw in Chapter 6, employees (supported by the business) are increasingly demanding use of smartphones and tablets. Use of their own devices is fine with management when budgets can then target bigger revenue generation projects. Like wireless access, we are unable to just say no. In addition to consumer device connectivity, we increasingly receive requests to connect to cloud service provider networks or create more traditional business-to-business (B2B) connections to enhance productivity and reduce cost.

The expanding connectivity requirements are exceeding the ability of our traditional access and admission control technologies. For example, is the acceptable use policy the same for remote employee-owned tablets as it is for company-owned laptops? Should it be? How can we enforce different policies for different devices?

And it is not just device differences. Is acceptable use the same when the vice president of finance uses a smartphone to connect as it is for an accounts payable clerk with a tablet? So it is also about roles. Add location and processes/data access controls, and you run into capability walls with many older remote access and admission control solutions.

As we progress through the remaining chapter, we pursue safe implementation of remote access control objectives based on five security considerations:

• Device type. What device types require remote access? Is the device company- or employee-owned?
• Role. What role does each user play in the organization? What remote access is appropriate for that role given the device used?
• Location. Is access from a public location, another company site, internal wireless, etc.?
• Process and data. What processes and data are accessible given the first three access characteristics?
• Authentication method. Does the need for strong authentication increase based on the device used, where it is used, and what it is allowed to access?

Table 9-1 is an example of what an acceptable access matrix might look like. It does not include all possible combinations: just enough to demonstrate how it works. Note the difference in access as the same role moves from one device to another. This is known as context-based access control. It is not always easy to get to this point, but it is worth the trip. Once implemented, allowing the right access can be as simple as dropping a user into a remote access group; all the various access restrictions immediately apply.

Table 9-1: Context-based Access Control

Remote access architecture

Two architecture challenges face us. First, how do we segregate incoming traffic once it arrives at our network edge? Second, how do we connect over the Internet in a way that safeguards our data and introduces minimal solution management challenges? We answer these question with network segmentation and VPN, respectively.

Network segmentation

We looked at the details of VLAN network segmentation in Chapter 5. Creating security (trust) zones enables flexible and strong control of what a remote user can access. It not only simplifies context-based access control; it enables it.

Figure 9-1 depicts security zones separating incoming traffic from internal resources. Using dynamic VLAN assignments and access control lists, we can control user access based on the conditions listed in Table 1. Dynamic VLAN assignment uses group membership or other user characteristics. This allows remote access control solutions to use context-based policies to provide internal segment access (See Chapter 5.)

Figure 9- 1: VLAN Segmented Network

Remote access choices

Remote access is increasingly the preferred connectivity method for many business roles using various types of company- and employee-owned devices. So a remote access solution must be

• Flexible
• Secure
• Transparent to users
• Compatible with the anytime/anywhere resource access model
• Budget-friendly

These characteristics of a successful remote access implementation mean different things across various communication contexts: facility-to-facility (F2F), business-to-business (B2B), and individual-to-business (I2B). Three current solutions provide the flexibility to match implementation-specific requirements: T1/T3, IPSec VPN, and SSL VPN.

T1/T3

The T1 (1.544 Mbps), one of four T-carrier types, is historically the most popular solution for connecting businesses to the Internet, facilities, or other businesses. It consists of 24 (64 Kbps) channels a provider can provide in fractional increments to better match business need to bandwidth. In addition to Internet access, an organization can use T1 circuits to establish direct or cloud-switched B2B or F2F connections.

When an organization requires more bandwidth, it can bond multiple T1s to look like a single connection. For example, bonding two T1s results in bandwidth of about 3 Mbps. Another option is to implement a full or partial T3 circuit. A T3 is an aggregate of 28 T1s, providing bandwidth of 44.736 Mbps.

Figure 9-2 depicts a common secure configuration for T-carriers. The carrier (circuit provider) connects a circuit from one of its central offices to a demarcation point (demarc) in the subscriber's (organization leasing the circuit) data center. It is called a demarc because it is the point at which the provider hands off hardware responsibility to the subscriber's network engineers. It is the separation point between carrier and premise (subscriber) infrastructure.

Packets from the demarc pass through a router and on to the firewall standing guard at ingress to the appropriate, outward facing security zone. For example, traffic destined for the public website might travel to one security zone while employee access traffic flows to another. A security zone's ingress firewall provides initial filtering for incoming traffic. Packets making it into the security zone face access policies and VLAN access control lists controlling internal network access.

Figure 9- 2: T-carrier Connection

Traditional communication solutions

After reaching a provider, transport of traffic from the central office to a remote user or site can take one of three forms: point-to-point, multi-point, or remote access.

Point-to-point

Point-to-point connections are private pathways between two ends of a communication circuit; think of them as cables stretched between facilities. Unlike the other alternatives, only the entities on either end of the circuit use the provided infrastructure. This is a secure approach, but it can be expensive.

Consider the cost for an organization needing multiple B2B and many F2F communication paths. The monthly cost might run into six figures, depending on the distance between endpoints and the bandwidth required. Further, an additional T-carrier is needed for each path added. This limits flexibility, results in ever-increasing costs, and hinders quick reaction to changing business needs. (It can take weeks to install a new T-carrier.) One common use for point-to-point connections is permanent connectivity between endpoints in a wide area network (WAN), as shown in Figure 9-3.

Figure 9- 3: Point-to-Point Connection

Multi-point

Multi-point pathways use a shared, switched cloud with each location connecting to the switched network with a T-carrier. This significantly reduces the cost of multiple connections; the circuit lease costs are based on both a shorter distance between the subscriber and the carrier's central office and subscriber-sharing of the network.

In the past, carriers pushed frame relay as a multi-point solution, as shown in Figure 9-4. Frame relay is a public switched network. Multiple subscribers share the cloud infrastructure. Because of security concerns, encryption of frame relay traffic was becoming an important consideration. However, the growth of the Internet and its lower cost for WAN implementation is quickly relegating frame relay to communication museums.

A better choice for today's Internet-connected businesses with multiple communication pathway requirements is VPN, which we explore in detail later in this chapter.

Figure 9- 4: Frame Relay

Remote access

Remote access began with simple modem-to-modem connections to dedicated data lines, as shown in Figure 9-5. This was slow and would never meet the demands of today's mobile workforce. Using the Internet with high-speed connections is a better option and usually more secure.

Figure 9- 5: Traditional Modem Access

VPN

Virtual private networks (VPNs) enable establishment of secure pathways over otherwise insecure media. For example, the Internet is a very public, unsafe, switched network environment. However, by establishing a VPN connection between two points, it is almost as safe as a point-to-point connection. In most cases, the lower cost and increased flexibility more than makes up for the increase in risk.

Organizations use VPNs for all WAN, B2B, and remote user requirements, rapidly replacing frame relay and point-to-point T-carrier implementations. In addition, modems have not been used in most businesses in years as Web portals powered by encryption technology replaced modem pools. VPN provides many capabilities not available in simple HTTPS connections, causing a shift to VPN for company intranet connectivity.

VPN characteristics

VPN uses TLS (the SSL replacement) to establish a tunnel between two points, as shown in Figure 9-6. This example is missing typical components that enable granular control of incoming traffic, but it provides a high-level view of a tunnel over the Internet. The two devices establish a tunnel by using asymmetric encryption to first exchange a shared key. Once both endpoints have the key, symmetric encryption secures the session. As we saw in Chapter 7, symmetric encryption is faster than asymmetric encryption, but asymmetric encryption allows both devices safely to get the needed key.

Figure 9- 6: VPN Model

All data passing between the laptop and the VPN endpoint, also known as a VPN gateway, is exchanged over an encrypted connection. The laptop's connection can be any Internet service. The connection from the Internet to a large subscriber's data center VPN endpoint is usually a T-carrier. A cable modem works fine for SMBs with limited remote access requirements. Depending on the type of VPN and configurations of internal resources (including VLANs and ACLs), most if not all access available to an office worker is also available to a teleworker.

VPN gateways can be standalone or integrated into other network devices. For example, many firewalls include VPN endpoint capability. A server is also a VPN gateway candidate. Whatever you use, remember that the data is encrypted between endpoints. Endpoints decrypt traffic before passing it along to intra- or inter-security zone resources.

Two types of VPN implementations dominate today: IPSec and SSL. Each brings unique capabilities to secure remote connectivity design.

IPSec VPN

IPSec (IP Security) is a network layer protocol that encrypts all communication between two endpoints. Figure 9-7 depicts a gateway-to-gateway configuration between two networks: a common implementation for B2B or F2F connectivity, replacing point-to-point and frame relay connections. T-carriers connect the networks to the Internet. And although all packets travel over public infrastructure, the strong encryption provided by IPSec helps ensure confidentiality.

An IPSec connection begins by the two endpoints establishing a security association (SA) using the Internet Security Association and Key Management Protocol (ISAKMP). Each endpoint obtains a pre-shared secret (key) using the Diffie-Hellman key exchange (see Chapter 7). Once both endpoints have the secret, symmetric encryption is used to enable session operation.

IPSec can also provide secure connectivity for remote hosts connecting to network VPN gateways or from host to host. For example, a server on an internal network segment can establish an IPSec tunnel with another internal server for protecting data in transit between data center services.

Encryption characteristics

Before a host can establish an IPSec connection across the Internet, it must possess required software. For Windows 7 hosts connecting to a Windows Server serving as a gateway, this is usually not a problem; the necessary software is built into the host OS. In addition to possessing the software, administrators must configure and manage IPSec connections on all remote hosts. When a large number of those hosts are employee-owned, the management challenge can grow exponentially.

Figure 9- 7: IPSec Gateway-to-Gateway Tunnel

Packet protection

The IPSec specification includes two approaches to securing packets: authentication header (AH) and encapsulation security payload (ESP). When using AH protection, a packet is not encrypted. Rather, it includes an integrity check value (ICV) created by passing each packet through a hash algorithm. All fields in the packet are included in the hash calculation except those that typically change between end points. Although the data is not encrypted, a packet's ICV is checked at its final destination by recalculating it. If the target ICV equals the source ICV included in the packet, a high probability exists that the data did not change between endpoints.

Using AH for an IPSec connection provides for data integrity but not confidentiality. AH also helps prevent replay attacks. Finally, it authenticates a packet as coming from the expected source.

If an organization requires confidentiality over IPSec, ESP is the better choice. ESP is configurable in tunnel or transport mode. Transport mode provides data payload encryption for each packet, but it does not ensure authentication and integrity of packet content. Tunnel mode, however, results in encapsulation of the entire packet. The original packet header is hidden and a new header added. For remote access, ESP in tunnel mode is the preferred configuration.

SSL VPN

Although IPSec works well for B2B or F2F connectivity, it can be a management nightmare for mobile users, especially those using employee-owned devices or proprietary devices that do not inherently support IPSec. SSL VPN fills the gap: and more.

How it works

Unlike IPSec, SSL VPN encrypts data as it passes from the application to the transport layer, using transport layer security (TLS). TLS replaced SSL version 3, and provides both confidentiality and integrity. Encryption at the application layer protects the payload while a message authentication code (MAC) helps ensure data integrity. An algorithm, often called a keyed hash function, creates the MAC at the source and confirms it at the destination. Although similar to a signature hash, the MAC uses the same key at source and destination. Figure 9-8 shows the handshake process that establishes a secure session between two points.

Figure 9-8: SSL VPN Handshake

None of the following steps require special software. TLS/SSL functionality is included in all commonly used operating systems.

• Step 1: The handshake phase begins with the host sending a list of encryption algorithms it supports. Typically, the host and the gateway settle on the most secure algorithm common to both. The host also sends a random key used later to create a shared secret.
• Step 2: The gateway selects an encryption algorithm and notifies the host. Along with algorithm selection, the gateway also sends a certificate with its public key. Finally, the server also provides a random number for the key generation step. In some cases, the gateway might request a certificate from the host.
• Step 3: The host uses the certificate to verify the gateway's authenticity. If authentication passes, the host generates a pre-master secret (a random number), encrypts it using the gateway's public key, and sends the ciphertext to the gateway. Both the gateway and host use the pre-master secret to generate the master secret.
• Step 4: The host and gateway use the master secret to generate the write key (session key used for encryption) and the MAC secret (session key used for hashing).
• Step 5: The handshake ends with an exchange of encrypted packets declaring handshake success.
• Step 6: A secure session is established as the two endpoints exchange packets using the new session keys. In addition to data encryption, a MAC is added to each packet sent to ensure integrity.

Implementation methods

Organizations can implement host remote access SSL VPN in one of two ways: portal or tunnel. Portal VPN, using port 443 by default, presents a remote user with a single, standard SSL connection to a website. The connection is very similar to common HTTPS connections. However, a portal Web page provides links to internal network services. This is useful when all services required are designed to present input and output screens via a browser. The gateway acts as a relay between the remote host and internal application servers.

Tunnel implementations are a little more complicated and allow execution of non-browser applications and services over an SSL VPN connection. The Web browser must be capable of handling various types of active content: Java, JavaScript, Flash, ActiveX, etc. A small application is downloaded from the gateway but normally requires no assistance from IT or the remote user.

Defining SSL VPN requirements

SSL VPN is not always the best choice. Because of its flexibility and low management requirements, SSL VPN is usually a good solution for remote employee, guest, and contractor access when B2B or F2F is not required. Although SSL VPN can support gateway-to-gateway challenges, IPSec is more efficient for always-up connections. In addition to understanding business need, the following considerations are critical when evaluating specific SSL VPN solutions.

1. Is high availability necessary? If so, how is it implemented?
2. Can the organization modify the portal to make it look like it was developed in-house? Is branding possible?
3. Are configuration options available to ensure proper portal display on all remote devices, including smartphones and tablets?
4. Is the solution compatible with the organization's current authentication methods? Is it compatible with planned authentication methods? How easy is integration? (Remember, security controls should be seamless to users…)
5. What cryptographic algorithms does the solution support? Are all algorithms widely accepted (e.g., AES) or is the vendor attempting to implement a proprietary cipher (see Chapter 7)?
6. Is IPS integrated into the gateway? Is it necessary to implement an IPS appliance behind the gateway?
7. Does host checking occur periodically throughout each session?
8. What granularity is included in authentication? Is it possible to easily manage access by context?

Context-based access control

Regardless of how you allow remote connections, the same access control considerations apply. In addition, the access controls covered in the rest of this chapter equally apply to internal wireless access. The principle standard to apply across all access and all devices is that different controls apply to different access contexts.

Smartphones are different from laptops, and laptops differ from tablets. They use different operating systems, possess various levels of local controls, and are owned by your organization, another organization, or individuals. Access controls must take into account the various levels of risk. As we saw in the beginning of this chapter, context-based access control provides the most flexibility and the greatest granularity. Table 2 is a copy of Table 1 and depicts examples of controlling access based on various characteristics of a connection.

Table 9-2: Context Planning

Context-based access control is facilitated by first defining policies, as depicted in Figure 9-9. Remote access policy must address who, what, when, where, and with what is access allowed and to what extent. Figure 9-10 depicts an example of how an organization might apply a set of polices.

Figure 9- 9: Policy Development

Context consists of five dimensions: users, devices, locations, applications, and time. We typically group users by role or group. Roles or groups use an approved set of devices to access resources from various locations. While connected, enforcement of regulatory constraints, data leakage/loss control, and malware prevention must all apply as if the device and user were sitting in the corporate office.

In many cases, regulatory compliance and ethical business practices require restricting access for some contexts. Solutions like Cisco's Policy Governed Network architecture provide centralized control of remote, wireless, and internally wired access control. If the network is properly segmented, access to resources is easily controlled. Access to various VLANs, for example, is controlled based on current context: the user attempting access, the user's location, the device used, and the time of day.

Figure 9- 10: Access Differences

Host checking

An additional dimension common with SSL VPN solutions is host compliance. An organization can require devices seeking access comply with policy-specified patch levels, firewall implementation, and the existence of an updated anti-malware solution. Failure to comply results in limited access until compliance is achieved..

Figures 9-11 and 9-12 are screen shots of a Juniper (http://www.juniper.net/us/en/) host checker configuration console. In this example, the administrator chooses approved anti-malware products and acceptable version levels. When a device attempts to connect, a small application (the host checker) scans to determine current device state. The host checker sends the state information to the access control solution. Device state is checked against a policy server. If the device meets all mandatory conditions, authentication and authorization continues to completion.

Organizations can provide three options for non-compliant systems. First, block access. Second, allow very restricted access. Third, the device is assigned to a VLAN where servers provide updates and configuration management solutions to make the device compliant. Once the device meets policy requirements, the host checker communicates this information; the device is then allowed access.

Finally, host checking is not implemented the same across vendor implementations. Some SSL VPN solutions might only check policy compliance at initial access. If the firewall fails or the user disables it, for example, the host remains connected while increasing risk. A better solution is a host checker that checks connected devices on an administrator-defined cycle: for example, every 10 minutes. If a device fails, it is disconnected, reverts to restricted access, or is tossed into a remediation network segment.

Figure 9- 11: Juniper Host Checker Policy Management

Figure 9- 12: Host Checker Security Configuration

Conclusion

Remote access security begins with hardening the devices seeking to connect, as demonstrated in Chapter 6. We follow this with a selection of one or more remote access methods based on functional and technical requirements. Finally, we control access based on context.

The dimensions related to context-based access control include users, devices, locations, applications, and time. Automatically enforcing policies based on user role, the device used, the remote location and network risk, applications accessed, and time of day allows us to provide anytime, anywhere access while controlling risk.

Sources

Cisco. (2011). The Policy Governed Network.