ITL Bulletin for January 2004

[William Knowles <wk () c4i org>]

Forwarded from: Elizabeth Lennon <elizabeth.lennon () nist gov>

ITL Bulletin for January 2004

COMPUTER SECURITY INCIDENTS: ASSESSING, MANAGING, AND 
CONTROLLING THE RISKS
Shirley Radack, Editor
Computer Security Division
Information Technology Laboratory
National Institute of Standards and Technology
Technology Administration
U.S. Department of Commerce

Attacks on computers and networks have become more numerous and more
severe in recent years. While preventing such attacks would be the
ideal course of action for organizations, not all computer security
incidents can be prevented. Every organization that depends upon
computers and networks to carry out its mission should identify and
assess the risks to its systems and to its information, and reduce
those risks to an acceptable level. An important component of this
risk management process is the assessment of the risks of security
incidents and the identification of effective ways to deal with them.
A well-defined incident response capability helps the organization
detect incidents rapidly, minimize losses and destruction, identify
weaknesses, and restore information technology operations speedily.

NIST Guide on Handling Security Incidents

NIST's Information Technology Laboratory recently issued Special
Publication (SP) 800-61, Computer Security Incident Handling Guide:
Recommendations of the National Institute of Standards and Technology.
Written by Tim Grance, Karen Kent, and Brian Kim, NIST SP 800-61
provides practical guidance to help organizations establish an
effective incident response program, analyze and respond to
information security incidents, and reduce the risks of future
incidents. The new guide replaces NIST SP 800-3, Establishing a
Computer Security Incident Response Capability (CSIRC).

The new incident handling guide contains useful information for
computer security incident response teams (CSIRTs), system and network
administrators, security staff, technical support staff, chief
information officers (CIOs), and computer security program managers
who are responsible for handling security incidents. Topics discussed
include the need for and the organization of incident response teams,
and how to manage the incident handling process.  Specific
recommendations are provided for handling five types of incidents:
denial of service (DoS), malicious code, unauthorized access,
inappropriate usage, and multiple component incidents.

Appendices include a consolidated list of recommendations that are
discussed in the guide, incident response scenarios, and questions for
use in incident response exercises.  Also included in the appendices
are suggested items of information to be collected about each
incident, a glossary, an acronym list, lists of online resources and
other references, frequently asked questions about incident response
activities, and the steps to follow when handling a security incident.

This ITL Bulletin summarizes NIST SP 800-61, which is available at
http://csrc.nist.gov/publications/nistpubs/index.html.

Planning and Organizing an Incident Handling Capability

Federal departments and agencies are specifically directed by the
Federal Information Security Management Act (FISMA)  of 2002 to
develop and implement procedures for detecting, reporting, and
responding to security incidents. Federal civilian agencies are
responsible for designating a primary and secondary point of contact
(POC) to report all incidents to the Federal Computer Incident
Response Center (FedCIRC) in the Department of Homeland Security, and
for documenting corrective actions that have been taken and their
impact. Further, policy guidance issued by the Office of Management
and Budget (OMB) requires that agencies have a capability to provide
help to users when security incidents occur in their systems and to
share information concerning common vulnerabilities and threats (OMB
Circular No. A-130, Appendix III).

The participation of many people within the organization is important
in planning and implementing an incident response program, and in
making the decisions that are key to a successful program. The
organization should adopt an incident response policy which defines
which events are considered incidents, establishes the organizational
structure for incident response, defines roles and responsibilities,
and lists the requirements for reporting incidents.

An incident response team with appropriate technical skills should be
selected from the different team structures and staffing models that
are discussed in the guide, and training should be provided to team
members. The services that will be provided by the team should be
decided.  Procedures are needed to assess the impact of incidents, and
effective methods of collecting, analyzing, and reporting data should
be established. Careful planning and dedicated resources are essential
to establishing and maintaining a successful incident handling
capability that will enable the organization to respond quickly and
effectively when incidents occur.

Using Effective Security Methods for Networks, Systems, and
Applications to Reduce the Frequency of Incidents

