• Preface
• Table of Contents
• 1.0 SUMMARY
• 1.1 Executive Summary
• 1.2 Summary of Major Recommendations
• 2.0 ACHIEVING CONSENSUS
• 2.1 Introduction
• 2.2 The Process
• 2.2.1 E-Mail and Document Exchange
• 2.2.1.1 Presentation
• 2.2.1.2 Discussion
• The main discussion issues were as follows:
• 2.2.1.3 Consensus Reached on Group Recommendations
• 2.2.2 Secure Network Environment, Including Intranets
• 2.2.2.1 Presentation
• 2.2.2.2 Discussion
• 2.2.2.3 Consensus Reached on Group Recommendations
• 2.2.3 World Wide Web Based Applications at the NIH
• 2.2.3.1 Presentation
• Application Development Issues
• Server Issues
• Crosscutting Issues
• 2.2.3.2 Discussion
• 2.2.3.3 Consensus Reached on Group Recommendations
• 2.2.4 Secure, Centrally Coordinated Electronic Directory
• 2.2.4.1 Presentation
• 2.2.4.2 Discussion
• 2.2.4.3 Consensus Reached on Group Recommendations
• 2.2.5 Secure Remote Access
• 2.2.5.1 Presentation
• 2.2.5.2 Discussion
• 2.2.5.3 Consensus Reached on Group Recommendations

Preface

On February 19, 1997, in his remarks to the quarterly meeting of the AMG, Mr. Ittielag asked the AMG for its recommendations regarding five areas in which immediate progress must be made in response to Information Technology Central Committee (ITCC) recommendations:

1. Standards for e-mail and document exchange

2. Strategy for a secure networking environment

3. Standards and features for World Wide Web based applications

4. Strategy for a secure, centrally coordinated electronic directory

5. Strategy for establishing secure remote access.

Early in March, the AMG formed five working groups, each focusing on one of the above mandates. This report is the consolidation of the work of those groups. It represents the collaborative work of 42 information technology professionals from 17 institutes who were members of the working groups. Each group defined the need and the scope of the effort; reviewed the alternatives to address the need and any issues involved. Finally, each group developed a series of recommendations (a total of 40) for consideration by the CIO.

On April 16, the working groups presented their findings to the AMG. Although spirited discussions ensued, the AMG generally endorsed all of the working group reports. Given the diverse nature of the NIH and the AMG membership, which represents all 24 institutes, agreement on all of the recommendations by NIH information technology professionals is very significant. It is an indication that the interoperability of information technology systems is critical to the mission of the NIH.

Although not central to the discussion, it was noted several times that the NIH mission is to conduct and support research and that each institute may have unique needs. While some think that standards may be inhibiting, there is another body of opinion that standards actually promote creativity. Perhaps writer Marilyn vos Savant put it best in responding to a concern by a computer technologist that standards tend to stifle creativity: "I think standardization encourages creativity--by providing the framework upon which new developments can be built. For example, without a dictionary and rules of grammar to provide the standards for words and their use, a complex language cannot evolve, without which a complex written literature cannot be cultivated."

Table of Contents

1.0 SUMMARY

1.1 Executive Summary

The NIH, along with many other institutions and federal agencies, is facing a period of reduced funding and a downsizing of the workforce while trying to cope with an expanding workload. Effective management and use of information technology (IT) can help the NIH better support its mission. Toward this end, Dr. Varmus recently took two significant steps: (1) He commissioned an Information Technology Central Committee (ITCC) to provide new organizational and process approaches to improve IT management at the NIH; (2) He appointed Mr. Tony Itteilag as acting Chief Information Officer (CIO) and commissioned a search for a permanent CIO.

At the February 1996 quarterly meeting, Mr. Itteilag spoke about two primary issues. The first concerned the search for a permanent CIO. The second issue, the topic of this report, was to make some immediate progress on the ITCC recommendations regarding information technology, particularly those recommendations dealing with interoperability. He identified five areas in which action was needed:

1. Formulate standards for e-mail and document exchange

2. Develop a strategy for a secure networking environment that includes the Internet

