Educause Security Discussion mailing list archives
Incident Response
From: Ken Shaurette <kmshaurette () MPCCORP COM>
Date: Thu, 22 Jul 2004 20:02:01 -0600
Several following the discussions on Incident Response might be interested in Mich Kabay's recent series on CIRT in the Network World Fusion newsletters list. Excerpts of the newsletter follow.
Ken ------ Ken M. Shaurette, CISSP, CISA, CISM kmshaurette () mpccorp com Information Security Solutions Manager MPC Security Solutions <www.mpcscorp.com> or <www.buympc.com> (262) 523-3300 x60486 FAX 262-523-3333 ------ National Security Awareness Day - September 10, 2004 - Are you aware? ------ ******************************************** This email and any files transmitted with it are confidential and are intended solely for the use of the individual or entity to whom they are addressed. This communication may represent the originator's personal views and opinions, which do not necessarily reflect those of MPC Security Solutions. If you have received this email in error, further dissemination, forwarding, printing or copying of this email is prohibited, please notify the sender and delete this email and destroy any hard copy. ********************************************
Today's focus: CIRT management: Rapid alerts By M. E. Kabay In this column, I review three important aspects of early warnings in CIRT management: notification of vulnerabilities, notification of threats and notification of incidents. Vulnerabilities A computer incident response team (CIRT) relies on operations managers to maintain adequate defenses by maintaining up-to-date system and application software. The subject of patch management is complex and will be discussed in another series, but I can remind readers that there are many resources on which to draw for notification of newfound vulnerabilities. Each network-equipment and system-software vendor generally provides a notification service; many organizations have one of their employees subscribe to these to keep up with the news. A better approach, less susceptible to interruption, is to set up a special e-mail address for all the subscriptions and to assign one or more people to read that mail every day. If one of the team members is away on assignment or on vacation, be sure that a replacement person takes over the task of scanning the notices to spot anything that is relevant to your network configuration. Instead of forwarding the messages to an individual's mailbox, all of them can be kept in a separate mailbox accessible to everyone on the team. There are also many newsletters that summarize vulnerabilities; I particularly like "@RISK <mailto:"@RISK <mailto:> > : The Consensus Security Alert" from the SANS Institute; you can subscribe at no cost using: <https://portal.sans.org/> Finally, regular readers will recall that the Common Vulnerabilities and Exposures (CVE) dictionary ( <http://cve.mitre.org/> ) is a superb compendium of standardized names for vulnerabilities and exposures. MITRE writes, "CVE aspires to describe and name all publicly known facts about computer systems that could allow somebody to violate a reasonable security policy for that system." <http://cve.mitre.org/about/terminology.html> MITRE also uses the term "exposure" and defines it as "security-related facts that may not be considered to be vulnerabilities by everyone." You can download the CVE in various formats or you can use the ICAT Metabase ( <http://icat.nist.gov/icat.cfm> ) to search the CVE for various subsets of vulnerabilities (e.g., by product, version, type, and so on). At the time of this writing (late June) there were 6,663 vulnerabilities in the CVE. As a side note, of these, 1,383 involved buffer overflows (about one-fifth). Threats There's a wide range of resources keeping track of security threats. By staying up to date about new threats, you can improve your defenses before you are attacked; e.g., if particular attacks are growing in frequency and there are configuration changes or other measures you can take to stave them off, early warning is a real help. Some of the more popular alert letters - and where you can subscribe - include: * Computerworld Security Update <http://www.cwrld.com/nl/sub.asp> * Cybercrime-Alerts http://www.freelists.org/cgi-bin/list?list_id=cybercrime-alerts> * DHS/IAIP Daily Open Source Report <mailto:nipcdailyadmin () mail nipc osis gov> * Information Security This Week <mailto:security-subscribe () News WebUrb dk> * NewsBits <http://www.newsbits.net/> * RISKS <mailto:risks-subscribe () csl sri com> * SANS NewsBites <http://portal.sans.org/> * SC Infosecurity Opinionwire <http://content.hbpl.co.uk/subscribe1/?cmp=387> Editor's Note: Let us not forget Network World's own twice-weekly Virus and Bug Patch Alert for threats and vulnerabilities. If you're not already a subscriber you can sign up at: <http://www.nwwsubscribe.com/Default.aspx> Incidents Finally, it's important to know when there's an incident happening in your own system. Intrusion detection systems should be configured to alert CIRT or network management personnel at once when there are successful intrusions, disturbances of network performance, equipment malfunctions and other incidents. There are systems available to coordinate output from network and security systems for rapid notification; for example, the GFI LANguard Security Event Log Monitor (S.E.L.M.) is described as follows: "GFI LANguard Security Event Log Monitor (S.E.L.M.) performs event log based intrusion detection and network-wide event log management. GFI LANguard S.E.L.M. archives and analyzes the event logs of all network machines and alerts administrators in real time to security issues, attacks and other critical events. GFI LANguard S.E.L.M.'s intelligent analysis means network administrators need not be 'event gurus' to be able to: * Monitor for critical security events network-wide, and detect attacks and malicious network users. * Receive alerts about critical events on Exchange, ISA, SQL and IIS Servers. * Back up and clear event logs network-wide, and archive them to a central database." <http://www.gfi.com/lanselm/> Note: I have no financial interest whatsoever in the resources listed in this article. Mention of specific products should not be interpreted as endorsement. RELATED EDITORIAL LINKS Creating the CIRT: Establishing policies and procedures By M. E. Kabay As the DISA training course on CD-ROM about computer incident response teams succinctly puts it, "policies and procedures are not merely bureaucratic red tape." They are the scaffolding on which you can establish clear understanding and expectations for everyone involved in incident response. These living, evolving documents are tools that provide guidance on (to quote the CD-ROM): * Roles and responsibilities. * Priorities. * Escalation criteria. * Response provided. * Orientation. Policies are the statements of the desired goals; procedures are the methods for attaining those goals. Policies tend to be global and relatively stable; procedures can and should be relatively specific and can be adapted quickly to meet changing conditions and to integrate knowledge from experience. Policies cannot be promulgated without the approval and support of appropriate authorities in the organization, so one of the first steps is to identify those authorities. Another step is to gain their support for the policy project. All policies and especially CIRT policies should be framed in clear, simple language so everyone can understand them, and they should be made available in electronic form. In previous articles published by Network World Fusion, I have pointed out that hypertext can make policies more understandable by providing pop-up comments or explanations of difficult sections or technical terms. Similarly, procedures show how to implement the policies in real terms. For example, a policy might stipulate, "All relevant information about the time and details of a computer incident shall be recorded with regard for the requirements of later analysis and for possible use in a legal proceeding." That policy might spawn a dozen procedures describing exactly how the information is to be recorded, named, stored, and maintained through a proper chain of custody. For example, one procedure might start, "Using the Incident_Report form in the CIRT database accessible to all CIRT members, fill in every required field. Use the pull-down menus wherever possible in answering the questions." Again, as the DISA CD-ROM points out, these procedures should minimize ambiguity and help members of the team to provide a consistent level of service to the organization. A glossary of local acronyms and technical terms can be helpful as part of these procedures. Whenever policies and procedures are changed in a way that may affect users, it's important to let people know about the changes so that their expectations can be adjusted. The DISA course recommends using several channels of communications to ensure that everyone gets the message; for example, send e-mail, use phone and phone messages, send broadcast voicemail, announce the changes at staff meetings, and use posters and Web sites. DISA's Introduction to Computer Incident Response Team (CSIRT) Management, v1.0, is available free from the Information Assurance Support Environment at: http://iase.disa.mil/eta/index.html RELATED EDITORIAL LINKS Tester's Challenge: OS vendors defend security information efforts Network World, 03/29/04 http://www.nwfusion.com/news/2004/0329testchallenge.html AT&T unveils security alert service Network World, 03/29/04 http://www.nwfusion.com/news/2004/0329attprotect.html Time to enlist a 'national guard' for IT? Network World, 03/29/04 http://www.nwfusion.com/news/2004/0329vermont.html _______________________________________________________________ To contact: M. E. Kabay M. E. Kabay, Ph.D., CISSP, is Associate Professor in the Department of Computer Information Systems at Norwich University in Northfield, Vt. Mich can be reached by e-mail mailto:mkabay () norwich edu and his Web site http://www2.norwich.edu/mkabay/index.htm. _______________________________________________________________ This newsletter is sponsored by IMlogic Copyright Network World, Inc., 2004 Disclaimer: 22/7/2004 MPC Computers is providing the following information in compliance with federal regulations: MPC Computers, LLC 906 E. Karcher Road Nampa, Idaho 83687 1-888-224-4247 http://www.mpccorp.com If you wish to unsubscribe to all e-mail communications with MPC, please click on the link below. http://www.mpccorp.com/email/unsubscribe.html ********** Participation and subscription information for this EDUCAUSE Discussion Group discussion list can be found at http://www.educause.edu/cg/.
Current thread:
- Incident Response Schmitt, Dianne (Jul 21)
- <Possible follow-ups>
- Incident Response Ken Shaurette (Jul 22)