InfoJur.ccj.ufsc.br

Introduction
Companies of all sizes require increasing sophistication in their communications capabilities. Financial institutions, as they continue to optimize operations, must consider alternate methods of access for employees as workdays get longer and response times get shorter.

While most corporations can be flexible in the security solutions they use for access to internal networks, financial institutions must consider the sensitivity of the data they store and the varying pressures of regulatory measures designed to protect the confidentiality and integrity of their operations.

Remote access today allows users to dial directly into an organization's internal network to execute transactions or access internal systems. This document describes best practices for remote access security. Any evaluation of best practices implies a survey of existing technology and approaches. This best practices document is based on a survey of remote access practices among the ICSA’s Financial Information Security Consortium membership. The survey represents a consistent and detailed examination of remote access practices in 11 major financial institutions across the United States.

We have organized the document to provide a comprehensive description of remote access technology and design principles before discussing our recommended best practices for remote access systems security. At the end of the document, we have provided a list of suggested reading materials and references for further study.

We wish to express our gratitude to the FISC membership and member banks for their participation in this survey. For security reasons, we have refrained from mentioning specific financial institutions in this document. Even so, their time and efforts have brought great benefit to the consortium and the industry.

Although regulators do not specify solutions, their evaluation criteria can provide valuable guidance on best practices.

Depository institutions will most likely look for guidance from the Federal Financial Institutions Examination Council (FFIEC). The FFIEC Information Systems Examination Handbook provides guidance on the criteria used to evaluate the adequacy of internal controls for many financial institutions. Institutions supervised by one of the following organizations would be advised to examine the Handbook prior to the installation of any security system.

Unauthorized dial-in access to mainframe, minicomputers, and LANs is a serious threat today. Precautions or control mechanisms must be in place to prevent threats to the financial institutions systems, applications, and data. Telecommunication controls generally are supplied for the terminals, files and for data transmission. [...]

The extent of telecommunications security in an organization varies from simple to complex and depends upon risks and costs. In each instance, the comprehensiveness and effectiveness of existing controls should be determined by carefully assessing the system's security risk and the potential effect to the financial institution.

The Handbook provides evaluation criteria regarding dial-in access, telecommunications security, user authentication, the use of home computers and many other aspects of remote access. These criteria form the basis for best practices in any financial institution.

Although the Handbook does not specify any individual technology, it emphasizes the need for authentication, authorization, and logging. All best-practice remote access systems should employ strong authentication and logging mechanisms. In contrast, even though the handbook encourages the use of encryption, our survey of financial institutions did not find encryption in use for most user access. Instead, encryption was most often used for automated monetary transfers such as ACH transactions and certain forms of EDI.

Remote access is a method for providing traveling or homebound users with access to the voice and data networks of the corporation. Although there are other means of handling business while away, such as voice mail, interactive voice response units, and teleconferencing, these technologies have different requirements for security. In this document, we will focus on remote computer access.

The predominant method of providing remote access is through telephone lines on the public network. Telephone lines are ubiquitous and provide a reliable circuit for low-speed data traffic (currently up to 56 KBPS). There are several types of dial-in access; we will describe four of the dominant approaches.

The earliest remote access technologies allowed a user to make a connection with a host via a standard character-based port on the host. This function can still be accomplished by connecting a modem to a serial port on the computer and using appropriate software. For example, a modem connected to a serial port on a UNIX machine can be enabled if getty is running on that port.

This technique is still broadly used in industry; it easily and cheaply meets many special needs. For example, organizations frequently use this kind of connection to provide emergency access for equipment vendor support contracts. Emergency maintenance modems are frequently requested because machines that fail are often unable to communicate on the network but can nonetheless communicate through a serial line. Another example of direct host-terminal connections is remote access for special-purpose systems that cannot easily be reached from a normal network.

Normally, such connections use the existing host user-authentication mechanisms. Only infrequently will the host system implement an additional authentication mechanism, such as a hand-held authentication token.

A terminal server is essentially a serial-to-IP (Internet Protocol) or serial-to-SNA (IBM Systems Network Architecture) multiplexer. The terminal server is connected to the internal host via an Ethernet or Token Ring segment and all serial connections are routed directly to the host. The ASCII terminal server has multiple serial ports to which modems can be attached. These modems are commonly configured as a hunt group to provide a common access number. The terminal server is essentially a bank of direct host-access serial ports, as described above, but the terminal server is not the destination host; users connect to the destination hosts using common IP or SNA communications protocols.

