Text-Only Version
CCC Computing Cooperative
middle spacerhomemembersmeetingsemploymentissuesresourcesUCLA homebottom spacer

CCC Home --> Documents --> Electronic Security Officer

Electronic Security Officer

Proposal to Fund One - Year Position

Summary

The ubiquity of access to computer resources that has been brought about by the Internet also means that many more people are able to initiate attacks to these same resources, and from anywhere in the world. In recent years, these attacks have significantly increased in frequency, variety and sophistication. Types of security vulnerabilities are summarized in Appendix 1.

Attacks on UCLA computing resources have increased significantly damaged or compromised data resulting in degraded performance of computing services and possible legal vulnerabilities for the campus. The challenges of addressing electronic security become even more complex as they intersect with ambiguous legal territory, shifting cultural expectations and rapid technological development.

UCLA currently has no overall electronic security policy in place or a framework for tracking and designing countermeasures for this complex threat. A coordinated, campus-wide initiative to build such a framework is necessary to avoid serious, ongoing damage that drains campus computing resources. Action in the areas of policy and enforcement, external presence, technical coordination, and education and training are desirable, and outlined in this document.

Proposal

It is critical that UCLA define a position with respect to electronic security. OAC proposes to provide "pilot" funding for a one- year position. In this period electronic security issues with respect to UCLA’s technology and policy environment would be assessed to determine UCLA’s immediate and long-term requirements for a permanent IT security officer. Other goals for this one-year period are outlined below.

One-Year Goals

  1. Campus policy and enforcement. Create a framework to develop campus-wide policies on electronic security; provide a clear definition of the possible consequences for neglect in this area and develop a set of procedures to follow in the event of a legal or administrative challenge. Work with various campus agencies to define an official stance with respect to electronic security that can be used externally to defend incidents that may involve freedom of speech, etc.
    • Assume responsibility for the UCLA Postmaster role that is currently located at OAC as part of BOL to expose, track and deal with electronic abuse issues. Currently 30 to 50 abuse complaints are received every week.
    • Establish a coordinative relationship with Dean of Students, the Student Technology Center, the Office of Residential Life, Campus Counsel and UCLA Webmaster under External Affairs and departmental IT directors and managers to develop a campus-wide electronic security framework for developing programs and policies.
  2. External presence. Monitor UC, legislative and specific project efforts that may have significant impact in the area of electronic security. Support and help shape such efforts ultimately helping build a solid foundation upon which local policy can be built.
    • There is anti-spam legislation now being proposed in more than one state. Although such legislation may not be perfect, and may initially be defeated, it is in the University’s interest to support and help shape such efforts.
    • An immediate example of needing an external presence. The proposed Acceptable Use Policy for CalREN2/Internet2 indicates that a member institution’s access to this network could be cut off if severe network disruption originates from that institution. Is UCLA willing to have its entire community cut off because of a single individual, even for a brief period of time?
  3. Technical coordination. Bring together expertise and experience from across campus to share knowledge, discuss current events, and plan strategy for future measures. Establish relationships with relevant external organizations (e.g. the Computer Emergency Response Team Coordination Center at Carnegie Mellon University, or the Computer Incident Advisory Capability). Establish relationships with relevant organizations and projects at UCLA (e.g. the authentication project). Create a "strike force" team that could assist departments who have been subject to a computer attack. Consider strategies for performing a technical "threat assessment."
    • For example, the Bruin OnLine technical staff constantly deal with the results of spam, and are actively exploring ways to alleviate its effects. The UCLA Postmaster already works with Campus Counsel, the Dean of Students, and the Office of Residential Life for incidents arising from electronic abuse. Communications Technology Services is continuously exploring and implementing technical security measures for the Campus Backbone Network. Medical Center Computing Services has a Manager of Data Security that deals with such issues for the Medical Enterprise. Administrative Information Systems has expertise in creating secure environments. There are a variety of individual departmental efforts in this area. All of this expertise and experience needs to be brought together, shared and coordinated to be effective as a campus-wide response.
  4. Education and Training: Build a "clearinghouse" of electronic security information: track issues on the latest security vulnerabilities (including the latest computer virii and virus hoaxes) through electronic means, conferences, and workshops; and make this information available to the campus. Develop, package and deploy security-related fixes. Create training programs on specific technical areas, such as Windows NT security.