It is less costly and more effective to prevent incidents than to try
to fix the problems that occur when security controls are inadequate.
Many security incidents can overwhelm the resources and capacity of
the organization to respond and can result in delayed or incomplete
recovery.  Extensive damage may occur, and systems and information may
not be available for long periods. Risk assessments should be
performed regularly and the identified risks reduced to an acceptable
level. Threats to systems and information should be continuously
monitored using intrusion detection systems and other methods. The
incident response team should have access to tools, resources, and
information such as contact lists, encryption software, network
diagrams, and security patches. When the security of networks,
systems, and applications is effectively protected and maintained, the
incident response team can focus on handling serious problems. See
Sections 3.1, 4.2, 5.2, 6.2, and 7.2 of the guide for specific
recommendations for maintaining adequate security.

Interacting with Other Organizations

Clear procedures should be established to communicate when necessary
with internal groups such as the human resources, public affairs, and
legal departments, and with external organizations such as computer
incident response teams and law enforcement officials. A list of such
contacts should be developed and maintained. Guidelines are needed so
that only the appropriate information is shared with the right
parties. The inappropriate release of sensitive information could lead
to greater disruption and financial loss than the incident itself by
revealing information useful to the attacker or another would-be
attacker.

Maintaining Staff Awareness of the Importance of Incident Detection
and Analysis

Logging and computer security software should be checked for possible
signs of incidents. Event correlation software and centralized logging
can be of great value in performing an initial analysis of the
voluminous data that is collected and in selecting the events that
require human review. The effectiveness of the automated analysis
process depends on the quality of the data that is collected.  
Organizations should establish standards and procedures to make
certain that adequate information is collected by the logging and
security software, and to assure that data collected and analyzed by
the automated software is reviewed regularly by staff members.

Developing Written Guidelines for Prioritizing Incidents

Priorities for the handling of individual incidents should be
established, based on the following considerations:

* The criticality of the affected resources (e.g., public 
  web server, user workstation)

* The current and potential technical effect of the 
  incident (e.g., root compromise, data destruction).

The business impact of the incident depends upon these considerations.
For example, data destruction on a user workstation might result in a
minor loss of productivity.  Root compromise of a public web server
might result in a major loss of revenue, productivity, access to
services, and reputation, as well as the release of confidential data,
such as credit card numbers or Social Security numbers.

Clear decisions about priorities and how to react in various
circumstances will help the incident response team respond quicker and
more effectively, thereby reducing the cost, duration, and overall
business impact on the organization. The organization should develop a
Service Level Agreement (SLA) to document the appropriate actions and
maximum response times. This documentation is particularly valuable
for organizations that outsource components of their incident response
programs.

Applying the Lessons Learned from Incidents

After a major incident has been handled, the organization should hold
a meeting to review how effective the incident handling process was
and to identify needed improvements to existing security controls and
practices. Meetings to go over lessons learned should also be held
periodically for lesser incidents. The information accumulated from
all of these review meetings should be used to identify systemic
security weaknesses and deficiencies in policies and procedures. The
follow-up reports generated for each resolved incident can be valuable
for evidentiary purposes, for reference in handling future incidents,
and in training new incident response team members. An incident
database, with detailed information on each incident that occurs, can
be another useful source of information for incident handlers.

Maintaining Situational Awareness During Large-Scale Incidents

Communications within the organization and with external groups can be
challenging and complex when large-scale incidents are handled. Many
people within the organization may play a role in incident response,
and the organization may need to communicate rapidly and efficiently
with various external groups. Many pieces of information must be
collected, organized, and analyzed to enable the right decisions to be
made and executed.  Situational awareness in the organization can be
maintained when handling large-scale incidents by:

* Establishing, documenting, maintaining, and exercising 
on-hours and off-hours contact and notification mechanisms 
for various individuals and groups within the organization 
(e.g., chief information officer [CIO], head of information 
security, IT support, business continuity planning) and 
outside the organization (e.g., incident response 
organizations, counterparts at other organizations).

* Planning and documenting guidelines for the 
  prioritization of incident response actions based on 
  business impact.

* Preparing one or more individuals to act as lead 
  officials who are responsible for gathering information 
  from the incident handlers and other parties, and 
  distributing relevant information to the parties that need it.

