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

Current thread:

Incident Response Schmitt, Dianne (Jul 21)
- <Possible follow-ups>
- Incident Response Ken Shaurette (Jul 22)