When users dial into one of the modems, they may authenticate themselves with an alphanumeric password to the server. Sometimes, however, the users can simply issue commands, such as "telnet somehost" and use the LAN. Some terminal servers support optional authentication mechanisms and some do not.

With faster modems and graphical user interfaces, users began connecting not just to a single host, but to the entire internal network. To accomplish this, the network provider had to simulate Local Area Network (LAN) traffic across a serial line. Making the LAN available over a serial connection also meant making the remote user appear to be a node on the LAN. It was initially a sophisticated solution that required bandwidth and precise timing; today, however, this is a common practice. Most Internet Service Providers (ISP’s) use the PPP protocol to communicate with dial-in customers.

Note that this is a different technology than direct host access and remote access servers. A remote LAN connection is a pass-through technology that does not attempt to process most commands from the user. Instead, the service translates the packet-based communication of a LAN into a stream of bits that can be transmitted across a standard phone line.

Today, the standard protocol for remote LAN access is the point-to-point protocol (PPP). This protocol implements the Internet Protocol (IP) over serial connections. From an OSI (Open Systems Interconnect) architectural standpoint, PPP replaces the data-link layer in a communications session and permits network-layer protocols to ride on the connection.

For example, an organization may set up a direct-access modem on a server's serial port to provide access for low-volume file transfer. To run FTP over the connection, though, requires IP, so the server will run PPP on that serial connection.

The remote node must have a valid IP address for the PPP connection to work properly. These addresses can be pre-assigned to each remote user, or they can be allocated dynamically. Usually, RAS (Remote Access Server) devices, described below, will use dynamic IP addressing in order to support larger numbers of remote users.

Some organizations that require multi-protocol access to internal networks will implement them on the same remote LAN connection with PPP. Since PPP works below the network layer, it can support simultaneous packets for TCP/IP, Novell IPX, NetBIOS, and other LAN protocols on the same serial connection.

Remote access servers are becoming popular as a mechanism for customizing the interface for a specific corporation. A RAS device is special-purpose networking equipment specifically designed to support remote or mobile computing. As with a terminal server, the RAS supports multiple dial-in modems. The RAS will handle static and dynamic IP allocation; Automatic Number Identification (ANI), if supported; and, frequently, additional security mechanisms such as RADIUS or TACACS authentication and dial-back support (see below).

The authentication mechanisms supported by RAS devices vary widely. They can be as simple as a password or as sophisticated as a hand-held authentication device with encrypted communications lines, automatic ANI, and dial-back.

Ascend and Bay Networks and Microsoft produce examples of remote access servers.

There are three critical security elements that organizations should consider when implementing or evaluating remote access solutions:

Confidentiality is provided by mechanisms to protect the information in the communication channel. The strongest method of providing confidentiality is to encrypt the communications session.

Defense in Depth is the concept of providing multiple security mechanisms to protect the same resources. This way, attackers must overcome several obstacles in order to break in, rather than just one. This reduces the chances that one undiscovered bug in a security mechanism will allow unauthorized access to all organizational resources.

Remote access is a critical element in many IT programs. Therefore, the security tools developed to support remote access systems must focus on security and availability. A security tool that breaks frequently can turn into a denial-of-service problem for the organization.

This section examines some of the most common types of security tools for remote access. We will present some of the common implementation issues and pitfalls associated with each type of technology and examine the value of each approach. Where appropriate we will include specific product names. This is not intended to be a recommendation for or against any individual product but rather a way of providing examples for the reader. In any case, product features change so frequently that any specific issue is likely to change soon after publication of this report.

By far the most commonly recommended means of protecting a remote access system, these devices provide strong protection against spoofing or brute force password attacks. Hand-held authentication tokens provide a one-time-password for each session. To improve the security provided for the organization, most types of token also implement positive authentication, as defined by the National Institute for Standards and Technology (NIST).

Hand-held authentication devices and biometrics devices both meet this criterion. Passwords, digital signatures, dial-back devices, and ANI matching do not meet this criterion because they don't use two methods of authentication.

The idea behind positive authentication is that the network owner doesn’t necessarily care where the user logs in from as long as the user can be authenticated correctly. When positive authentication is implemented correctly, it can provide a significant barrier to intruders.

Hand-held authentication tokens provide the organization with assurance that the user is authorized as long as users report missing tokens. This dramatically improves the risk profile of an authentication system.

Examples of hand-held authentication tokens that support positive authentication are the Security Dynamics SecurID PINPAD card, the Enigma Logic Safeword card, and the Cryptocard.