APPENDIX 1 — Security Issues and Scenarios

  • Someone on the Internet sends out thousands of copies of unsolicited email to thousands of people ("spamming") that advertises a "get rich quick" scheme. Neither the initiator of the spam nor the thousands of recipients who receive this junk mail may have any affiliation with UCLA; but the spammer has used a UCLA server as an intermediate relay, both to defeat "anti-spam" filters and to cover tracks that may help pinpoint the perpetrator. Known as a "relay" attack, a single such incident can trigger thousands of error messages to the administrator of the UCLA server in question, generate hundreds of complaint messages to the UCLA Postmaster and Webmaster (many threatening legal action), and significantly degrade performance of UCLA networks and computer services. Furthermore, a common brute-force solution adopted by some organizations is to temporarily block all email from any site linked to a spam incident, denying delivery of legitimate UCLA email to those organizations. It may take from hours to weeks to "solve" an incident.
  • A faculty member who uses a Netscape Navigator or Microsoft Internet Explorer to do research on the web is hit by a newly discovered vulnerability in these programs, giving malicious hackers access to the faculty member’s email archives–and more. This intrusion would likely not even be detected unless the perpetrator chooses to do damage.
  • A hacker somewhere on the Internet discovers an unsecured server at UCLA, places pirated copies of commercial software ("warez") on it, and then advertises the location of this server to the Internet. Suddenly thousands of people from all over the world begin making copies of this software, straining departmental networks and servers, and impeding normal use of computing resources. Properly shutting down such access and tracking the original perpetrator takes enormous time and experience by IT personnel. UCLA may also be vulnerable legally for having allowed this to occur.
  • A student downloads new software from the Internet that contains a virus, which infects Microsoft Word on his computer and consequently destroys much of the formatting of his latest paper. Although no data may lost, it will take time to restore the document to its original format, often requiring the aid of departmental IT personnel both to undo the damage and cure the virus to prevent it from spreading.
  • A new vulnerability in basic network software is identified, and a hacker chooses to exploit it on a UCLA network. In one particularly severe incident, the same vulnerability is present in Windows computers, Unix systems, printers, and network routers; and the attack (a "denial of service" attack) crashes dozens of systems and effectively halts all productive use of computers in a department for a time.
  • For example, many of the most effective anti-spam measures involve automatic filtering of certain types of email messages. America OnLine, representing more than 11 million users, is locked in numerous legal battles with spammers who have charged that such filters represent discrimination and violate free speech. While the vast majority of people support such filters, are they legally and philosophically appropriate for UCLA, especially as it is a public institution? When someone threatens legal action against UCLA because of an email message sent by a UCLA student containing an unpleasant or unpopular viewpoint, it would be much easier to defend freedom of speech if the campus has adopted a public stance on these issues.
  • UCLA as an organization is increasingly being held responsible for any incident on any computer on campus–internal administrative boundaries are irrelevant. For example, the proposed Acceptable Use Policy for CalREN2/Internet2 indicates that a member institution’s access to this network could be cut off if severe network disruption originates from that institution. Is UCLA willing to have its entire community cut off because of a single individual, even for a brief period of time? What are the responsibilities that all computer users have, and what are the consequences of neglect? Furthermore, the legal threats to UCLA (e.g. for a spam incident initiated on campus) potentially affect the entire campus, even if the perpetrator is just one UCLA student.






Search in for

Home - Members - Meetings - Employment
Issues - Resources - UCLA home

Text-Only Version | Printable Version

This page maintained by:
GSE&IS/CCC Web Team (webmaster@ccc.ucla.edu)