3. Formulate a set of World Wide Web (WWW) standards and features that enable the development of WWW applications across the NIH

4. Develop a strategy for a secure, centrally coordinated NIH electronic directory that logically coordinates directories for e-mail, personnel, parking, etc., and fully implement de-registration activities

5. Develop a strategy for establishing secure remote access as an extension of basic connectivity services.

In response, the AMG formed a working group of IT professionals from across the NIH for each area. Each group further defined the scope of their effort, alternatives that would provide immediate or near-term solutions, issues associated with the alternatives, and recommendations for the CIO to consider. Early on, each group realized there were many overlapping problems, issues, alternatives, and solutions, particularly with security, which was a prime concern of all working groups.

Several key issues and recommendations surfaced:

1. NIH-wide information technology standards and infrastructure should be established. NIH-wide information technology standards will improve interoperability and offer the opportunity to reduce costs, improve support, and reduce development time.

2. Take immediate steps to improve e-mail and document exchange at the NIH. Given that there are several e-mail systems in operation at the NIH, steps must be taken to ensure that the e-mail messages and any attachments to them are readable by all NIH users. The AMG recommends that the NIH adopt MIME as the standard for e-mail transport, and that this recommendation be implemented across all ICDs as quickly as possible. This is a relatively inexpensive action that will provide immediate relief by ensuring correct delivery of attachments. However, document exchange at the NIH--the ability to read documents contained in attachments--is much more intractable due to the use of several word processing products. Selection of a single word processing product which would be centrally funded and supported, and available on every NIH desktop, could improve interoperability and potentially could reduce the costs of document exchange

3. Establishment of the NIH centrally supported electronic directory is a critical priority. While all five areas are related and interdependent, action on recommendations for the central electronic directory and for a secure networking environment is paramount. If consolidated and centrally coordinated actions are not taken immediately, individual institutes will provide their own solutions, which will be more expensive to maintain and will complicate interoperability issues. Further, development and implementation of the directory is prerequisite to the emplacement of network security at the NIH. In addition, the directory must be recognized by all ICDs as the authoritative source for directory information.

4. Implementation of interoperability at the NIH will require an investment. Two working groups (the WWW Applications and the Central Directory groups) did provide a rough estimate of costs to implement their recommendations. However, the definitive costs of implementing the various recommendations are difficult to determine. What is more, the current IT costs at the NIH are not well defined; and without having the costs of the current environment as a baseline, it becomes even more difficult to compare alternatives. While absolute costs of new IT technology required to support these recommendations may not be known, new investments in IT infrastructure standards should reduce the overall IT costs at the NIH.

5. A technical management group should be established to oversee implementation of the recommendations. Implementation of the numerous recommendations must be centrally managed to ensure the appropriate planning, resource allocation, priority setting, and progress are achieved. Four of the five working groups recommended the formation of a follow-on group to carry its recommendations forward. Owing to the numerous dependencies and interrelationships, central management should be provided for the planning, funding, resourcing, and development needed to implement the recommendations. The working groups and the AMG recommend that the CIO designate a Technical Architecture Implementation Subcommittee of the AMG to provide the needed oversight and authority, and to make recommendations to the CIO regarding NIH and contractor staffing and resource needs

6. Immediate action on the recommendations is needed. Finally, there is the cost of inertia--of not taking action now toward implementing these recommendations. The marketplace is changing rapidly, and new technologies are introduced every day. If the NIH is to keep its operational costs to a minimum, action must be taken to put in place the management structure, funding mechanisms, and staff needed for the IT infrastructure (procedures, policies, standards, and technical support).

While there are many difficulties to be overcome, a few immediate positive steps can be taken:

1. Set interim standards and guidelines such as the MIME standard for e-mail attachments.

2. Form a Technical Architecture Implementation group to begin to plan for and resource the actions needed to implement the recommendations.

3. Leverage existing capabilities; for example, endorse PARACHUTE as the NIH-wide dial-up remote access facility.

Other needed actions require long-term NIH executive commitment and resources:

