|
The Stanford Linear Accelerator Center is the lead Department of Energy (DOE) laboratory for electron-based high energy physics. It is dedicated to research in elementary particle physics, accelerator physics and in allied fields that can make use of its synchrotron radiation facilities—including biology, chemistry, geology, materials science and environmental engineering. Operated on behalf of the DOE by Stanford University, SLAC is a national user facility serving universities, industry and other research institutions throughout the world. Its mission can be summarized as follows:
The Unclassified Computer Security function is responsible for coordinating and promoting programs within the Laboratory to assure that information resources provide 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.
Bob Cowles, Computer Security Officer (CSO), SLAC
Richard Mount, Director, SLAC Computing Services (SCS)
General Security Education
A computer security briefing was included in the September, 2004, Integrated Safety Management System (ISMS) training given to all SLAC staff. A significant number of students attended a variety of security-related classes taught by Microsoft or by Gene Schultz from Lawrence Berkeley National Lab.
Web and Anti-Virus Activities
Almost all incoming mail enters SLAC through a single gateway that runs flexible algorithms for scanning and stripping potentially harmful attachment files. Further scanning is performed at the MS Exchange server, and real-time anti-virus scanning is performed at the user’s workstations and home directory file servers. There were no reportable incidents of serious virus infection at SLAC in FY2004, other than individual machines brought into the lab by collaborators – and these few machines were usually quickly detected and re-installed. During this year we converted from using InoculateIT from Computer Associates to Symantec’s anti-virus scanner. Not only Symantec scanner is a more mainstream product, but we were able to leverage the site license already negotiated by Stanford University for a cost savings.
Secure BSD-Network
Continuous work is being performed on the business system network to accommodate a significant change in service that is planned. PeopleSoft HR was upgraded last year and Financials applications will be moving to PeopleSoft version 8 within the next few months., These upgardes will require substantial changes in the security structure to accommodate broader access to PeopleSoft information through a web and application server (3-tier) architecture. To accommodate these changes, a new management network and firewall design is in the process of being deployed.
SPAM
In May, 2003, SLAC introduced spam-tagging software (PureMessage) at the mail gateways. SLAC has chosen to: scan; tag-if-spam; and deliver all email; and not to quarantine any emails. For the most part, the user community continues to be extremely happy with this solution. The spam-tagging software has been enhanced to also tag, as spam, the emails containing malicious code often found in the “phishing email” that entices users to provide personal or financial information.
Management of Windows systems
Traditionally, desktop administrators have had to visit individual systems to apply security patches. While this is quite time consuming, until this year the border firewall and stripping of executable attachments gave us a substantial time buffer to get patches applied to all systems. This year, with the conversion of desktop systems to Windows XP, we have been able to distribute OS updates through a Software Update Server (SUS) and application updates through Group Policy Objects (GPO). We have steadily improved the speed at which patches get installed and have been able to quickly identify machines requiring individual attention by almost daily vulnerability scanning.
In late December 2003, 30 Windows machines were compromised through a vulnerability in DameWare remote control software that the administrators had installed to improve their ability to apply patches to systems in an effective manner. The Lab was in a holiday shutdown period when the problem occurred and was discovered, so that it took several days longer than normal to halt the compromises. Analyzing the data and locating all compromised machines took through January into early February.
Management of Linux and Solaris systems
The SCS Unix Systems Group uses software to standardize the management of Red Hat Linux and Sun Solaris systems. This software is used on all central Linux and Solaris servers and is strongly encouraged for desktop systems. We now treat any vulnerability allowing an authenticated local user to compromise a system as seriously as a vulnerability allowing an unauthenticated remote user to compromise a system. There were no root compromises of managed systems during the year.
There was one system compromised using the techniques associated with CIAC’s Case #596 (formerly known as the TerraGrid Incident) – a user managed machine running the Debian Linux distribution. While several SLAC users have had their passwords compromised in other locations (CalTech, CERN, Rice University, Stanford University), the intruders have been unable to get privileged access on other systems at SLAC but have used SLAC to launch attacks at other sites (LBNL) and to set up scanners probing for unprotected X-sessions. We have required password changes, SSH RAS key changes and suggested grid certificate revocations for users whose passwords were potentially compromised at other sites.
One other machine was compromised because it was running an old version of CVS version control software. The system has now been updated to not use CVS in a form that has been shown to have vulnerable access controls.
Risk Assessment and Mitigations
The risk assessment is based on current and probable future threats to the computing environment of the lab, based on experience at SLAC and other DOE labs, and the experience with costs to recover from incidents where the protective measures have failed.
Risk 1: Attacks on Windows desktops and servers through known vulnerabilities.
Mitigation: Converted almost all Windows machines to participate in Active Directory so patches are automatically installed. The network is scanned several times a week to ensure patches are properly applied to systems. No additional effort is planned.
Risk 2: Attacks on Unix & Linux servers and desktops thru known vulnerabilities.
Mitigation: Use of locally developed "taylor" mechanism for centrally maintaining these systems is strongly recommended, and it is required for use of certain services (e. g. access to mail spool). No additional effort is planned.
Risk 3: Email-born attacks through attachments and malware that induce users to compromise their systems.
Mitigation: All Windows-style executable attachments (incoming and outgoing) are removed by the Internet email gateways. Direct delivery of email except thru these gateways is blocked at the external border router. Email containing in-line malware is flagged as spam so most users will not read it. Email going to Exchange servers is scanned with Sybari's anti-virus tool and malware is removed. In case the other steps fail or in case the email is downloaded from other sites, almost all Windows desktops on the site run a current version of Symantec's antivirus software with current signatures, which should remove the virus. No additional effort is planned.
Risk 4: A SLAC Windows user makes a remote connection to the site using a compromised machine and software in this machine attempts to compromise other Windows machines on the SLAC internal network.
Mitigation: The Windows networking ports typically used in such an attack are blocked between remote-access users and all but identified and well-maintained servers. After the Windows server infrastructure is converted to Windows 2003, the risk will be further reduced since VPN access will no longer be required for reading email from the Exchange servers. This area is being watched in case further action is required.
Risk 5: Copyrighted materials may be improperly available for access and downloaded from machines on the SLAC network.
Mitigation: A report on network "flows" is produced each day and when machines on the report demonstrate certain characteristics typical of peer-to-peer file sharing, the primary user of that machine has a conference with HR or a Research Division person to ensure any illegal or inappropriate activity is halted. Policies and responses are being coordinated with Stanford campus to ensure consistency. No additional action is planned.
Risk 6: Software not maintained by the Windows Active Directory maintenance is installed and may contain flaws used to attack and compromise machines.
Mitigation: SLAC has purchased a license for a tool to allow these systems to be inventoried and reports generated on versions of software that may be vulnerable. Further deployment awaits sufficient staff resources to develop and maintain the inventories (1 FTE for a year, .5 FTE ongoing). No active work.
Risk 7: Reusable passwords could be sniffed or otherwise discovered and allow unauthorized access to Unix or Windows systems. Unix users are not automatically forced to change their password on a regular timetable.
Mitigation: All Unix users with centrally maintained privileged access are required to change their passwords every 6 months - this is verified and enforced through manual procedures. A project to synchronize Unix and Windows passwords and then to force password updates through Windows mechanisms has been cancelled in light of the threat from the "ssh-attacks" to Unix systems; attention has turned to one-time passwords technology as a possible solution. Accounts associated with departed employees and users are being disabled regularly. Losses attributed to reusable passwords have been minor to date, but major future losses cannot be totally ruled out. We are proceeding with our investigation and we are planning to coordinate with other HEP research facilities including non-DOE labs. This risk is being tracked in the quarterly POA&M report.
Risk 8: There is a campus-wide wireless network allowing anonymous access to the Internet that could be used to compromise other machines on-site, or to mount externally directed attacks, with or without the knowledge of the machine's user.
Mitigation: All wireless access points are on the visitor network that has no special access rights to the SLAC internal network. The SLAC physical site is far enough removed and access sufficiently controlled to greatly reduce risk of casual access by the public other than through access from the SLAC Guest House. The problems relating to this type of access have been relatively few; the convenience has been great for attendees at conferences, meetings and seminars - such access is now assumed by participants at such gatherings. Much of the cost of these incidents is related to the detective work to determine, if possible, the identity of the "anonymous user". Further mitigation would take the lines of an online hotel-like registration system so there is a name associated with each machine using the network and the machine can be scanned before granting access. Installation of such a system would likely require staff resources on the order of 2 FTEs for at least 6 months and .25 FTE on an on-going basis. No active work is being performed in this area.
Risk 9: There exist no fully documented set of recovery procedures for the lab in the case of severe damage to selected (co-located) parts of the computing infrastructure nor to even moderate widespread damage to the infrastructure.
Mitigation: The administrative computing areas have procedures in place so SLAC can still meet legally mandated requirements in case of disruption to the computing services. Irreplaceable scientific data is replicated within hours of acquisition at remote sites (principally in Europe). More systematic replication of business and scientific functions at remote sites is under study, but no implementation is funded. SLAC has always been able to depend on an incredibly talented and dedicated staff to work through problems and get the required tasks done. The dynamic nature of the environment means that most recovery procedures become rapidly out-of-date. Staff time should only be directed at longer-term solutions. No further action is expected until resources are available.
Risk 10: Web servers at SLAC could be compromised and the home pages defaced.
Mitigation: The barriers for having a web server visible off-site are quite high. Applicants for such a privilege are required to explain why they can't use existing servers and must demonstrate an understanding of the effort required to properly maintain an Internet-visible web server. SLAC's primary web server includes monitoring that sends alerts in cases of unauthorized changes to the home page. Web authors who desire to utilize CGI scripts must undergo training on security considerations prior to being granted that privilege. No additional action is planned.
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.
Activities in response to threats
10/03 Completed discussions with SLAC legal and GLAST on protection of ITAR materials
10/06 Created maintained email lists for remote users (dsl, dialup, isdn).
10/14 Network access for unpatched DCOM machines removed – 0 removed – all patched
10/16 Allhands memo to stop Windows messenger service
10/23 Met with campus security and Microsoft about patching requirements
10/31 Disabled 9 machines from the network for being unpatched
11/13 Started campaign to shut down remaining Solaris 2.6 desktop machines
11/25 Patched a number of local security vulnerabilities in RedHat Linux systems
12/02 Patched do_brk vunerablity in Linux
12/12 Patched security issues in Perl scripting language
12/16 Patched dtprintinfo vulnerability in Solaris
12/18 Patch rsync vulnerability in Unix
12/20 First DameWare system compromised
12/22 Alert to update Mac OS X systems for USB keyboard vulnerability
12/28 Blocked DameWare port to prevent further compromises
12/28 Outgoing email scanned for virus/worms; no longer stripping files with macros
01/14 Alert to update yahoo messenger
01/15 Dealt with report of machine running an open proxy server
02/05 Began campaign to close port 5000/tcp (uPnP) on all Windows machines
02/18 Start build and rollout of Linux kernel fix for mremap vulnerability
02/19 Set up automatically maintained email list for all registered dhcp users
02/27 Patched mremap vulnerability on Linux systems
02/27 Submitted updated CSPP
03/05 Patched Solaris vulnerability in print/conv_fix
03/05 Attempted intrusion on machine nettest1 – compromised account from Rice
03/08 Developed computer security text to be incorporated in lab-wide performance appraisals
03/16 Alert about fake Microsoft update email
03/29 Completed shutdown of radmind use in PCD
04/09 Linux system Bodensee found to be compromised
04/15 Started blocking desktop file/printer sharing ports from VPN & dialup users
04/17 All on-site Windows machines patched for LSASS exploit
04/29 Begin rollout of new Solaris kernel with security patches
05/01 Login banner changed to indicate possible ownership by the US Government
05/02 Made sure login banner on Windows and *nix logins referenced the same web page
05/24 Linux system sldl1 found to be compromised through CVS
06/14 Received and started process of dealing with a DCMA notice
06/16 Headed off proposal to make individuals dosemetry reports available through the web
07/06 Discussed One Time Passwords at annual meeting of SLAC Users Organization
07/23 Patched RHEL system kernels for multiple security vulnerabilities
07/23 Compromised account (from Stanford) used to attack systems at LBNL from SLAC
07/25 Alert to Linux desktop users of need to reboot their system to activate new kernel
08/02 New kernel for RHEL Linux systems
08/09 Received and began dealing with MPAA notice
08/13 Alert to update AOL Instant Messenger
08/24 Alert on Axis Network Camera
09/22 Cyber Security presentation at annual ISMS training
09/24 Disabled accounts accessing SLAC from compromised LXPLUS cluster at CERN
09/30 Found compromised account used to scan Internet on multiple machines for xhost +
Windows desktop security patch application
With the recent vulnerabilities in Windows desktop systems, the security team has been performing almost daily scans for desktop systems remaining to be patched. The chart below shows we are getting the systems patched with very little delay.
Status of FY2004 Goals:
Windows patching has been greatly improved. Early in the year, it took approximately 30 days to get a critical patch installed. By the end of the year, patch MS04-025 was basically installed in approximately 20 days.
This effort has been completed
This goal was not met. With the steadily increasing threat posed by the attackers associated with Case #596 (formerly known as the TerraGrid Incident), the investment in this project was a halted until we could evaluate the requirement to migrate to a one-time-password solution.
Goals for FY2005:
The Laboratory’s true performance with regard to Unclassified Computer Security is perhaps best measured by the things that did NOT happen during FY2003:
Back to Index Page