* Practicing the handling of large-scale incidents through 
  exercises and simulations on a regular basis. Such 
  incidents happen rarely, so incident response teams often 
  lack experience in handling them effectively.

Handling Specific Types of Incidents

NIST SP 800-61 specifies recommended procedures for preventing and
dealing with the following kinds of incidents:

- Denial of Service (DoS)-an attack that prevents or impairs the
authorized use of networks, systems, or applications by exhausting
resources

- Malicious Code-a virus, worm, Trojan horse, or other code-based
malicious entity that infects a host

- Unauthorized Access-a person gains logical or physical access
without permission to a network, system, application, data, or other
resource

- Inappropriate Usage-a person violates acceptable computing use
policies

- Multiple Component-a single incident that encompasses two or more
incidents; for example, a malicious code infection leads to
unauthorized access to a host, which is then used to gain unauthorized
access to additional hosts. Check the guide for detailed
recommendations and advice to prevent and reduce the damage that might
be caused by each of these kinds of incidents.

More Information

For a list of references, online tools, and resources on incident
response activities, consult Appendices F and G of NIST SP 800-61.

The following Special Publications (SPs) provide help to organizations
in planning, developing, operating, and maintaining incident response
programs. These publications are available in electronic format from
the NIST Computer Security Resource Center at
http://csrc.nist.gov/publications.

NIST SP 800-18, Guide for Developing Security Plans for Information
Technology Systems, discusses developing and updating security plans.

NIST SP 800-28, Guidelines on Active Content and Mobile Code, gives
advice on the use of active content (e.g., java applets, macros,
etc.), identifies the risks, and suggests strategies for managing
these risks.

NIST SP 800-30, Risk Management Guide for Information Technology
Systems, discusses the risk-based approach to security and provides
guidance on conducting risk assessments.

NIST SP 800-31, Intrusion Detection Systems (IDSs), and NIST SP
800-41, Guidelines on Firewalls and Firewall Policy, provide
information on using and deploying IDSs and firewalls.

NIST SP 800-35, Guide to Information Technology Security Services,
covers evaluating, selecting, and managing security services
throughout the life cycle.

NIST SP 800-40, Procedures for Handling Security Patches, provides
guidance on suggested polices and methods to systematically and
effectively implement an organizational patch management strategy.

NIST SP 800-42, Guidelines on Network Security Testing, describes
available security testing techniques, their strengths and weaknesses,
and the recommended frequencies for testing as well as strategies for
deploying network security testing.

NIST SP 800-44, Guidelines on Securing Public Web Servers, and NIST SP
800-45, Guidelines on Electronic Mail Security, assist organizations
in installing, configuring, and maintaining secure public web servers
and e-mail servers.

NIST SP 800-53, Recommended Security Controls for Federal Information
Systems, provides recommended security controls based on system impact
level (available in draft at
http://csrc.nist.gov/publications/drafts.html).

The following organizations (and others listed in Appendix G of the
guide) provide useful information on incident handling:

Federal Computer Incident Response Center (FedCIRC), the federal
government's incident response activity http://www.fedcirc.gov

CERT(r) Coordination Center (CERT(r)/CC), nongovernmental incident
response activity located at Carnegie Mellon University
http://www.cert.org

Information Analysis Infrastructure Protection (IAIP) in the
Department of Homeland Security (DHS) http://www.nipc.gov

Center for Education and Research in Information Assurance and
Security (CERIAS(r)) at Purdue University
https://cirdb.cerias.purdue.edu

SANS Institute Reading Room http://www.sans.org/rr

National Institute of Justice (NIJ) Electronic Crime Program
http://www.ojp.usdoj.gov/nij/sciencetech/ecrime.htm

Disclaimer
Any mention of commercial products or reference to commercial
organizations is for information only; it does not imply
recommendation or endorsement by NIST nor does it imply that the
products mentioned are necessarily the best available for the purpose.



-
ISN is currently hosted by Attrition.org

To unsubscribe email majordomo () attrition org with 'unsubscribe isn'
in the BODY of the mail.