1. Build an NIH electronic directory and implement intranet security using a combination of public key security standards, native NOS security mechanisms, and firewalls.

2. Establish appropriate support and training for IT solutions

3. Build and maintain the NIH IT infrastructure needed.

Another topic, the migration to a single e-mail system, or a reduced number of systems, for NIH-wide use, was also discussed at length by the AMG. While a consensus opinion was not reached at the meeting, the CIO may want to task the Technical Architecture Implementation Group to revisit this topic.

Section 1.2 summarizes the working groups' major recommendations and includes several management recommendations arising out of the April 16 AMG meeting. The relative priorities and specific dependencies for all recommendations have not been determined. However, some recommendations should be acted on before others due to their low cost and high return (adoption and implementation of the MIME standard), or due to the need to set a cornerstone for building or completing other recommendations (the Central Directory is the cornerstone for many of the other recommendations and will require a substantial investment.) Prioritization and determination of dependencies for the remaining recommendations should be one of the first tasks conducted after approval of recommendations.

Section 2 presents a synopsis of the April 16 meeting of the AMG, at which the issues, alternatives, and recommendations from all five areas were presented and discussed. Details about the issues, alternatives, and other recommendations from each working group are available in the groups' individual reports, which are attached as Appendices A through E.

1.2 Summary of Major Recommendations

Note: (n) represents the identifying number of the recommendation from each group. (AMG) denotes a recommendation emanating from the AMG meeting.

2.0 ACHIEVING CONSENSUS

2.1 Introduction

At the February 1996 quarterly meeting, Mr. Itteilag spoke about two primary issues: the search for a permanent CIO and the need to make some immediate progress on ITCC recommendations regarding information technology, particularly those dealing with interoperability. He identified five areas in which action was needed:

1. Formulate standards for e-mail and document exchange

2. Develop a strategy for a secure networking environment that includes the Internet

3. Formulate a set of World Wide Web (WWW) standards and features that enable the development of WWW applications across the NIH

4. Develop a strategy for a secure, centrally coordinated NIH electronic directory that logically coordinates directories for e-mail, personnel, parking, etc., and fully implement de-registration activities

5. Develop a strategy for establishing secure remote access as an extension of basic connectivity services.

In response, the AMG formed a working group for each area comprising IT professionals from across the NIH. The hurdles to be overcome in finding solutions and achieving interoperability are substantial. This is particularly true in the NIH IT environment, in which individual institutes--rather than a team of institutes--often commit labor and funds to solving IT problems that are common across the NIH. In addition, the funding needed to support the objective of interoperability must be considered. Downward budget pressures will continue to be the norm; therefore, information technology solutions must be evaluated for their immediate or tactical benefit as well as their strategic or long-term benefit.

Within the time provided, each working group, mindful of the need to develop recommendations that would not only yield immediate results but would also provide a solid foundation for building the infrastructure needed for the future, defined its goals and set the scope and objectives for its efforts. The groups established objectives that were both tactical and strategic; each group focused on near-term progress and realistic solutions to burning problems while staying attentive to the longer-range implications of the solutions chosen. Then the feasible alternatives were identified and analyzed. During this analysis, numerous technical and management issues were identified. While non-technical issues often surfaced, the groups remained focused on the technical solutions and steps needed to implement them. Finally, recommendations for CIO consideration and action were forged.

Early on, each group realized there were many overlapping problems, issues, alternatives, and solutions, particularly with security, which was a prime concern of all groups. To ensure each group's efforts were not duplicated or in conflict with each other, the groups were cross-pollinated with members from other groups. Each group met as often as possible, given the diversity of membership and schedules. In all, the groups met 21 times over 5 weeks. In addition, the working group chairs met every 2 weeks to ensure the efforts were coordinated and on track. All groups documented each meeting and shared the results with all other groups through e-mail and postings to the AMG Working Group Intranet site.

2.2 The Process