Livingston Enterprises developed a protocol for authentication by dial-in systems. The protocol is called Remote Authentication Dial In User Service (RADIUS) and is used on a variety of terminal and LAN servers today. Although it has been available commercially since 1995, it is not yet extensively deployed in the field for remote access.

RADIUS works with other authentication mechanisms and has been ported to several operating systems. Since it is a proprietary protocol, it must be purchased. RADIUS requires that the organization establish a central security server where the user-authentication information can be stored and managed for all remote connections. Then each remote port can be configured to communicate with the security server for authentication information.

Our analysis of RADIUS indicates that users should pay special attention to the location and security configuration of the RADIUS security server. Since this server is often a UNIX host, this host must be tightly configured to prevent attacks that compromise the server. Users should also check to ensure that the installation works smoothly with any authentication system procured for the remote access installation. Failures that affect interaction with an external authentication system can create denial-of-service problems for the network.

The FISC survey contacted more than 20 large financial institutions around the United States. Our survey of practices at institutions covered: banking, insurance, and specialty finance companies. The survey was conducted by phone over the course of 2 months in 1997. Respondents were significantly involved in the remote access operations of their respective institutions. The survey was composed of 50 questions regarding the nature of remote access, remote access security policies, mechanisms, and procedures. Survey respondents were also encouraged to comment on other items of interest to the best practices document.

All surveys were conducted under the condition that individual names would remain confidential. We have aggregated results for that reason. All institutions surveyed had already formed an internal data security group. The data security group either completed the survey or coordinated the survey with a member of the remote access team.

Seven of the respondents were large regional or national banks with more than 1000 employees. Although all were governed by some regulatory agency (FDIC, OCC, OTS) some branchless institutions were included in the survey. Some of the banks had national charters, (governed by the Office of the Comptroller of the Currency) meaning that branches were dispersed around the US.

Overall, however, the results showed a consistent interest in security for any existing remote access connections among the banks surveyed. Interestingly, those banks that did not have remote access currently in place still had remote users. In banks that had not yet implemented remote access, users had nevertheless created their own unauthorized remote access points using networked PC’s and remote-control software. The banks where this end-run occurred, realized that it created an enormous exposure for the institution and planned to replace the individual modems with a secure remote access system within the next year.

Our survey of financial institutions found that most organizations used remote access to provide LAN and E-mail access for employees and contractually-related users. The median number of users for remote access was 1000. In roughly half of the institutions, the remote access population was larger or the same size as the Internet enabled population. All survey respondents indicated that remote access was designed to support access from home to

Figure 1 shows the most common configuration for remote access by participants. In this configuration, the remote access system is located inside the firewall and users are directly connected to the internal network after connecting to the remote access system. The remote access system is protected using positive authentication. In most cases, the device is managed by the corporate networking group, but the Information Security group manages security and UserID activities.

All respondents discouraged the use of remote-control activities by end users. Remote control, when it was employed, was most often brought in by end users as a means of bypassing corporate restrictions on remote access by employees. In organizations without formal remote access systems, remote access was seen as a way to eliminate the unauthorized use of remote control by end users.

Overall, the characteristics of a best-practices remote access security program were consistent throughout the survey group. All respondents concurred on several important components of a remote access program. In all cases, the data security group was very involved in the development of the remote access function. In all cases but one, the remote access system either employed positive authentication or was being replaced by one that did.

In the next few sections, we will discuss the results of the survey and our observations regarding the best practices in participating institutions. For many reasons, the participants were assured of confidentiality during the survey process. Results have been aggregated and should not reflect any individual order or association. While no institution implemented every best practice across all remote access environments, most institutions met more than 65% of the best practices criteria in this document.

Remote access policies typically supplement the overall security policy document established in the organization. Often the requirements for remote access are documented as standards or directives from the group within the institution that provides the service. In all but one of the financial organizations surveyed, a formal remote access security policy or standard existed if remote access was permitted.

A number of organizations supplement their policies with agreements signed by each user of the remote access service. Since all organizations but one require hand-held authentication tokens, these forms act as a receipt for the token and an agreement to abide by institutional policies regarding remote access. Most organizations also use the process of issuing tokens to provide users with training on the remote access service.

Among the organizations we surveyed, the following policy points are consistent throughout:

