Index

Safeguards and Security

Unclassified Computer Security

Introduction/Background

Date of last assessment: October 1999

Departmental Overview

Laboratory Mission

The Stanford Linear Accelerator Center (SLAC) is dedicated to experimental and theoretical research in elementary particle physics and in those fields that make use of its synchrotron radiation facilities, including biology, chemistry, geology, material science and electrical engineering. This includes the development of new techniques in particle acceleration and detection, and of synchrotron radiation sources and associated instrumentation. The Center is operated as a national user facility for the Department of Energy by Stanford University.

Organizational Mission

The Unclassified Computer Security function is responsible for coordinating and promoting programs within the Laboratory to assure that information resources are provided protection commensurate with the risk and magnitude of harm that could result from loss, misuse, or unauthorized access or from modification of such information resources and to assure that systems and applications operate effectively and provide appropriate confidentiality, integrity, and availability protection.

The Unclassified Computer Security functional area self-assessment is based on, and measured against, performance objectives and standards as reflected in the SLAC contract.

Identification of Self-Assessment Report Staff

Names, titles, affiliations of participants

Bill Johnson, IRM Computing Manager, BSD

Douglas Kreitz, Assistant Director, BSD

Scope of Self-Assessment

Status of Open Items from 1999 Review

The SCS Security Group is now fully integrated and represented in all computing matters.  In addition, computer security considerations are well represented in the two policy groups, the Computer Coordinating Committee (CCC) and the Associate Directors Committee on Computing (ADCC), by Richard Mount, Director of SLAC Computing Services (SCS) who chairs the former and is an ex-officio member of the latter.

Secure BSD-Network

Considerable progress has been made toward completing this project (described in some detail in last year’s self-assessment):

• The Architecture has been fully mapped and all components are either in place or pending minor network changes.
• PeopleSoft HR applications are now run exclusively from the Citrix Windows Terminal Server environment (the BSD Extremely Private Network or BSD-EPN) via fully encrypted ICA sessions.
• Work is presently underway to bring up PeopleSoft 7.5 for the Financials applications on the Citrix Windows Terminal Server system.  When this is completed, the BSD firewall around the PeopleSoft Database can be activated.  This is expected to happen in October 2000.

Progress Reducing Clear Text Passwords

At the end of FY99, the HEP community had replaced all Telnet connections with Secure Shell (ssh).  During FY00, SSRL has introduced ssh onto most of its servers and eliminated Telnet to all but a handful of residual machines.  These are well identified, and SSRL management has accepted the risk as a necessary communications link for their user community.  It may be possible to eliminate these Telnet sessions in the future through additional user community education (i.e., encouraging those users to establish and use ssh at their home laboratories).

The last remaining bastion of clear-text passwords is POP and IMAP e-mail service.  Because of the SLAC firewall, this is almost entirely a local exposure.  After exploring a number of mail-clients that boasted various forms of encrypted authentication, SCS has recommended migrating all Eudora POP and IMAP clients to MS Outlook, using a Microsoft Exchange Server and Windows NT password authentication.  A large-scale migration is under way with a goal for completion of January 1, 2001.  At present (September, 2000), more than 600 e-mail users have made the transition.

Discussion of Individual Performance Objectives

Performance Objective         # 3

Information resources are provided protection commensurate with the risk and magnitude of harm that could result from the loss, misuse, or unauthorized access to or modification of such information resources.  

Performance Criteria:        3.1

Through a documented unclassified computer security program, SLAC will ensure its information systems and applications operate effectively and provide appropriate confidentiality, integrity, and availability protection.

Discussion

New FY00 Activities

The major Computer Security accomplishment of the year was the development of SLAC’s Cyber Security Protection Plan (CSPP), which was approved by DOE.  DOE Directive N 205.1 provided the essential guidance and structure necessary to the Plan.  This fundamentally required a comprehensive description of Laboratory computer security structures and existing practices and subsequent analysis by SLAC management of the appropriateness of these structures and practices.

The Plan was drafted by the Computer Security Officer with help from his SCS Computer Security Group.  It was then reviewed by the CCC for accuracy and content and subsequently presented to the ADCC.  The final draft was reviewed page-by-page at an ADCC Meeting before final approval.  Very special consideration was given to SLAC’s unique mission and environment.  The document achieves an extraordinary balance between the Laboratory’s need to freely exchange and publish scientific information throughout the world-wide scientific community while preserving and protecting the integrity of Laboratory computers and information.  It was subsequently approved by DOE with favorable comment.