The path to consensus included an all-day meeting of the AMG on April 16. Each group presented their findings, issues, and recommendations for AMG consideration. The objective of the meeting was to offer a forum for full and open discussion of the working groups' recommendations and to achieve consensus on them. The presentations evoked lively discussion from members, and many points of view were raised. Following each presentation, a facilitated discussion was held to ensure full understanding of the issues and recommendations and to determine if the AMG could reach consensus on each group's recommendations. The AMG reached general consensus on working group recommendations. These recommendations are included at the end of each group's report in the Appendices. A summary of the meeting follows.

2.2.1 E-Mail and Document Exchange

2.2.1.1 Presentation

The working group presented its findings and recommendations. More time was allotted to this presentation owing to the divergent views and interest in the topic. This working group presented the following issues and alternatives:

1. Given the heterogeneous nature of the NIH and the reality that individual institutes have already implemented various e-mail solutions, the focus should be on adopting standards rather than recommending a single product.

2. To improve interoperability, issue a directive from the CIO defining adequate minimum levels of accepted standards and technologies for desktop computing; provide the standards and technologies to ICDs who do not have the needed resources.

3. Each ICD should migrate to a single e-mail architecture within its institute and provide a single point of contact for support.

4. Each ICD must support its e-mail resources at the same level as NIHnet, i.e., 24 hours of support, 7 days a week.

5. The evolving e-mail standards for communication via the Internet must be tracked and may provide solutions to current interoperability problems between different platforms (MAC and PC).

6. E-mail must be secure.

7. Two dominant word processing products have emerged at the NIH as "standards": Microsoft Word and Corel's WordPerfect. Selection of a single word processor would achieve the greatest level of interoperability, but it is uncertain that this is an achievable goal at the NIH, given the investment and commitment accrued for both products. Support and training would also be an issue if a single product were selected. There is no simple solution for guaranteed interoperability between these two products. Possible solutions include the use of 3^rd party viewers, which would increase IT costs and support, or use HTML 4.0, the format used for web publication, if it becomes as feature-rich and robust as the word processing products.

The group then presented its recommendations.

2.2.1.2 Discussion

The main discussion issues were as follows:

* While the e-mail working group principally focused on tactical approaches that would produce immediate results, it nonetheless included the strategic recommendation to "explore the feasibility and cost to reduce the number of e-mail technologies and architectures across the NIH." This generated a spirited discussion, in which some AMG members supported immediate aggressive action to reduce the number of e-mail systems. No consensus emerged on this topic.

* Document exchange, a particularly complex issue because NIH commonly uses two word processors, also engendered lively discussion. In ICDs that have good network and application support, exchange of documents is not a serious problem. However, exchange between staff of other ICDs or staff of different ICDs, exchange is more problematic. While, in many cases, each of the two common word processors can read documents produced by the other, this situation is not uniformly true across all desktop computer platforms at the NIH. Worse yet, it's not uniformly true even among different releases of the same product. One alternative presented by the working group involved 3^rd party viewers that must be purchased, installed and supported on every NIH desktop. During discussion, an additional alternative was suggested--a single word processing product that would be centrally funded and supported. It would not be mandated for use, but over time, some felt users would naturally converge on it as the preferred product, since it would be on every desktop and would be centrally funded and supported. ICDs could continue to use a different product (i.e., two products on each desktop), but the centrally provided product and support would still be available to users. Another alternative that arose during discussion envisioned a central document conversion group. Documents would be sent to the group and returned in a format readable by the sender. This alternative could be in place of or in addition to other alternatives.

* Should e-mail recommendations be expanded to include such additional business functions as calendaring and workflow management? Again the focus of the working group was tactical and short-term in nature. Additional functions such as calendaring should be evaluated by the recommended Technical Architecture Implementation Subcommittee.

* Concerns regarding support and training for e-mail and document exchange were raised often. Users need to be able to get quick, reliable support and answers to their questions. They may not care which product is used. In addition, they must be trained to use the product effectively.

* The individuality of NIH institutes and the focus on research were discussed. While institutes do have unique needs, common IT solutions are still possible and advised.

* Funding concerns were raised. Many ICDs do not have the money it requires to stay current with product releases, which may make it difficult to sustain the currency recommendation. Consensus was reached that money is an issue and that most recommendations include a cost.