Some institutions had policies regarding dial-out services. In these policies, all dial-out circuit requests were approved by the data security organization. Some companies went further to provide pooled modems for dial-out users. Pooled modems, however, are technologically complex and require special software to be installed on user PC’s to work. Other organizations did not control dial-out circuits, allowing many users to obtain modems easily for desktop machines. We will discuss this further in the following section.

Control mechanisms vary among financial institutions, but a common theme runs throughout. While many financial institutions provide remote access for employees, these access points are tightly controlled by the organization. Most control mechanisms focused on positive authentication of remote users and those measures were often supplemented with controls over systems that could be reached from a remote location.

The most common method of positive authentication in financial services is the hand-held authentication token. Users are issued a token and taught how to use it. There are no special adapters for the user’s PC or special locations that they are restricted to dialing from. The user can access the network from a hotel as well as from home.

The FISC survey shows that positive authentication is a nearly universal criterion for interactive remote access. Although positive authentication systems vary, survey respondents most often chose hand-held password generators, as found in the Security Dynamics SecurID card. One respondent, in particular, did not employ positive authentication on the remote access system. This organization instead restricted the remote access system to a small group of maintenance users on a limited set of machines on the network.

Depending on the form of remote access, organizations may decide that the remote access server must be located outside the firewall. This is a two-edged sword. If the remote access server is located in the Internet DMZ, remote users can feasibly access the Internet freely from outside the firewall. If users enter the organization’s network from the Internet DMZ, there is a possibility that an Internet user can fool the firewall by looking like a remote access user. This problem is correctable, but should be addressed with a clear understanding of the technology and threats.

Placing the remote access entry point inside the firewall can permit uncontrolled access to internal resources. Most remote access solutions provide limited capability to control an authenticated user’s access on the network. In high security situations, this could mean additional resources to maintain another access control list or additional risk from dial-in users. Organizations that place remote access points inside the firewall will often require frequent user recertification reviews to reduce the potential for unauthorized use.

Using a firewall to control remote access sessions is not considered a best practice today. Firewall technology is not well built for this type of function and is unlikely to provide the multi-protocol filtering necessary to prevent intrusions. If firewalls are used to protect remote access, best practices indicate that the firewall should exert application-level control over all sessions. In such a configuration, the firewall should be configured to proxy TCP functions coming from the remote access system. This will increase control over the session and increase the amount of log information that can be obtained.

The FISC survey found that the majority of institutions did not use a firewall to control remote access sessions. Most often, the firewall was considered too restrictive and potentially damaging to availability. Since remote access is used for all forms of LAN access, the firewall’s inability to control IPX or SNA traffic reduced its value in a remote access environment. One of the organizations that did use a firewall placed the remote access server in the DMZ (de-militarized zone).

We should note here that while the firewall did not control inbound use of remote access, the majority of institutions surveyed had used the firewall to prevent remote access users from going to the Internet.

Any comprehensive remote access program must address the use of modems by employees. Modems are frequently used to bypass remote access servers and therefore pose a threat to the controls in place at the institution. For these reasons, all but one institution had instituted modem controls as part of the overall data security program.

Most often, modem users were required to obtain approval from the data security group before a modem could be attached to a networked computer. Most often, the modem-control policy permitted users to connect modems only to outbound analog lines. This can be accomplished at the switch by disabling the Direct Inbound Dialing (DID) feature of the analog line when it is installed. Organizations that disabled inbound access to modems believed that the major threat from the modem had been eliminated, but still expressed interest in methods that could eliminate all dial-out modem lines.

Our experience shows that outbound modem pools are seldom used today. Outbound modem connections require special software on the PC that can convert the circuit switched connection provided by the modem into a virtual circuit on the LAN. The packet-switched, multi-protocol nature of most LANs makes this a difficult proposition. Software is always required on the user desktop and frequently interferes with other LAN protocol drivers on the desktop. These obstacles prevent most corporations from using outbound modem pools widely.

Our survey found that most organizations do not formally control FAX connections. It is extremely unlikely that a FAX connection would permit some kind of inbound connection to the network. Therefore, FAX lines are usually just cataloged and managed like other specialized phone circuits.

A few institutions around the US supplement their remote access implementations by requiring encryption for all connections. In the past, encryption was viewed as difficult and slow when implemented in software. While the speed of solutions has improved, the best options involve special hardware for each remote user. By encrypting all remote sessions, the organization gains strong control over every inbound connection and can prevent most attacks in front of the terminal server.

