
Academic Computing Vulnerabilities: Another View of the Roof
Added by the EDUCAUSE Librarian
Good Ideas
Academic Computing Vulnerabilities: Another View of the Roof
A faculty-driven audit offers a complementary perspective on network disaster planning
"The time to repair the roof is when the sun is shining." —John F. Kennedy President Kennedy's 40-year-old quotation is as timely as ever when applied to academic network failures. In anticipation of Y2K, and later as a result of heightened security concerns following the events of September 11, 2001, numerous colleges and universities developed formal planning documents to guide their responses to unexpected network outages. Typically, vigilant institutional financial auditors or information technology directors initiate campus-wide crisis planning efforts. The University of Pittsburgh similarly maintains an updated Y2K-derived plan, and, like many academic institutions, enjoys a reliable and stable computing environment. Recognizing, however, that unanticipated network outages can seriously interrupt business functions, the university also initiated a faculty-driven audit to identify the potential effects of network failures on academic functions. As a result of what we learned from this initiative, we suggest that other institutions may similarly benefit from integrating two complementary approaches to network disaster planning. The ChallengeThe University of Pittsburgh's Computing Services and Systems Development (CSSD) provides computing support, development services, telecommunication services, and the information infrastructure necessary to the educational, research, and administrative activities of students, faculty, and staff. CSSD also provides significant and ongoing support to individual units, a commitment articulated in the university's technology plan: The existing departmental support model recognizes the need for centralized and distributed information technology resources to support the implementation of technology-related initiatives throughout the university. Departments receive assistance through the services of the Help Desk, Contract Support, Training Services, and the Expert Partners programs.1
The challenge arises as follows. At the University of Pittsburgh, as is typical for large research universities with multiple campuses, schools, departments, and centers, it is not unusual for local units to hire and maintain their own IT staff and establish local servers to run specialized computing labs, departmental research, and other functions. This has resulted in many local IT configurations (some in geographically distant locations), each with a need to fully protect essential business functions to avoid costly system failures. Thus, like many universities, we were faced with a computing architecture that appeared to require an additional, complementary approach to self-study. The challenge of systems disaster planning for an amalgamation of central and localized academic computing infrastructures is analogous to crisis management planning for public roads that span a large metropolitan area, with federal, state, county, and local governments each maintaining its respective roadway. The stakes become high when the economic vitality of the larger region is unexpectedly threatened by unrecognized vulnerabilities within critically situated local roadways. The same interdependencies may occur within large university systems. Each of these environments requires a high degree of internal information sharing and coordination to anticipate and manage emergencies. There are also cultural challenges inherent in any academic system. Both the business of universities and supporting information systems occur in juxtaposition with academic cultures that have evolved over hundreds of years, research-based imperatives that drive institutional excellence, and a competitive admissions marketplace. Thus, critical timing factors unique to academic institutions, if subject to disruption, can cause expensive business losses. For example, system failures at inopportune times could prevent completion of multi-million dollar grant applications, disrupt and even negate time-dependent research protocols, and prevent prospective graduate students from submitting deadline-dependent electronic applications. While these major issues were obvious to all, upon further discussion we began to discern less obvious vulnerabilities that we needed to take into account. Indeed, systems disaster plans may not reveal the subtleties of academic computing vulnerabilities within each of the diverse units of a large research university. Why might such be the case for plans developed with university-wide representation? It is natural for planning efforts to focus on central technical functions—how system-wide outages might occur, be prevented, and/or be corrected. The brightest beams shine on the largest systemic vulnerabilities for valid reasons: in the absence of back-up systems, a power outage in a major university computing facility could have far-reaching negative consequences. Therefore, centrally driven plans must concentrate on "the big picture." Extending President Kennedy's example, we must first view "the roof" from above. Yet, if called upon, those inhabitants of academic subunits who live beneath the roof will likely be able to contribute new and valuable information. They will be able to uniquely identify what parts of their local computing infrastructures system are the most vulnerable to disruptions and identify where "leaks in their roof" could result in the most serious damage. The ProcessThe University of Pittsburgh decided to initiate a faculty-driven audit to more fully discern the potential effects of network failures on academic functions. Before this process was initiated, the university considered the costs and benefits of several approaches. Approaches Considered and RejectedThe first option proposed was to engage a consultant to audit local academic computing environments. This was deemed an unnecessary expense given the available internal expertise. A second option was to ask the director of CSSD to assign members of that staff to conduct an audit. This option was rejected so as not to divert that staff from their specialized functions when other options existed. A third option was to seek the assistance of the Expert Partners Program, a group of systems analysts and other information technologists who supply computing support on the local level. The Expert Partners Program …was developed to provide assistance to departments with support personnel responsible for providing day-to-day computing support. The program is devoted to building strong, positive relations between central and departmental support staff by providing in-depth access to technical resources. Individuals participating in the program have access to electronic resources, technical meetings, a Web site with technical information and links, a group discussion area, and an array of training for applications and University network services.2
While many in the Expert Partners group were ultimately called on to contribute to the reports, we decided that a faculty-initiated project would most fully assemble the nuances related to customers' perceptions of academic computing. Approach ChosenThe concept of an academically driven audit process emerged from faculty discussions in the provost's Council on Academic Computing (CAC),3 a committee chaired by the vice provost for research. The CAC was established in December 1999 "to provide guidance to the Provost regarding academic computing issues; specifically by recommending priorities and policies, and reviewing proposals in the areas of network services, acquisition of instructional software, and development of specialized facilities." The committee consists of 23 faculty members, most appointed by their deans. Committee members represent the arts and sciences (3); health sciences (5); professional schools (6); and regional campuses (6). In addition, faculty members serve from the university senate's Computer Usage Committee (2), and the committee includes the director of CSSD. The CAC is led by a tenured faculty member who is a high-level administrator in the provost's office. The CAC meets monthly to foster intra-organizational communication, seek new opportunities, recommend policy, and engage in problem solving. The CAC maintains ad hoc working subcommittees, which in 2002–2003 included the high-performance network computing initiative, faculty training, the future of academic computing, and the faculty portal. In 2001, the Subcommittee on Systems Failures was formed within the CAC. The group was charged to detail instances of past and potential network computing disruptions across mission-critical academic units at the University of Pittsburgh. At the request of the associate vice provost who serves as the CAC chair, the deans and directors of major academic units each identified an individual within their organizations who could describe the effects of interruptions in network computing. We also invited the participation of a number of non-academic units (for example, the office of undergraduate admissions and financial aid and the office of the registrar), selected because of their functional impact on the academic mission of the university. (See the sidebar for the letter of invitation to participate.) The interview procedure was as follows. Five faculty members from the subcommittee conducted interviews at a total of 25 sites, ranging in size from very small units to regional campuses. Forty-seven respondents provided information. Interviewees variously consisted of administrative staff, computing staff, faculty, and high-level administrators. Some individuals spoke solely from their own perceptions, while others sought pre-interview data from a representation of their colleagues and/or furnished a prepared summary approved by administrative leaders. The interviews focused on the types and functional (specifically, business) effects of network computing disruptions and did not dwell on the technical aspects of the disruptions. Interviews ranged between 30 minutes and two hours and, unless otherwise noted, were conducted onsite between March and May 2001. The interviews were conversational and open-ended, with the intent of eliciting the content most pertinent to each site. Each interviewer submitted a written narrative. These were edited and summarized by the subcommittee chair and assembled into a report presented to CAC, CSSD, and the university provost. Three major outcomes of the audit—new information, common themes, and local introspection and change—are described below. New InformationThe elicited scenarios yielded as a primary outcome a rich body of new information concerning potential vulnerabilities. The process provided all concerned with a greater appreciation of the ways in which mission-critical university functions could be vulnerable to computing failures. The process also stimulated dialogue and valuable mutual learning among local administrators, faculty members, and IT staff. This created an enhanced understanding of their mutual dependencies on technology. Six examples follow. School-Based, Research-Related Services
School-Based Student Services
International Services
Health Sciences Services for Clinical Rotations
Customer Services
Regional Campus Services
Common ThemesThe resultant report yielded a second outcome, the following common themes expressed throughout the interviews. Potential Types of DisruptionThe subcommittee identified numerous types of potential disruptions:
Potential Business LossesMost units related potential business losses secondary to systems interruptions. The resultant "costs" could variously affect the institution, its workforce, and its customers (for example, students, alumni, and community-based employers). Three distinct categories of loss emerged:
Timing FactorsTwo major aspects of timing emerged:
Localized Back-Up SystemsIt became clear that there was a wide variability in dependence on the university computing network, even within individual units. Some units had unique computing dependencies, as in the School of Medicine for resident "matches," the School of Law for connections to downtown courts, and the School of Dentistry for patient scheduling. Some units maintained IT architectures that were less dependent on the university network; these appeared to have evolved for reasons other than protection from network failures. Local Introspection and ChangeA third major outcome was that various units engaged in intra-organizational reflection concerning their dependencies on computing network functions. Units identified new areas of vulnerability and ways to avoid network-related losses. Some stated that specific changes would follow, such as the installation of localized back-up systems. Issues ranged from realizing that a Web site wasn't routinely backed up to discussing when a system's shutdown would most affect critical business functions such as admissions deadlines, research grant submissions, and class registration. The interview process thus appeared to stimulate thinking concerning business continuity issues. Relevance to Other Academic InstitutionsThis project could be relevant to other academic institutions in several ways:
Future DirectionsThe chair of the Council on Academic Computing will revisit the need to focus attention on academic computing vulnerabilities and update the report within the next academic year. In that event, we might consider incorporating the perspectives of another set of customers—students, a key constituency that is likely to yield yet another "view of the roof." Acknowledgments
This presentation was featured as a poster session at the EDUCAUSE 2002 Annual Conference in Atlanta, Georgia, which also featured comprehensive audit-driven approaches described by Jay Dominick, Assistant Vice President, Information Systems, and Chief Information Officer, Wake Forest University.
Endnotes
1. See the University of Pittsburgh technology plan at <http://technology.pitt.edu/itplan/>.
2. Find more information on the Expert Partners Program at <http://expert.cis.pitt.edu/>.
3. The Council on Academic Computing is explained in more detail at <http://www.pitt.edu/~vpres/CAC/>.
|