Viruses Activities

If one needed a subtitle describing FY00, it might very well be “The Year of the Worm.”  Most organizations worldwide have suffered major infections from macro-virus/worms that proliferated through MS Outlook to other users at the infected site and ultimately to infect external sites as well.  Very fortunately, SLAC has been spared almost all of this agony.  The principal reason for this has been the structure of incoming e-mail at SLAC and aggressive early actions on the part of SLAC’s Postmaster, Teresa Downey, in stripping infected attachments out of mail at the gateway before it ever gets delivered to users.  Almost all incoming mail enters SLAC through a single gateway.  The gateway software PMDF has within it flexible algorithms for scanning and stripping attachment files that either contain executable macros or are themselves executable. 

As the first viruses appeared, the Postmaster configured PMDF to scan for macro-virus signatures selectively and strip out the famous ones before delivery to the user community.  As the siege from these pests became more intense, SLAC expanded its policies by stripping all attachments with an executable component.  When an attachment had been stripped, the user received in its place a text file with instructions about contacting the Postmaster if recovery of the stripped file were necessary.  Remarkably only a very small number of recovery requests were received.   Data regarding the number of stripped attachments and their nature is given in Appendix A

As a result, in the worst virus year in history, SLAC suffered only one minor infection by a relatively harmless worm, which unfortunately did get transmitted to another site.  The infection, however, was easily contained and the external site promptly warned of the exposure.

The anti-virus product InocuLAN provided an additional layer of protection against the small number of documents that slipped past the mail gateway.  As indicated in the FY99 self-assessment, InocuLAN replaced the McAfee anti-virus product and has been widely installed on Windows systems in FY00.  During the Siege of 2000, InocuLAN has been extremely diligent in distributing virus signature updates, which then are distributed almost immediately to SLAC workstations by means of the networked distribution servers that are part of the InocuLAN product.  Statistics about viruses that InocuLAN detected and neutralized are given in Appendix B.  

InocuLAN detected and logged 1925 viruses during the year.  They have been classified in Appendix B as “Macro Viruses,” “Viruses,” or as “Worms.”  Since these categories sometimes overlap, there may be some ambiguities.  Their “severity” is also somewhat subjective, based on hearsay in the world community rather than direct experience (thankfully).  Those indicated as deadly are either purported to be destructive and highly infective (like AOL.Setup) or capable of  taking over one’s system (like the “Backdoor” family).  Those categorized as “Bad” are purported to have a destructive payload.  Those in the “nuisance” category are mostly the ubiquitous macro viruses like CONCEPT and PAD.  One native Macintosh virus was detected.

There are an alarming number of deadly viruses in this list, especially since gateway stripping of executable attachments has already eliminated many candidates.  Fortunately, most of these target Windows 95 or 98 systems preferentially (rather than Windows NT) or rely on features of Outlook or Outlook Express that are thwarted by SLAC’s Exchange server.

As indicated above, SLAC is migrating e-mail users to MS Outlook with an Exchange server.  A third layer of protection is supplied for Outlook users by deploying a specific InocuLAN product on the Exchange server that scans all incoming mail for viruses.

SPAM 

SLAC continues to be aggressive in suppressing SPAM when there are complaints from the user community.  We do this, once again at the mail gateway, by blocking incoming e-mail from ranges of offending IP addresses (i.e., blocking traffic from all IP addresses in the range 24.28.42.*).  At the present we have blocked more than 3200 such ranges.  There are 40 to 50 additions each month, and removal of approximately one per month when requested by a SLAC user in order to receive e-mail from someone off-site. 

The SLAC community enthusiastically supports this program and complains loudly when new “spammers” discover the Laboratory.  The only downside is the on-going staff effort that must be expended in maintaining the lists of blocked ranges.

Status of FY00 Goals:

1. Deploy and tune the REALSECURE Intrusion Detection Software.  Accomplished.  Routinely scans are detected and reported to the appropriate abuse authorities as well as CIAC (during FY00 more than 70 scans were detected and reported).  Defining “events” is, of course, a perpetually on-going process.

2. Integrate handling of computer accounts for Staff, Collaborators, and contractor/consultants so that they may be properly terminated upon departure from SLAC.  Policy for this was presented to CCC and ADCC and approved by ADCC.  Manual implementation by disabling accounts has begun.  Automation of this process is underway with a goal of making the process completely impersonal unless managers or supervisors have specifically applied for exception.  Wider advertisement of this policy is still needed.

