Strategy For Establishing Secure Remote Access
Report and Recommendations
STRATEGY FOR ESTABLISHING SECURE REMOTE ACCESS
Prepared by: AMG, Remote Access Working Group
April 16, 1997 May 6, 1997
THE NEED
1. The general need is to provide members of the NIH community secure and
convenient remote access to the information they need to perform their
work. Remote users include those who perform additional work at home, people
traveling on NIH business, and those who tele-commute. The activity to be
supported includes sending and receiving e-mail, word-processing and other
office automation functions, access to electronic files stored on ICD LANs and
servers, access to NIH systems, and access to the Internet.
2. In addition to these functional requirements, there is a need for
security. Only those persons authorized should gain access to the
NIHnet and in turn to the systems, services and databases which it
interconnects. The need for security includes not only protecting the privacy
and confidentially of sensitive information but also safeguarding it from loss
or damage and insuring that NIH computing and communication assets are used
only for the purposes intended and by the persons specifically authorized to do
so. While end-to-end security is required to properly secure information, the
remote access strategy only addresses securing access to the
NIHnet via dial-up telephone lines.
3. There is also the issue of economy. Because the need for remote
access occurs across the entire NIH, it is reasonable to assume that economies
could be gained through a common shared approach rather than multiple
independent solutions, each with its own price to implement, operate and
support.
4. Finally, there is the need for growth and extensibility. Any
facility which meets the requirements above for functionality, security, and
economy will be well-received and used extensively. The service must be
capable of capacity growth and it must be standards-based so that it does not
become obsolete quickly.
SCOPE AND OBJECTIVES OF THE WORKING GROUP
The working group, given the tactical nature of its charter, set as its
scope and objectives identification of a strategy leading to the rapid and
low-cost implementation of dial-up remote access capabilities that could
satisfy most, if not all, of the existing dial-up remote access requirements.
Further, the group sought a near term solution that could also be a proper
subset of a longer term capability. This strategy only addresses provision for
a secure, dial-up remote access entry point to the NIH network, NIHnet.
Security of non dial-up remote access facilities, databases, the NIHnet itself
and applications are not within the purview of this working group.
ALTERNATIVES CONSIDERED
Three functional alternatives were considered. Due to the shortened time frame
available to the working group, an in-depth, fully described and quantified
alternatives analysis was not feasible. The three alternatives considered to
provide dial-up remote access to NIHnet are:
1. Centrally provided, i.e., a single NIH dial-up remote access facility,
managed and operated by DCRT;
2. ICD provided, i.e., each ICD would provide the dial-up remote access
facility for its users. The facility would be managed and operated by each
ICD;
3. Commercially provided, i.e., individuals or ICDs would utilize external
service providers such as Erol's to gain access to NIHnet.
The working group also looked at remote access capabilities being developed by
local cable TV companies and telephone companies. Although there is
considerable promise for both these options, neither is ready for wide-scale
use now.
The working group discussed the pros and cons of each alternative and in
consideration of the objectives of the strategy, agreed that the first
alternative - centrally provided remote access, should be the recommendation.
This was based not only on the obvious economies of scale and reduced
redundancy of effort that the central alternative provides, but also on the
reality that an existing, centrally provided dial-up remote access facility -
PARACHUTE - was already available that would meet most of the requirements for
remote access. The group very quickly turned to the examination of the
PARACHUTE facility which was established by DCRT in 1995 to address the needs
described above.
DESCRIPTION OF PARACHUTE
PARACHUTE is a well-conceived standards-based dial-in facility that allows
remote personal computers to temporarily connect to the NIHnet and provides its
users essentially the same functionality available at an on-campus work
station, albeit at a slower speed. Technically, it provides a "remote node"
service which means that the remote personal computer performs all the usual
workstation processes. Another form of remote access is called a "remote
control" in which the remote personal computer controls another personal
computer through its keyboard and display monitor. (This latter form of remote
access can also be conducted via PARACHUTE if both the master and slave
computers have appropriate software.) Still another form of remote access is a
"remote terminal" where the remote personal computer simply emulates a terminal
and all the actual processing is done by a host computer.
ISSUES
PARACHUTE, as it exists today, is not a complete remote access solution. There
are several issues that should be addressed regarding PARACHUTE. The issues
are in the following areas:
1. Security - There is no account aging or active de-registration process,
there is no current facility for password aging, and there are no current
controls on session length. A review of PARACHUTE security has already been
initiated and a plan for improving security is expected soon (within 40 days.)
2. Can Parachute Meet All Remote Access Needs - Many ICDs have already
established remote access capabilities on a limited scale for specific systems.
This leads to the question as to whether a standard should (or could) be
established for all NIH remote access activity. The consensus of the working
group was that, while PARACHUTE should be promoted as the preferred NIH remote
access solution, it should not be mandated as the only solution nor should
there be a requirement to convert existing capabilities that are providing
acceptable service. The group also feels that while PARACHUTE should not be
mandated as the only dial-up remote access to the NIHnet, ICD's should not be
allowed to "opt out" by providing their own complete dial-up remote access
facility. This would defeat the economies of scale possible via the central
facility. Rather, ICD's would augment the central facility to support unique
remote access needs not met by the central facility.
RECOMMENDATIONS
The Working Group recommendations for consideration by the CIO are:
1. Adopt and Promote PARACHUTE as the preferred NIH means for dial-up remote
access to on-campus systems and the Internet. PARACHUTE can meet most of
the needs of the entire NIH community. Its widespread use would not only lead
to improvements in personal productivity, it would provide economies of scale
and the user community could expect a consistent high level of support from
DCRT.
2. Assess PARACHUTE security. Although there are several issues with
PARACHUTE security, a security assessment and plan is being prepared for review
by the Telecom/AMG Security sub-committee and there is every indication that
necessary changes to PARACHUTE can be made quickly.
3. Continue to plan, monitor new technologies, configure, operate and fund a
central remote access facility (currently, PARACHUTE) as an integral part of
NIHnet.
4. Develop the minimum security requirements for dial-up, remote access to
NIHnet. Based upon the review and recommendations of the Telecom/AMG
Security Subcommittee (see #2 above), all dial-up remote access facilities
including PARACHUTE must meet these minimum requirements. Authorization for
dial-up remote access should be granted through designated personnel in each
ICD.
5. Establish an ongoing review by the AMG or a designated sub-committee, of
remote access technologies to keep current with the market place and to
minimize costs.
Working Group Membership:
John Stanford (NHLBI)
David Orchard (NIAAA)
Charlie Jones (OD)
Wesley Russell (NLM)
Roger Fajman (DCRT)
Jaren Doherty (OD/OIRM)
Ellen Ring (DRG) Chair
Strategy for Establishing Secure Remote Access
Working Group Recommendations
Recommendations
|
Initial
Step(s)
|
Proposed
Agent
|
1.
Adopt and promote PARACHUTE as the preferred NIH means for dial-up remote
access to on-campus systems and the Internet.
|
*
Endorse the remote access recommendation
* Promulgate remote access policy
|
AMG
& CIO
CIO
|
2.
Assess PARACHUTE security
|
*
Complete the security assessment currently underway
|
OIRM
& DCRT
|
3.
Continue to plan, monitor new technologies, configure, operate and fund a
central remote access facility (currently PARACHUTE) as an integral part of
NIHnet
|
*
Promulgate procedures for remote access (including web page and hard copy)
* Expand PARACHUTE to include ISDN Evaluate use of higher speed technologies
such as xDSL and cable modems for remote access
|
DCRT
|
4. Develop the minimum security requirements for dial-up remote access to
NIHnet.
|
* Using OIRM and DCRT as basis for the requirements, develop the minimum remote
access standards
* Promulgate minimum remote access standards
|
AMG/TC
AMG/TC & CIO
|
5.
Establish an ongoing review by the AMG, or a designated subcommittee, of remote
access technologies.
|
*
Establish remote access standards and technologies as a permanent AMG meeting
agenda item
|
AMG
Chair
|
Report on Interoperability at the NIH
|