The disadvantage of encryption is its impact on performance and high cost. Hardware solutions often require special configuration, meaning that the organization must also install the device on each remote computer. The cost for purchasing the hardware and maintaining the configuration on remote machines often exceeds $300/year. Therefore, only organizations with the strictest requirements for access control and confidentiality use encryption on all remote access devices.

Our survey showed that most organizations used encryption only for Internet-based access or EDI applications, such as ACH transactions or Fed transfers. EDI did not appear to be considered a remote access issue by the group, although remote access through the Internet was generally seen as a remote access issue. EDI security was being addressed in most organizations, although the security group was less involved with EDI than with remote access security issues. A mitigating factor in the EDI discussion was the use of Value Added Networks for EDI activities, such as Advantis from IBM.

Participants believed that encryption was mandatory for Internet-based transfers. Two organizations were notable for their strong emphasis on using the Internet for file transfers. The institutions had purchased encrypting file-transfer tools for sharing information via the Internet with partners. Other organizations that had not begun emphasizing the Internet for file transfers were attempting to evaluate or integrate similar tools for Internet-based exchanges.

The ability to identify and track intrusions is a key requirement in the FFIEC guidelines. This influences the choice of the type of remote access system and its implementation in a financial institution. Logging sessions should be a mandatory feature of any remote access server system. The ease with which the organization can review those logs is a necessary consideration during planning of the remote access system.

Logging can occur at the remote access server. The server can log session initiation and termination. The server can log many types of connections and certain management functions performed on the server (such as adding new authorized users). Additionally, the server can log any outbound sessions started from inside the corporate network. If the remote access server permits outbound sessions, each of these should be monitored carefully to prevent the most common forms of insider attack.

In some cases, the telephone and server system are sophisticated enough to pass and log the phone number of the incoming call. This can be accomplished with ANI-capable modems, but is not a common feature of most systems. With ANI, the institution can construct a consistent record of locations for all incoming sessions. Although the number can be obtained in only about half of the sessions attempted, this provides valuable information if an incident must ever be investigated.

In some cases it is inconvenient or impossible to log significant events at the remote access server. In these cases, a separate authentication server should be used and logs should be kept on all authentication transactions. Typically, organizations log every transaction on the authentication server because the logs can remain small and the authentication server is the most sensitive component of the remote access installation.

Since most security organizations controlled the use and management of the authentication server, logging at this server was a simpler process than logging at the remote access system. We found that log reviews were consistent only when the security group had responsibility for administration and log maintenance on the authentication server. While review cycles varied, the majority of survey respondents reviewed logs at least weekly. Respondents generally held that reviews were important to the integrity of the remote access process.

Organizations that use a firewall to control the remote access pathway can provide significant control and logging for all sessions by logging at the firewall. The firewall is typically a much more effective security tool than any of the other components. Since it sees most activities in a user session, it can provide much more information about attempted intrusions through the remote access pathway. Firewalls also provide enhanced analysis and notification tools for use by the security team. Firewalls can log session activity as well as other transactions, such as file transfers. Although logging capabilities depend on the firewall model, firewalls are most often much better at log generation and monitoring than the remote access servers we have reviewed.

Nevertheless, most organizations do not use firewalls to control or log connections through the remote access system. Apparently the reasoning for this is the complexity that firewalls introduce in the remote access equation. Firewalls frequently only permit TCP/IP traffic through and sometimes complicate that traffic as well. This additional complexity is seen as unnecessary in light of the protection provided by the positive authentication system. Therefore, firewalls are only used in isolated cases for either protection or logging.

When we asked about intrusions, the responses were mixed. In some cases institutions were unable to respond to these questions. In cases where responses were given, we have aggregated those responses to protect the confidentiality of the associated institutions. It is clear that institutions employing remote access have seen intrusion attempts. It is also clear that these institutions spend time and resources trying to determine if any intrusion attempts were successful. While no actual intrusions were reported, at least half of the institutions have identified and dealt with employee or contractor abuse on the remote access system.

The responses in this section indicate that the positive authentication employed on remote access systems provides significant protection against intrusion. The data also show that intrusions are only part of the remote access security problem. Internal abuse and misuse provide ample reason to monitor the remote access connection.

Interestingly enough, training is more common for remote access than for any other component of the security program at institutions surveyed. Since remote access usually involves new technology and new procedures, 80% of organizations surveyed have implemented training for users. Most often, the training involves the distribution of written materials regarding the token and remote access system. Some organizations help users by providing corporate equipment for remote access. Other institutions provide in-person training. This training covers the process for logging in, but can get as sophisticated as formal presentations by trained security administrators.

