d

Computer Incident: The Complete Documentation

• This category contains 11 Papers
• The last paper was added on 2007-03-26 (YYYY-MM-DD)

Common Language for Computer Security Incidents (A)

Published on October 1998, by John D. Howard, Thomas A. Longstaff., ©Carnegie Mellon University.

Much of the computer security information regularly gathered and disseminated by individuals and organizations cannot currently be combined or compared because a “common language” has yet to emerge in the field of computer security. A common language consists of terms and taxonomies (principles of classification) which enable the gathering, exchange and comparison of information. This paper presents the results of a project to develop such a common language for computer security incidents. This project results from cooperation between the Security and Networking Research Group at the Sandia National Laboratories, Livermore, CA, and the CERT® Coordination Center at Carnegie Mellon University, Pittsburgh, PA.

Creating a Computer Security Incident Response Team: A Process for Getting Started

Published on May 08, 2003, by CERT, ©Carnegie Mellon University.

Keeping organizational information assets secure in today's interconnected computing environment is a true challenge that becomes more difficult with each new "e" product and each new intruder tool. Most organizations realize that there is no one solution or panacea for securing systems and data; instead a multi-layered security strategy is required. One of the layers that many organizations are including in their strategy today is the creation of a Computer Security Incident Response Team, generally called a CSIRT.

CSIRT Case Classification (Example for Enterprise CSIRT)

Published on 2007-02-19, by Dustin Schieber and Gavin Reid , ©FIRST.org, Inc.

It is critical that the CSIRT provide consistent and timely response to the customer, and that sensitive information is handled appropriately. This document provides the guidelines needed for CSIRT Incident Managers (IM) to classify the case category, criticality level, and sensitivity level for each CSIRT case. This information will be entered into the Incident Tracking System (ITS) when a case is created. Consistent case classification is required for the CSIRT to provide accurate reporting to management on a regular basis. In addition, the classifications will provide CSIRT IM’s with proper case handling procedures and will form the basis of SLA’s between the CSIRT and other Company departments.

Day After: Your First Response To A Security Breach (The)

Published on 2005, by Kelly J. Cooper, ©Microsoft Corporation.

The security incident is over. The techs have all gone home and are snug in their beds, dreaming of flawless code trees and buffer-overflow repellent. Upper management has done all the damage control they can. Everyone's shifting back into their normal activities and schedules. Everyone, that is, except you. What can you do to prevent this from ever happening again?

The best way to understand how a security incident happened is to conduct a post mortem. Incidents can range from an internal configuration error that resulted in system downtime, all the way up through an attack on your company, or even a natural disaster that impacted your company's physical location. Any event that didn't go as well as you hoped, or any set of processes that need to be checked, is a perfect candidate for a post mortem.

A post mortem is a review of what happened; a good post mortem delves into the who, what, how, when, and why of the incident. Even if the incident was clearly documented at the time, you're still going to need to review how things could have gone better in order to improve your processes, tools, and training for the future. These improvements may not prevent all future attacks, but they will allow you to prepare your business for the next incident.

Developing an Effective Incident Cost Analysis Mechanism

Published on June 12, 2002, by David A. Dittrich, ©SecurityFocus.

When it comes to calculating damages from computer security incidents, some in the media will tell you that it is impossible to come up with a value. At the same time, others will tell you that the Melissa Virus caused $80 million in damages to US businesses. Who is right? Can these damages be calculated, and if so, how?

Expectations for Computer Security Incident Response (RFC 2350)

Published on June 1998, by N. Brownlee, ©Network Working Group.

The purpose of this document is to express the general Internet community's expectations of Computer Security Incident Response Teams (CSIRTs). It is not possible to define a set of requirements that would be appropriate for all teams, but it is possible and helpful to list and describe the general set of topics and issues which are of concern and interest to constituent communities.

Forming an Incident Response Team

Published on 1995-01-01, by Danny Smith, ©AusCERT.

Forming an Incident Response Team (IRT) in the 1990s can be a daunting task. Many people forming an IRT have no experience with doing this. This paper examines the role an IRT may play in the community, and the issues that should be addressed both during the formation and after commencement of operations. It may be of benefit to existing IRTs as it may raise awareness of issues not previously addressed.

Handbook for Computer Security Incident Response Teams

Published on December 1998, by Moira J. West-Brown, Don Stikvoort, Klaus-Peter Kossakowski, ©Carnegie Mellon University.

This document provides guidance on the generic issues to consider when forming and operating a computer security incident response team (CSIRT). In particular, it helps an organization to define and document the nature and scope of a computer security incident response (CSIR) service, which is the core service of a CSIRT. The document discusses the functions that make up the service; how those functions interrelate; and the tools, procedures, and roles necessary to implement the service. This document also describes how CSIRTs interact with other organizations and how to handle often sensitive information. In addition, operational and technical issues are addressed, such as equipment, security, and staffing considerations.

How to set-up a CSIRT

Published on 2007-02-19, by ENISA, ©European Network and Information Security Agency.

The document at hand describes the process of setting up a Computer Security and Incident Response Team (CSIRT) from all relevant perspectives like business management, process management and technical perspective.

Implementing a Computer Incident Response Team in a Smaller, Limited Resource Organizational Setting

Published on March 15, 2003, by Mary (Missy) Hall, ©SANS Institute.

Information security risks are an ever-increasing threat today given the fact that the number of technically well informed users continues to grow, as well as the availability of the Internet on nearly every desktop. Protecting your organization s information in today s environment becomes a greater concern and importance and presents a formidable task for organizations to undertake. In response to the growing number of threats and intrusion activities, most organizations have established Security Programs and Plans to deal with the myriad of threats present for any infrastructure. Security Programs are essential to an organization and aid in protecting you from potential threats and vulnerabilities. However, Security Programs alone will not protect you and your organization from all incidents, nor will they cover the issues surrounding response to an incident. Many organizations are looking toward developing their own Computer Incident Response Team (CIRT) or possibly outsourcing in this area.

Incident Response Tools For Unix, Part Two: File-System Tools

Published on October 17, 2003, by Holt Sorenson, ©SecurityFocus.

This is the second article in a three part series on tools that are useful during incident response and investigation after a compromise has occurred on a Linux, OpenBSD, or Solaris system. The first article focused on system tools, this one focuses on file system tools, and the next article will discuss network and other tools. The information used in these articles is based on OpenBSD 3.2, Debian GNU/Linux 3.0 (woody), RedHat 8.0 (psyche), and Solaris 9 (aka Solaris 2.9 or SunOS 5.9). The tools focused on are generally tools that are available with the operating system, although there are some that may not be native to a given system that are discussed as well. If a tool that is discussed isn't available on the operating system you're using, the information on acquiring tools in the references section might help you out.