Unclassified Computer Security
Introduction/BackgroundPoint of Contact: Bob CowlesPhone No.: (650) 926-4965 Email: rdc@slac.stanford.edu General Security Issues A computer security briefing was included in the September, 2005, Integrated Safety Management System (ISMS) training given to all SLAC staff. An email is sent to all Windows users when Microsoft releases critical patches. Users are encouraged to test patches before the lab-wide deployment and reminded to update other systems (e. g. home systems) that are not centrally maintained. In August, we started performing SANS Top-20 vulnerability scans against all machines on the network. The server networks were found to be in good shape (except for some unsupported Oracle servers) and for this first pass we pushed to remedy the high priority desktop vulnerabilities. We will be repeating the scan quarterly and adding any other vulnerabilities to the list that are required to be fixed. 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 FY2005. A few infected machines were brought into the lab by collaborators – and these few machines were quickly detected, removed from the network and re-installed. During this year, we upgraded the Symantec anti-virus scanner. One Internet-visible web server was briefly compromised due to an erroneous configuration change. Secure BSD-Network Work is continuing on the business system network to accommodate the PeopleSoft HR and Financials applications move to PeopleSoft version 8. Substantial changes in the security structure have been implemented and are undergoing refinement to accommodate broader access to PeopleSoft information through a web and application server (3-tier) architecture. A new management network and firewall design is in the process of being deployed. SPAM With the dramatic increase in “phishing” attacks, SLAC implemented the “quarantine” option of the PureMessage spam-tagging software by default and then allowed users to opt-out if they wanted to receive all email. Almost all users elected to not receive the email that was tagged as spam (with the probability of more than 50%) and instead receive a daily report of the quarantined email from which they could request delivery of any apparently legitimate email. The spam-tagging software continues to tag, as spam, the emails containing malicious code often found in the “phishing email” that entices users to provide personal or financial information, but the spammers continually find ways to bypass the filters generating a new round of filter updates. Management of Windows systems We have steadily improved the speed at which patches get installed and 3-times daily vulnerability scanning, quickly identifies machines requiring individual attention. With the deployment of Service Pack 2 for Windows XP, we substantially increased the hardening of individual systems while still allowing access to the system for vulnerability scanning. At about the same time, software was deployed to the Windows XP desktops to enforce certain standard configuration options, including patches that were required to be installed. This software has reduced the number of individual systems that have to be visited because they did not properly install the patches distributed through the Software Update Service mechanism. With the implementation of “RPC-over-HTTP” for the Exchange servers, it is no longer necessary to have VPN access to connect to the Exchange email servers – so we have begun to discourage users from using VPN unless really required for accessing their home directory. We strongly encourage the use of Citrix as a more secure way for Windows’ users to gain access to internal SLAC network resources from the Internet. Management of Linux and Solaris systems The SCCS Unix Systems Group uses software to standardize the management of Red Hat Linux, Scientific Linux and Sun Solaris systems. This software is used on all central Linux and Solaris servers and is strongly encouraged for desktop systems. There were no root compromises of managed systems during the year. There were user accounts compromised using the techniques associated with CIAC’s Case #596 – several SLAC users have had their passwords compromised in other locations, the intruders were unable to get privileged access on the systems. We have required password changes, SSH RAS key changes and suggested grid certificate revocations for users whose passwords were potentially compromised at other sites. In September, we implemented daily analysis of the ssh logins to detect cases when the ssh password scanning that has been occurring on the Internet for several years might possibly have successfully logged in. We detected several successful attempts and checked the logs for several previous months to be confident there had been no other successful password guessing attempts. Certification and Accreditation Activities An updated C&A package was approved in November, 2004. With the continually changing requirements and to assist the Science Labs, the DOE Office of Science (SC) instituted Site Assistance Visits (SAV) in conjunction with the DOE Office of Assurance (OA). The first visit occurred in late August with subsequent visits scheduled in FY06, to update the written policies and documentation in a form that satisfies the latest DOE and NIST requirements, is consistent across the SC Labs, and has the approval of OA. 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 three times a day 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 quarantined 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. 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 well-maintained servers. With the conversion of the Exchange server infrastructure to Exchange 2003, the risk was further reduced since VPN access is no longer being required for reading email from the Exchange servers. VPN access for reading email is being discouraged and we will be increasing pressure to stop using VPN access. Risk 5: Copyrighted materials may be improperly available for access and downloaded from machines on the SLAC network. Mitigation: Several times an hour, the network flow data is analyzed for machines that appear to be contacting a large number of hosts. While these machines are sometimes infected with viruses, the most common activities are file sharing, Internet gaming or having a machine selected as a Skype super-node. The first priority has been to reduce the amount of file-sharing that occurs on machines permanently connected to the SLAC network, and that has been eliminated. Almost all this activity is now occurring on transient attachments to the visitor network. Work is proceeding on a registration system for users on the visitor network so that we can more easily contact a person who has a machine that is causing a problem. 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. One user maintained Oracle database system was compromised because it had not been patched. 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. Work on one-time passwords was halted until the impact of HSPD-12 could be determined. 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". Work is currently being performed on a registration system for users of the visitor network. 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 or 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. A test of the procedures was performed during the site-wide power outage. We were able to run Payroll, communicate status reports to staff and users, and then restore services quickly after power was restored. Some refinements in communications were performed in response to lessons learned during the outage. 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 alerts are sent 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. Discussion of Individual Performance Objectives Performance Objective 1: Cyber Security Perform network vulnerability scans on the SLAC network systems so that all systems are scanned each year or after significant system upgrades/changes. Ensure that high and moderate vulnerabilities on identified critical and/or sensitive systems are addressed within 45 business days of discovery and document in the FISMA and POA&M reports quarterly. Documentation for mitigation of the vulnerability or the reason for accepting the risk and identification of the corrective measures taken that reduce the risk these systems have on the internal and external networks. (Total Weight: 70%) Performance Criterion 1.1: Continue to implement and improve the cyber security program at SLAC consistent with DOE directives and guidelines. Performance Measure 1.1.a: Minimize network vulnerabilities and promptly correct vulnerabilities detected by either network scans or security advisories. Ensure that a robust Risk Management program is in affect using NIST guidance. Additionally, the development of certified and accredited enclaves is documented in conformance with NIST guidance. (Weight: 70%) Discussion Windows machines are scanned for critical vulnerabilities 3 times per day. Any critical vulnerability showing up on the Tuesday or Thursday scans must be patched by 6pm on the same day or network access for that machine is blocked. All systems were scanned in August for the SANS Top-20 vulnerabilities. While no critical servers had problems that weren’t already mitigated by additional restrictive firewalls or blocked ports at the network perimeter, some Oracle servers were found to be back-level and no longer supported by the vendor. A series of meetings resulted and a schedule for upgrading the servers was agreed upon. There is a POA&M tracking entry for the most important of these servers. We continue to work with the SAV team to ensure our policies and procedures are in place with the controls as required by DOE orders and NIST guidance. This effort will result in a rewritten CSPP and a new C&A package later in the fiscal year. Status of FY2004 Goals:
Improvement Action Plan/Goals Goals for FY2006:
|