2.2.1.3 Consensus Reached on Group Recommendations

All of the working group's recommendations were approved by the AMG for consideration by the CIO:

1. Explore the feasibility and cost to reduce the number of e-mail technologies and architectures across the NIH.

2. Explore the feasibility, desirability, and cost to implement a single product solution for word processing software across the NIH.

3. Adopt MIME as the transport standard for e-mail and mandate compliance by a specific date.

4. Establish a permanent e-mail management and coordination body of the AMG, along with a technical team capable of implementing solutions and providing rapid problem resolution.

5. Establish an ongoing NIH-wide desktop standards review for determining minimum levels of hardware, software, and support. Provide a mechanism to ensure standards are adopted within the ICDs.

6. Establish ongoing sunset dates for outdated releases of e-mail and word processing software.

7. Empower DCRT to provide timely e-mail and LISTSERV services to ICDs on request, with charges levied as infrastructure costs.

An example of the type of outcome that might arise from the second recommendation is adoption of the proposal that arose during discussion at the AMG meeting to adopt a single word processing product that would be centrally funded and supported for NIH-wide use. However, it was noted that improving document exchange within NIH does not resolve problems of document exchange with people outside of NIH, who may be using different products or versions of products.

2.2.2 Secure Network Environment, Including Intranets

2.2.2.1 Presentation

The working group presented the group's findings and recommendations. Given the mandate to this group to "define a strategy for a secure network environment including Intranet," the group offered a definition of an Intranet. An Intranet is "an environment of network and computing tools based on those used in the global Internet that is isolated from or connected in a controlled way to the global network and is generally not accessible from the Internet at large." The appropriate level of security must be provided to:

* Permit public access to non-sensitive data with assurance that it came from the NIH

* Permit extramural business partners to have authorized access to sensitive data

* Protect NIH sensitive data.

2.2.2.2 Discussion

The group's recommendations were presented and discussed. The main points were as follows:

* The group expressed concern regarding preparation of the various security plans and the issue of whether education or support for formulating the plans would be provided. The group felt consultation assistance should be provided. The ISSOs are working to provide this assistance.

* The group expressed concern about how security will be funded and acknowledged that an organization that cannot afford appropriate security should not place sensitive data on a server. The group reiterated that sensitive data must be secured.

* The group included personal web servers, in addition to departmental or ICD servers, in their recommendations.

* Authentication is a technical issue as well as a management and control issue. The group cautioned against underestimating the costs required to manage and maintain a central authentication service.

* The group was interested in how authentication will be enforced, expressing the opinion that the NIH security plan should address the issue, or that action by the CIO may be needed.

* The group agreed that credential issuance should extend to NIH business partners.

* The group felt that other technologies, such as smart cards, are not prohibited as a means to support certification.

2.2.2.3 Consensus Reached on Group Recommendations

All of the working group's recommendations were approved by the AMG for consideration by the CIO:

1. Develop an NIH web policy addressing the purpose, appropriate use, and definition of security standards.

2. Implement the NIHnet Security Plan, due December 1997.

3. Continue ongoing NIH education on computer security awareness and standards.

4. Review and assess general support systems' security on a recurring basis.

5. Implement Intranet security using a combination of the following:

a. Public key security based on standards such as X.509 and SSL to provide digital signatures, and mutual authentication and privacy between web browsers and servers

b. Native security provided by network operating systems (NOS) to secure non-web based-applications and web server network access to file and database servers

c. Firewalls to block network access via methods not protected by public key or native NOS security.

6. Establish a central authentication service that uses public key or shared secret key security standards and provides electronic credentials for all the NIH workforce.

7. Establish a central registry for web and other types of network servers that includes ISSO-approved security plans and security monitoring and auditing plans.

8. Designate a group to develop public key certificate policy and coordinate public key certificate authorities, NOS security registries, and directory services. The certificate policy must define the way in which public key certificates are issued and maintained and must specify that credentials issued will carry a unique personal identifier assigned to each person in the NIH, and that servers and applications must be able to access certificates through use of AMG approved standards.