Training enhances both the security of the remote access process and the reliability of the service. By explaining the system to users, the administrator can answer routine questions before they become a denial-of-service problem. Training should include an explanation of the remote access security policy as well as an admonition against sharing IDs or access devices. Talking about the difference between security problems and computer problems can also reduce undue frustration with a service that is often viewed as entirely security related.

While survey respondents believed that training reduced help calls from users, we did not obtain any data regarding the statistical reduction for the various types of training. Drawing from survey work by Gartner Group, we find that formal training on PC use can reduce help-desk requirements by 2-6 hours per user. Responses from organizations that sponsored formal training programs supported the statistics from Gartner. Those organizations claimed a significant reduction in the number of help-desk problems after training.

The FISC survey shows that the deep involvement in remote access security by security organizations extends to the administration function. In all survey cases, remote access security administration was handled by the data security organization. Typically, the data security organization managed remote access via the in-house ID administration group. Since remote access always involved some form of token, this activity seems well placed. Some reasons for handling remote access in this way are to ensure accurate distribution of tokens and to ensure rapid revocation of tokens for users who leave the company. Most often in financial institutions, the ID administration function is one of the first to know about terminations of employment.

A group in the Information Systems area often handles system management for remote access. Our survey respondents said that either networking or the operating system administration group handled it. This shared responsibility is likely necessary since those two organizations are most likely to debug user calls about failed connections. With the high level use of remote access in many organizations, high availability is often an issue.

An under-reported aspect of remote access that affects security is remote access for maintenance ports on UNIX or mini-computer systems. These ports are often single modems for emergency maintenance purposes and are most often used by vendors. If the modems cannot support positive authentication, the ports must be strictly monitored and turned on only when explicitly requested by an authorized maintenance person. FISC institutions employ a variety of techniques for validating authorized users, including phone calls to the vendor and internal requests.

One remarkable feature of remote access administration is its sensitivity and criticality to most financial institutions. None of the institutions surveyed outsourced the administration of the remote access system. Two organizations had considered outsourcing of the function and decided against it. They reasoned that the sensitivity of external access decisions was too important to relinquish control of the remote access feature to anyone outside the corporation. Our experience with remote access failures supports this conclusion. Most often remote access security failures are caused by administrators with more interest in making it work than making it secure.

Table 1 summarizes the best practices and additional recommendations for securing remote access to corporate systems.

Control Element	Best Practice	Recom- mended
Remote Access Security Policy	X
Policy prohibiting uncontrolled modem lines	X
Policy requiring manager’s signature on all (inbound and outbound) remote access requests.	X
Policy requiring strict supervision of remote control connections.	X
Policy specifying security control requirements for EDI.		X
Policy regarding home storage of confidential corporate information.		X
Security logging of connections and violations	X
Weekly monitoring of Remote Access Security Logs	X
Positive authentication required for all interactive remote access sessions.	X
Encryption for Remote Access sessions conducted across the Internet, or for unattended file transfers related to monetary transactions.	X
Authentication Token Signature Forms that require user to state understanding of Remote Access Policies		X
Documented security procedures for Remote Access administrators and support personnel.		X
Access control and encryption for unattended file transfers.		X
Positive authentication controls on PBX or phone switch.		X
User Training that describes the system, security features, and procedural requirements.		X

Table 1. This table shows Control Elements that should be considered "best practice" features of a remote access security program in the financial industry. Other elements are recommended, but not required for financial industry systems.

A new generation of remote access systems is coming that allows users to access the internal network through the Internet. These systems will permit users to connect to all resources inside and outside the corporate network through any ISP in the world. These systems provide advanced authentication and encryption to protect traffic.

Although these systems have not been available long enough to support a best practices evaluation, we will attempt to predict the issues based on our experience with the technology and current approaches.

Although smartcards have been available for many years, they have not been used extensively in remote access solutions. True smartcards (also called chip cards) place a CPU and memory on a credit card sized device that can be read through a standard interface device. Smartcards are used extensively in Europe and other parts of the world, but this has not translated into success inside the United States.

Smartcards allow users to easily carry an authentication device for many specific applications. Smartcards can be used to control physical, as well as computer access to an installation and the cards can support encryption internally without disclosing the keys to outsiders.

The major disadvantage of smartcards is the requirement for readers in each place where the smartcard is used. Until PC and laptop manufacturers begin including smartcard readers with their units, smartcards will be an expensive solution to implement for remote access systems.

