A Case Study in Technology Transfer of Collaboration Tools

Published in the June 1998 issue of The Edge

MITRE has brought the Collaborative Virtual Workspace (CVW) prototype to a Defense Department intelligence organization to refine intelligence analysis. Every year this organization runs a Intelligence Crisis Exercise called ICE. Until CVW, preparing for ICE meant dedicating a physical situation room and installing network drops, power, furniture, workstations, and servers. It also meant that people joining the exercise had to move away from their offices and lose time from their normal intelligence jobs.

MITRE and the intelligence organization's crisis management team configured CVW to fit a new concept of operations. CVW linked analysts with technical and operational specialties from seven offices without relocating anyone. That made it possible for the crisis management team to get other analysts to join ICE by promising to leave them in their own offices and have them participate virtually.

The attraction of conducting ICE virtually swelled the size of the crisis team to two 12-hour shifts with 60 analysts each. What had been considered a difficult task became a chance to have fun with intriguing technology at a low cost. Some managers wanted a live briefing at every shift change. We were able to install a CVW terminal in the crisis room and use it to link the crisis team into the briefings, which meant that the briefings quickly grew to include all related offices.

Suddenly the senior briefer had a broad range of expertise available at a moment's notice to answer any questions. In addition, the analysts could now hear how their intelligence product was being used by decision makers, thus helping them refine their work. That became very important to some analysts, who would otherwise wait years before being able to listen to a high-level briefing. The decision makers directly addressed their concerns to the analysts, thereby circumventing the old organizational hierarchy.

The document sharing and exchange mechanism of CVW enabled teams of analysts to shorten the time spent coordinating product reports. The virtual teams left their inputs in virtual rooms to be coordinated by a team editor. The editor combined the inputs into a draft, which the team members could read, while discussing it in an audio conference. Through the benefits of CVW, the intelligence organization transformed its ability to manage information flow during crisis operations.

The experience of transferring the technology of Collaborative Virtual Workspace spawned a number of new requirements for linking new elements within the organization and other agencies. The community of interest supported in the crisis exercise now has no fewer than eight separate agencies, CINCs, or commands linked to their virtual environment worldwide. The senior analyst for the crisis group became a major spokesman for a new way of conducting crisis operations and has helped raise the visibility of collaboration technology across the entire intelligence community. The movement into the virtual world has not been easy, nor is the transition complete. In the process to date, however, many cultural norms, policies and infrastructures have been challenged. These challenges are discussed in the next section.

Cultural Issues - Collaboration is not a Bad Word
The pilot organization has encountered numerous cultural barriers to conducting operations in a virtual setting, from having to define new ways of assigning credit for reports, to finding ways to keep middle level managers involved, to overcoming a historical predisposition to protect information rather than sharing it.

The analysts have always strained against the restrictions to gather information from whatever source possible, including their counterparts at other agencies. The provision of an online conferencing and document exchange tool has raised the possibility of sharing selected information, interim analytic results, working aids, and final product among the staff across agency boundaries. This is revolutionary and has opened many new questions, including:

While some questions have been answered as a result of the collaboration pilot experience, other questions are unanswerable. In many cases, the old business processes cannot be re-mapped into a virtual world, and should not. Some tasks will no longer be needed as their function is taken over by an online system. Some mid-level managers are real barriers to productivity, and virtual teaming only highlights this fact in high contrast.

Challenges to Technology Transfer
When the pilot community began its journey, it was already clear that there were many technical issues to address in making collaboration technologies fit into the computing and networking infrastructure. What was not clear, however, was the extent to which these and other issues would require the organization to undergo a cultural shift. The technical issues encountered centered on the desktop environment and the network substrate.

Desktop Computing
The organization has standardized its desktop on UNIX, but has many flavors of UNIX (SunOS, Solaris, SGI, AIX) in place across its elements. In addition, there is a growing contingent of Windows NT workstations as offices begin evaluating the potential of migrating toward NT. As the organization progresses forward to an enterprise collaboration infrastructure, it will do so with the requirement for multiplatform support.

Audio Conferencing
None of the analysts' systems had microphones because they were removed from the desktops in order to comply with an unwritten and undocumented security policy against the use of microphones in operational spaces. It took several weeks to dispel this myth, find the microphone caches and redistribute the microphones back to the users. The policy had at its origin a fear that the microphones could be remotely enabled across the network to eavesdrop on operational spaces. There is some truth in the observation that under UNIX devices can be remotely enabled, but root access to the desktop involved would be required. The use of microphones was approved for the analysts.

Networks
Because of the mature computing environment at this organization, there also exists an equally mature and comprehensive campus-wide network infrastructure that provides at a minimum, a 10 Mbps Ethernet to every desktop. In addition, there are many high-speed connections to affiliates located across the country and the world. Without these investments, the organization could not have attempted to use collaboration technology in any meaningful way. As the organization upgrades their local area networks (LANs) to fiber, and then to asynchronous transfer mode, bandwidth concerns with collaboration technology will become less of an issue.

Bandwidth
One of the fears network administrators faced when introducing collaborative virtual workspace (CVW) into a new LAN was that the collaboration and conferencing tools would bring the LAN to its knees because of increased load. This fear was addressed by examining the sources of network loading. Since the decision was made to disable video conferencing, only three sources of bandwidth use needed to be addressed: audio, chat, and document exchange.