9. Establish central Intranet services at DCRT as part of the infrastructure. Minimum security standards apply to the centrally maintained and all ICD Intranet services.

10. NIH ISSO may allow exceptions to published NIH Intranet standards given acceptable justification.

2.2.3 World Wide Web Based Applications at the NIH

2.2.3.1 Presentation

The working group began by reviewing the group's mandate, membership, and existing web policy guidance provided by DHHS and NIH, which the group found reasonable. They then presented detailed findings, issues, and recommendations in three areas: application development, server issues, and crosscutting issues.

Application Development Issues

The group recommends that NIH standards and practices for web development be based on market trends using an algorithm that defines a "standard" set of browsers based on market share. A recognized authority would be found to make the market share determination, and this picture of the market place would be reviewed every 6 months. Reliance on browsers defined in this manner will keep pace with the rate of change of web products and focus on the process of product selection, not on a static set of approved products. The browser community consists of three groups: controlled audience (users within individual ICDs where support and applications are controlled and managed by the ICD), trans-NIH, and the general public. The first group, controlled audience, due to its parochial nature, was excluded from the group's consideration.

The second group, trans-NIH, was defined as the set of browsers that can be expected to be on every NIH desktop, which is required as the basis for new web application functionality. This will allow for quicker use of the latest technologies and provides application developers a known target for development. Availability on the desktop can be influenced by NIH management as well. The third group, the general public, requires a browser that the NIH can assume the general populace is using.

The standard set of browsers will be identified as the family of browsers that constitute the leading 85 percent of market share based on data provided by an authoritative source and will be based on the application's target audience (trans-NIH or public). Production releases of applications will provided for browsers released within the past 6 months for trans-NIH audience and within the past 12 months for public audience. The standard set of browsers may be influenced due to the need to accommodate various platforms and operating systems or in response to NIH, DHHS or federal policy guidance. The need for using non-standard browsers will be handled on a case-by-case basis.

Applications developed for use on the web should only use the Hyper Text Markup Language (HTML), applets, database access capabilities, and security features found throughout the standard family of browsers. Applications should also be tested with all of the browsers in the standard set. Today's set of standard browsers was based on data gathered from the "Browser Statistics Usage Page of the University of Illinois at Urbana-Champaign (UIUC)." Browsers for trans-NIH applications include Netscape Version 3.0 and higher and Microsoft Internet Explorer Version 3.0 and higher. Browsers for general public applications include Netscape Version 2.0 and higher and Microsoft Internet Explorer, all versions.

Server Issues

Web-based applications are becoming critical to the business of the NIH; therefore, servers should comply with all guidelines in the DHHS Automated Information Systems Security Program Handbook.

Crosscutting Issues

Robots are useful web-based applications that can adversely impact some web servers. Search engines are needed for indexing and retrieving web content, and their selection and use must also be considered. Finally, high bandwidth applications must be carefully analyzed to ensure their use does not overload the network. These issues are discussed in detail in the group's report.

The group also discussed estimated costs required to build the NIH web infrastructure. Given that browsers would be purchased for all desktops by June 1998 and that end user training and support would also be in place, the estimated funding need for FY 1998 is $550,000 and $230,000 each year thereafter for maintenance. These are only estimates. More detailed analysis is needed to further refine the funding estimates.

The group concluded their presentation with three points:

* The WWW is vital to NIH's IT future

* An infrastructure is needed for web-based applications

* NIH management awareness and support is required to take advantage of today's window of opportunity.

2.2.3.2 Discussion

The main points were as follows:

* What is the relation between the AMG Web committee recommended by the working group versus the existing NIH Web committee? The AMG Web committee will focus on technical and architectural issues; the NIH Web committee will handle web content and administration. The group agreed that close coordination between the two committees is required. It was suggested that an AMG representative be on the NIH committee. The point was made that the area of WWW standards and policies is an ongoing process requiring frequent review.

* Why not select a single browser for NIH? Issues such as incompatibility between the HTML generated by browsers are not trivial; selection of one browser may be premature, given the market dynamics.