3. Complete implementation of BSD Secure Network.  As noted above, significant progress has been made; final implementation of the firewall awaits commissioning of PeopleSoft 7.5 Financials for production use since WTS implementation is not possible for earlier versions of Financials.

4. Create Cyber Security Protection Plan suited to SLAC’s needs and compliant with DOE N 205.1.  Fully accomplished as noted above.

Improvement Action Plan/Goals

Goals for FY01:

1. Develop an appropriate computer security education program for SLAC.
2. Automate account termination procedures.
3. Develop appropriate Performance Measures for the Peer Review era of Laboratory Review.

Performance Side-Bar Performance Indicators

1. Accomplishment of High Priority Computer Security Objectives:

The most important objective, creation of SLAC’s CSPP, was accomplished with distinction.  This involved significant advances on, if not outright accomplishment of, almost every other single objective in the Objectives List.  The only exception is User Education, where Laboratory management is in the process of defining what kind of program is appropriate for SLAC’s unique mission. 

The value of this particular Objectives List now seems to have outlived its usefulness. We propose that the yearly goals replace this list or be supplanted by other mechanisms as the Peer Review process evolves.

2. Determine and track the fraction of “well managed” systems at SLAC.

The mechanics of tracking this fraction broke down almost completely during the course of the year.  The primary tool for NT systems had been those managed with Systems Management System (SMS) clients.  When SMS 2.0 was introduced, instabilities developed that forced System Admins to disable SMS clients and abandon SMS as a systems management tool.  Further, the problems encountered alienated a substantial portion of the community against SMS.  However, many NT System Administrators have attended training during the year (see IM Assessment regarding ADCC recommendation for training support in new technologies), so we can infer gains in the NT environment as well.  Also the transition to Windows 2000, which has already begun at SLAC, will introduce dramatic changes to the security of the NT environment.

On another front, the ascendance of Linux has introduced a substantial Laboratory constituency  (approximately 300 machines) whose management status is not easily quantifiable (see the Information Management Self Assessment for developments during the year with Linux Systems).  In effect there are no quantifiable results to present.  Security group scans of selected Linux systems monitor vulnerabilities and assist system owners and administrators in eliminating those vulnerabilities.

This particular side-bar indicator lacks a very important weighting factor—namely the importance of the system—in assessing how well Laboratory systems are managed.  The Compute Farms, for example, comprise an immense computing resource (900 440MHz Sun Textra 1 processors) that are extremely well managed by SCS.  These are given equal weight along side an equal number of Intel Pentiums, Pentium Pros, and Pentium II processors running Windows NT although they constitute a much less important computing resource for the Laboratory.  It appears that not only have the mechanisms for tracking this fraction broken down but even the significance of the number if it could have been measured.

The Laboratory’s true performance with regard to Unclassified Computer Security is perhaps best measured by the things that did NOT happen during FY00:

• There were no detected break-ins (a reflection of eliminating almost all clear-text passwords outside the firewall, diligence of the Security Group in detecting weak passwords, and scanning for vulnerabilities).
• In the worst year ever for viruses and worms, there were no significant infestations at SLAC.
• There were no known denial-of-service attacks (probably a reflection of good system administration and intrusion detection efforts).

The Laboratory in general has had an outstanding year of accomplishments in the area of computer security.

Appendix A:  Stripping Worms/Viruses from E-Mail

Although the numbers vary, in a typical week about 130 documents are stripped at the SLAC mail gateway.  Of these roughly 120 are “executables” and 10 are Microsoft documents with macros.  Typically there are 2-3 requests from users each week to retrieve the stripped attachments (i.e., ~2%).

There are three kinds of documents that are stripped:

1. Popular named attachments like “happy99.*”, “cokegift*”, etc.
2. Microsoft documents with macros

Executable files as defined by Microsoft, represented by the following file extensions:  *.EXE, *.SHS, *.VB*, *.JS*, .WS*, *.ADE, *.ADP, *.BAS, *.BAT, *.CHM, *.CMD, *.COM, *.CPL, *.CRT, *.HLP, *.HTA, *.INF, *.INS, *.ISP, *.LNK, *.MD*, *.MS*, *.PCD, *.PIF, *.REG, *.SC*, and *.URL.

Appendix B:  Virus Summary