Examples of smartcard-based authentication systems are the V-One Smartgate and the IRE Remote Access system.

Recently, many organizations have begun allowing remote access from the Internet. This is a convenient and relatively cost-effective solution. Remote users simply dial into an Internet service provider (ISP), then use normal Internet communications protocols, such as telnet, to connect to the host systems. This is very easy to do, even for traveling personnel, because of the wide availability of nationally-present ISP’s like Netcom, AT&T, or MCI and international value-added networks such as CompuServe.

This solution places the burden of maintaining dial-in and networking capabilities on the ISP, rather than on the organization's technical support or networking groups. This convenience, however, is not without significant security tradeoffs (see Threats).

Remote access via the Internet should not be accomplished unless the session can be encrypted from user machine to the inside of the corporate firewall. We have seen numerous reports of the danger of eavesdropping on the Internet, requiring caution about transmitting confidential information across the Internet in an unencrypted form.

From an operational point of view, remote access via the Internet is still evolving. Reliability of the connection is still a problem and encryption of circuits can impede problem analysis efforts inside the organization.

There are several significant risks in any remote access solution. Organizations must implement the correct controls to address each of them. These significant risks and vulnerabilities are:

Uncontrolled dial-in lines are a grave danger to any network. An uncontrolled dial-in does not require that remote users provide any authentication information whatsoever. For example, a modem attached to a serial port on a UNIX machine that has a root account lacking a password. Terminal servers without authentication are particularly dangerous, because they provide access to the LAN and are frequently under-monitored. It is amazing that this problem still exists, but it does, in many places.

A weakly authenticated dial-in provides either inadequate logging or inadequate control over access to resources. For example, a remote access server with an account guest that has the password "guest" is weakly authenticated, because anyone can connect and use it. Even well designed remote access systems can fall into this category without effective security management. In most cases where hackers have compromised a remote access system, investigation shows that the system was poorly managed or the owner permitted inadequate passwords.

Many terminal servers and RAS devices ship from the factory with default accounts and passwords. For example, one brand of terminal server uses its IP address for the administrator password if one is not set. It is extremely important that organizations find all default accounts and apply strong passwords to them (or remove unnecessary accounts).

This is the most significant threat with remote access via the Internet. There are several publicly available packet-sniffing tools. These tools watch passing network traffic and record interesting events. Hackers like to use these tools to capture authentication information. For example, if you telnet from a remote site, over the Internet, to your office, your login and password are transmitted in the clear. Anyone with access to a router, system, or wire along the transmission path can record it. This is one of the most significant causes of break-ins from the Internet, according to the Computer Emergency Response Team Coordination Center and FBI.

All authentication data on the Internet should be encrypted. A sufficiently sophisticated attacker can spoof even one-time passwords, like S/key.

Dial-back spoofing involves tricking a dial-back system into calling the wrong number, or not calling a new number at all. This is possible by using programmed attacks.

Two techniques that have been reported for spoofing dial-back systems are described here. The first involves exploiting the call-forwarding feature on any phone. If call forwarding can be activated remotely, the intruder can use this feature to forward the user’s home phone to their location. Then when the dial-back system calls the home of the authorized user, the call is then forwarded to the intruder.

A second type of intrusion had been executed on some systems by dialing into the outbound modem port. Since the outbound modem line had not been controlled in the same way as the inbound modems, the intruder was able to obtain a carrier and then access internal systems. Although this attack is not feasible in modern dial-back systems it exposes one kind of creative attack against generic remote access environments.

There are other techniques that require manipulation of the phone company switch. Although these attacks might seem extremely complex, telephone switch manipulation has occurred more often in the wild than successful attacks on encryption or token based authentication systems. Dial-back systems, or any ANI-based authentication, should use some additional authentication mechanism, such as a hand-held authentication token.

Another threat to Internet-based remote access is IP spoofing and DNS attacks. These work against authentication systems based on the remote node's IP address or name. The UNIX r-commands (rsh, rlogin, etc.) are examples of such authentication systems. These attacks involve, essentially, a remote system lying about its IP address or name.

For this reason, any IP or name-based authentication should be strongly supplemented with additional authentication mechanisms.

Session hijacking is yet another threat against remote access using the Internet. In this scenario, the attacker listens to an existing and already-authenticated session (e.g., a remote telnet after the user has authenticated using a Secure Net Key (SNK) hand-held authenticator). The attacker uses IP spoofing and sequence number guessing to take over the existing connection. The user will think the connection has simply dropped for some reason, while the host system will never know the difference.