* The extension of the WWW recommendations to include web plug-ins was raised. After some discussion, the group agreed that plug-ins would not be included.

* Concern was expressed, and the AMG agreed, that "controlled audience" needed to be better defined.

2.2.3.3 Consensus Reached on Group Recommendations

All of the working group's recommendations were approved by the AMG for consideration by the CIO:

1. Adopt the use of Web technologies as the "client/server" architecture of choice "for new NIH applications."

2. Act to ensure that on and after June 1998, all NIHnet connected desktop systems include a fully functional, standards compliant web browser.

3. Act to provide adequate employee training and support for the use of web browsers no later than June 1998

4. Create a standing AMG Web Committee to track technology, and update standards and policies as needed.

2.2.4 Secure, Centrally Coordinated Electronic Directory

2.2.4.1 Presentation

The working group expressed a need for a centrally coordinated electronic directory that is the one source for directory information at the NIH, that is used by people to look up information, and that is used by machines to coordinate NIH-wide systems. The requirements for this directory include extensibility, security, authority, human readability, and machine readability.

"Extensibility" means that new types of resources and their attributes can be easily added or changed. "Security" requirements include definition of who can view the information, who can update it, what information may be updated, and how linkage to public key certificates is defined by the Secure Network Environment Working Group. "Authority" simply means the directory should be the only definitive source for keeping this information.

The directory must also provide information that is easily accessed, searched, and available in simple-to-use "white pages" manner. Humans as well as machines at the NIH need to access this information; therefore, the information must comply with open standards and be available for synchronization with other information systems.

There are issues surrounding the maintenance, attributes, updates, and management of the directory. Maintenance issues include the method or procedure appropriate to delete people from the directory and to move people between ICDs. Issues with attributes include defining the types of resources that should be included in the directory, how should they be described, how changes to them will be managed and controlled, and how updates to the directory will be accomplished to ensure accuracy and currency. Finally, management issues regarding flow of information between the directory and the ICDs must be resolved. Will information be "pushed" from the ICDs to the directory, or vice versa?

2.2.4.2 Discussion

The group's recommendations were then presented and discussed. The main points were as follows:

* While the Lightweight Directory Access Protocol (LDAP) and X.500 are included as standards for the directory, more standards must be identified and analyzed for use during the design and build of the directory.

* The scope of the directory and whether it will also contain information about NIH business partners was raised. Basically, the directory will include those who use NIH resources.

* Concern about the ability of NIH to implement this directory in a timely fashion and at what cost was raised. Optimism was expressed as to the probability of quick action and delivery. The infrastructure needed is basically in place and additional costs would be minimal; however, the definition of the attributes of the directory, control mechanisms for updates and deletions, development of policies and procedures for use and the actual design, development and implementation will require a significant investment in time and dollars to complete. A suggestion was made to construct an initial "working model" of the directory for review by all ICDs which might help to reduce the time needed to reach agreement on the functionality and design issues. Also, the time and resources needed for the conversion and verification of data in existing data stores for migration to the directory may be significant. The cost estimate developed on behalf of the working group by Performance Engineering Corporation was approximately $2M. The estimate only included costs for the requirements definition, design, development, and implementation. Estimates for the conversion and verification of existing data and population of the directory with needed information as well as any additional infrastructure costs were not included. While the estimates for this recommendation appear to be expensive in relation to other groups' recommendations, there was strong agreement by the AMG that work on the directory must move forward as quickly as possible. If prioritization of recommendations must occur, then the directory recommendations should be moved to the top of the list. The directory will provide the foundation for many of the recommendations made by the working groups, particularly with the secure network environment and e-mail recommendations.

2.2.4.3 Consensus Reached on Group Recommendations

All of the working group's recommendations were approved by the AMG for consideration by the CIO:

1. LDAP should be used as the protocol for accessing directory information It has wide industry support and provides a strong basis for the directory.

2. Unique personal identifiers (not the SSN) must be defined. This will allow integration with systems based on relational databases. Formats to be used must be defined.