The organization has institutionally limited the installed audio conferencing tools to use the GSM (Global System for Mobile Communications) encoding scheme, which requires 17 kbps during transmission. In addition, all users are trained to use the "push-to-talk" mode in the audio tool, so that network bandwidth is utilized only when the analyst intends to speak to others. The pilot experience showed approximately 10 percent of the on-line users had their audio tool enabled in an active conference. Most LANs were able to absorb this kind of traffic without noticing its presence.

The text chat tool generates much less traffic, measured in tens of bits per second.

The document exchange interaction generates more traffic, but it is in bursts, as users import or open documents to/from the document server. This traffic can be compared to the use of a Web browser, as it is based on the same HTTP protocol. In the pilot organization, the files used by analysts within CVW are usually small documents, not large binary files. There are exceptions, but most are text notes, smaller image files or desktop publishing files.

Early on, the network administrators set up several LANs and ran network loading tests with and without CVW for one week. The results showed minimal increases in network loading because users are mostly single-threaded, performing one network operation at a time. While they are collaborating with others, they are not actively downloading Web pages, reading email, chatting over IRC, or using other network services.

Managing Multicast
The organization has a wide range of router hardware in place. Some of the routers were installed well before IP (Internet Protocol) Multicast was defined as an IETF (Internet Engineering Task Force) standard, and others have varied levels of support for IP Multicast. In all cases, none of the hardware routers were enabled to route IP Multicast.

A virtual Multicast network (MBONE) was constructed and managed for the CVW participants. Initially, multicast connections (tunnels) were established by linking offices that needed to talk with each other. Later, concerns arose that constructing an MBONE based on community membership was inherently inefficient, and a physical network survey was conducted to ensure that the virtual multicast network was not violating any obvious limitations in the physical network topology. Several instances of "doubling back" on connections in the MBONE were discovered and corrected. Understanding the network topology and its usage is critical to building an efficient and stable MBONE.

Challenges to Collaboration and Security
There were three main security concerns with CVW use in operations: audio security, classification marking of rooms and document security. The concerns arise from limitations of the current technology, and should be treated as requirements for a collaboration infrastructure, based on CVW usage experience.

Segmenting Multicast Addresses Used by CVW Buildings
The security administrators wanted to ensure that staff working in one CVW building did not hear audio from another CVW building. To address this concern, a study of IP Multicast segregation techniques was conducted, and multicast boundaries were implemented to segment CVW communities of interest (COIs) by multicast prefix. This means that for Target Community A, the multicast packets would be prefixed with a unique address group and access code for each community so no one has to resort to snooping the packets. The main concern was privacy, not security per se, since the participants were running on a secure network. With the rapid expansion of CVW virtual buildings within the organization, there are now 10 separate multicast group segments all riding over the same MBONE.

Audio Conferencing "Lurker" Issues
Because the IP Multicast protocol is a broadcast protocol, it sends data across the Multicast network, potentially into LANs where there are no active subscribers. It is possible to intercept the signals and "lurk" in an audio conference if one knows the multicast address of the conference. Obtaining this address without approval would require illicit means. The organization approved the use of multicast within its internal network, because the audio conferencing tool provided no unique opportunity for "lurkers" that was not already present in the agency's e-mail, FTP, Web, or any other network service. However, the use of multicast-based conferencing with other networks (e.g., through the firewall) remains a security issue until security safeguards become available.

Observing Classification Levels in a Virtual Environment
The concern of how to handle classification levels in a virtual environment is a valid concern that has not yet been adequately addressed. In CVW, the room-locking capabilities have been employed to restrict access to rooms and floors based on a "need-to-know" criterion. Security administrators would like to see a clear statement of the virtual room's classification level to advise the participants in the conference as to the highest level of classification the room can support.

There are two requirements implied. The collaboration environment should be able to access and act upon the clearance information of the users. In addition, virtual rooms need to be dynamically marked with the aggregate classification level of all the participants (or documents) present in the room, as it changes, to keep the user informed of the active security level. Policies and models need to be identified for the use of security classification levels in virtual environments.

Document Security
In the present CVW, access to the persistent documents is controlled by access to the rooms that house the documents. This model did not satisfactorily support the requirements of the analysts.

The security staff have identified a requirement for a model that reflects a document-level access control that is more consistent with the current physical control policy. In addition, the network is permitted a specific classification level. There are many instances where analysts wish to share material at higher classification levels among themselves. The security policy requires that they encrypt such material in storage, pass it encrypted (via FTP, Email, or Web), and then decrypt only at the workstation.

Technology Transfer Strategies Learned
The following strategies were identified by the Department of Defense as having been learned through the bittersweet experience of deploying and supporting collaboration technologies in their operational settings:

Conclusion
The last two years have been a wild ride as this organization encouraged, facilitated, cajoled, embarrassed and used any other means within their reach to implement an 80 percent collaborative technology solution. We have learned that technology transfer is not largely a technical activity, but rather a human or organizational one. Without a doubt, technology must support the mission and be shown to be efficient, state-of-the-art, and capable. But, technology transfer, in the long run, depends on persistence. In many cases, resistance to change has to be simply outlived and worn down.

The collaboration pilot experience in this organization is moving in a new direction as the agency helps to sponsor the migration of the collaboration technology into a true enterprise model. Such an Enterprise Collaboration Architecture will support federations of collaboration contexts, universal authentication services, defensible and supportable security services, alternative document and data services, activity logging services, and a host of other enterprise services that will integrate collaboration technology as part of the agency's baseline set of information services.

As they move toward that enterprise model, the technology-centric issues will become more important and central to the process. But the hardest challenge has been establishing an operational business case and applying existing technology.

Published in the June 1998 issue of The Edge MP980000087-01
http://www.mitre.org/pubs/edge/