Accounting - A mechanism, usually built into a computer operating system, for tracking how many resources a user consumes. Frequently confused with auditing.

Asymmetric Cryptosystem - The technical name for public/private key encryption. Called asymmetric because the encryption key is different from the decryption key. RSA is an example of an asymmetric cryptosystem.

Authentication - The process of proving identity or validity for a specific purpose.

Automated Clearing House (ACH) - A value-dated system that supports both credit and debit transactions. The ACH is a nationwide electronic payments system governed by the National Automated Clearing House Association.

Challenge/Response - A technique for authenticating users. The host issues a challenge, such as a random 8 digit number to the user. The user then encrypts the number with a key shared between the user and the host. The result is passed back to the host for verification.

DES - The Data Encryption Standard. This is the most widely used encryption process for financial data in the world. Described by FIPS Pub 46. AKA DEA, the Data Encryption Algorithm. A symmetric block cipher operating on 64 bit blocks.

Digital signature - a non-forgeable transformation of data that allows the proof of the source (with non- repudiation) and the verification of the integrity of that data.

Direct Inbound Dialing (DID) - This describes telephone lines on a private switch that permit inbound calls as well as outbound calls.

Firewall - A computer or router (or combination thereof) configured to permit or deny specific kinds of traffic through it. Usually used to protect a network from potentially hostile outside networks; intranetwork firewalls, however, are becoming more popular.

Hunt group - A set of telephone circuits on a private switch that are allocated in serial round-robin fashion, according to their status. If line 1 is busy, line 2 connects. If lines 1 and 2 are busy, line 3 picks up, and so on.

IP - The Internet Protocol. The lowest common denominator of all the protocols communicating on the Internet. This basic protocol allows computers to talk to each other. It is independent of the media-specific protocols below it (Ethernet, FDDI, SONET, etc).

Integrity - the property that sensitive data has not been modified or deleted in an unauthorized and undetected manner.

Key - A piece of information used to encrypt and decrypt information in cryptosystems. Specifically, a cryptographic key is a parameter used in conjunction with a cryptographic algorithm that determines:

Key Length - The size, in bits, of a cryptographic key. One of the three things that directly affects the strength of a given cryptosystem. The longer the key, the harder it will be to break the cryptosystem. The other two things that effect the strength of the cryptosystem are the strength of the algorithm and the amount of ciphertext available to the attacker.

Masquerading - Lying about who you are so a remote system will allow you access.

PPP - The Point-to-Point Protocol. A protocol designed to permit small computers (usually at home) to communicate with larger multi-protocol networks over modems.

Packet Filter - A mechanism for making permit/deny decisions within a firewall. Operates at the IP layer. A packet filter will permit or deny a connection based on the source IP address, destination IP address, protocol, and destination port. A packet filter is a basic building block for constructing firewalls.

Personal Identification Number (PIN) - a 4 to 12 character alphanumeric code or password used to authenticate an identity, commonly used in banking applications.

Remote Access - Using external communications technology to interact with a designated network system. Commonly employed in corporations to permit users to dial-in from remote locations.

Remote Access Service (RAS) – A service designed to provide a consistent graphical user interface to remote users of a system or network. Commonly, RAS is a term used to describe the Remote Access Server product from Microsoft Corporation.

Remote Control - A technology that permits a remote user to operate a PC as a local user would. This technology enables the user to see screens and type commands on the keyboard in the same way that a user at the PC would. This technology is implemented using tools like "Carbon Copy" and "PC Anywhere."

Router - A network device that moves traffic from one network to another. Routers understand packet header information and, therefore, can selectively retransmit each packet according to a pre-established set of rules.

SSL - The Secure Socket Layer. A protocol designed by Netscape for encrypting all communications between a web browser and the server. Prevents (given secure enough encryption keys) unauthorized observation of network traffic.

Symmetric Cryptosystem - The technical name for secret key encryption. AKA private key. Called symmetric because the encryption key must be the same as the decryption key. DES is an example of a symmetric cryptosystem.

TCP - The Transmission Control Protocol. Runs on top of IP. The term is frequently misused to represent all of IP, rather than just the TCP portion. The distinguishing feature of TCP is that packet delivery is guaranteed, sequence is guaranteed, and the connection is stateful.

UDP - The User Datagram Protocol. Another protocol that runs on top of IP. Packet delivery and sequencing is not guaranteed; the application must accommodate lost or out-of-sequence packets. The connection is stateless.