3. Declare directory presence a prerequisite for NIH services. This will help ensure the accuracy and currency of the information because presence in the directory will be required before other NIH resources can be used.

4. Establish functional and technical working groups to proceed with implementation. The functional group will develop user requirements and attributes for the directory; the technical group will design the system and carry forward its construction, test, and implementation. Cross-representation by ICDs is desired.

2.2.5 Secure Remote Access

2.2.5.1 Presentation

This group was directed to "develop a strategy for establishing secure remote access as an extension of basic NIH-wide connectivity services." The group first defined the types of users requiring dial-up remote access to NIH systems. Remote users include travelers, telecommuters, and flexiplace workers. The requirements include the need to provide secure dial-up remote access; dial-up remote access must be economical to implement and support, and it must allow for growth and extensibility. Based on these requirements, the group defined a strategy that:

* Leads to a rapid, low-cost implementation of dial-up remote access

* Satisfies most, if not all, requirements identified

* Provides a short-term solution leading to a longer term capability.

The group considered several alternatives, including establishing a centrally provided dial-up remote access facility, allowing individual ICDs to provide dial-up remote access to their systems, and using a commercial provider such as Erol's. The group recommends the first alternative be selected and that PARACHUTE be the centrally provided dial-up remote access facility for the NIH. PARACHUTE is an existing service provided by DCRT. It offers remote node service in which the remote PC performs all workstation processes (common for e-mail access). At the ICD level, PARACHUTE could support remote control access in which the remote PC performs as if it were actually attached to the LAN.

Several issues were discussed. First, the security provisions in the current PARACHUTE were designed to only prevent misuse of the dial-up remote access facility to the NIH, not to provide end-to-end security for the information available through NIH's local area networks, servers, mainframe or applications. Improvements in prevention of misuse include:

* Add account aging or active deregulation

* Add a provision for password aging

* Place appropriate controls on session length.

In addition, there is an effort under way to develop a security plan for PARACHUTE. This could form the basis for the security requirements for alternatives to PARACHUTE. There was also an issue regarding the ability of PARACHUTE to meet all dial-up remote access needs. The working group determined that PARACHUTE can provide basic dial-up remote access to the NIH backbone. Individual ICDs can provide remote control access using the PARACHUTE facility. In addition, the group felt that PARACHUTE use should be promoted but not mandated, and that it should continue to be funded through the NIH network charge.

2.2.5.2 Discussion

The group's recommendations were presented and discussed. The main points were as follows:

* Some members of the AMG expressed concern about the performance, difficulty of set-up, and reliability of PARACHUTE. Other members agreed that set-up procedures might be improved. A suggestion to perform an assessment of PARACHUTE as part of a user requirements definition process was offered.

* The enforcement and implementation of security for dial-up remote access to the NIHnet would be easier to manage at a central point rather than at multiple locations.

* The need for support for PARACHUTE users was also raised. If a central facility is to be provided and funded by all ICDs, then support must be provided.

* In addition to the recommendation from the working group, the NIH Telecommunication Committee is also likely to recommend PARACHUTE for use as the central dial-up remote access facility.

* The consensus of the AMG was that PARACHUTE will meet the basic requirements for dial-up remote access, but management controls are needed, including, for example, security improvements and processes for access approval. The security plan being developed for PARACHUTE should address these issues.

2.2.5.3 Consensus Reached on Group Recommendations

All of the working group's recommendations were approved by the AMG for consideration by the CIO:

1. Adopt and promote PARACHUTE as the preferred, although not mandated, NIH means for dial-up remote access to on-campus systems and the Internet.

2. Assess PARACHUTE security, and make necessary changes to accommodate the assessment.

3. Continue to plan, monitor new technologies, configure, operate, and fund a central dial-up remote access facility as an integral part of the NIHnet.

4. Develop the minimum security requirements for dial-up remote access to NIHnet. ICDs that provide their own remote access in lieu of using PARACHUTE must meet these minimum security requirements.

5. Establish an ongoing review by the AMG or a designated subcommittee of remote access technologies to keep current with the marketplace and to minimize costs.