LabMice.net - The Windows 2000\XP\.NET Resource Index
Home | About Us | Search

Last Updated December 16, 2003

Windows 2003
Windows 2000
Windows XP
BackOffice
Book Reviews
Career Tools
Device Drivers
Hardware Guides
MCSE Toolkit
Networking
Service Packs
Scripting
Security
  Anti-Virus
  Articles & Whitepapers
  Books on Security
  Cryptography
  Disaster Recovery
  FAQ's & Tutorials
  Firewalls
  Forensics
  Hacking
  Honeypots
  Incident Response
  Intrusion Detection
  Kerberos
  Legal Resources
  Online Seminars
  Password Security
  Penetration Testing
  Security Links
  Securing Networks
  Social Engineering
  Vulnerabilities
Utilities
Cybercheese

 


 

 

 

 

 

 

 

 

Computer Incident Handling and Response

Embezzlements, theft of trade secrets, Internet account abuses and unauthorized outside employment activities on company time are common occurrences in the workplace. As a result, many corporations and government agencies have created Incident Response Teams which deal with computer-related abuses and intrusions when they occur.
Where to Start....

An Introduction to Incident Handling
Incident handling is a generalized term that refers to the response by a person or organization to an attack. An organized and careful reaction to an incident can mean the difference between complete recovery and total disaster. This paper will provide a logical approach to handling two common forms of attack - virus outbreak and system compromise. The method that this article will propose includes the following sequence of steps that should be followed in the case of all types of attack. Source: SecurityFocus.com (Nov 2000)

An Introduction to Incident Response and Handling in a Microsoft Environment: A Primer for the Unprepared Administrator
An essential primer for the unprepared administrator, this article examines methods of attack and network intrusion detection, and suggests options for a response. Source: LabMice.net

Building an Incident Response Program To Suit Your Business
A security incident refers to an adverse event in an information system, and/or network, or the threat of the occurrence of such an event. Incidents can include but are not limited to unauthorized access, malicious code, network probes and denial of service attacks (1). Regardless of the criticality of the incident, it is essential that all steps outlined in this program are followed and are. The purpose of this paper is to outline the key concepts of an Incident Response Program (IRP). Although every organization is unique, there are basics components that should be included to mitigate disaster. Source: SANS.org (July, 2001)

Computer Incident Response and Computer Forensics Overview
When a compromise of security or an unauthorized/illegal action associated with a computer is suspected, it is important that steps are taken to ensure the protection of the data within the computer and/or storage media. The stored data is needed to determine the level of security compromise and location of potential evidence concerning the unauthorized or illegal act. This paper will focus on the incident response and computer forensics on the personal or desktop computers. The incident response and forensic procedures and techniques for servers may additional knowledge and tools. Source: SANS.org (March 6, 2001)

Fast Path to Security Incident Response and Recovery
Every network will eventually be the victim of a computer security incident. System administrators need to be prepared for security incidents and respond quickly to minimize and repair the damage. For the busy administrator, this article provides a quick overview of the steps involved in an incident response, with links to more in depth resources if required. Source: Microsoft Technet

Moment's Notice: The Immediate Steps of Incident Handling
This article covers the topic of response, including matters of scale, operational constraints, appropriate countermeasures, legal concerns, and hints for proper implementation. While not technical in nature, this study of response procedures might give you some insight on how to handle the more ambiguous elements of systems security: human factors, policy, and time.

Incident Handling

Corporate Incident Handling Guidelines
Incidents are an unfortunate fact of life in any systems environment. They can be extremely visible and disruptive (eg: widespread virus outbreaks) or entirely unnoticed but extremely damaging (eg: loss of confidential growth plans). There is a vast amount of information available to help you deal with most types, but if you have done no preparation you will struggle to find it when you need it at short notice. Incidents are also likely to occur at the least convenient time when the right people are not available. If you are a large multinational corporation without a large security function, this paper will help you approach some of the common problems in preparing incident handling procedures. Source: SANS.org (November 14, 2001)

Computer Incident Response Team
No company©s security policy should be considered complete until procedures are put into place that allow for the handling and recovery from even the most devastating of incidents. One possible solution is the inclusion a Computer Incident Response Team (CIRT) within the company©s incident response procedures. Source: SANS.org (September 2001)

Incident Response and Creating the CSIRT in Corporate America
The purpose of this document is to discuss why these challenges may exist and suggest a way to successfully implement a formal incident response organization. However, the needs of each organization are unique. Therefore, the reader should keep in mind that these are guidelines and should take their company©s needs into consideration. Source: SANS.org (September 2001)

Incident Response in A Global Environment
A six-step process for incident handling includes: prepare, detect, contain, eradicate, recover and lessons learned. Technical staffs and support teams throughout the world execute the four middle steps © detect, contain, eradicate and recover ? routinely, often without documentation to guide them. They just do it. However preparing an incident response procedure and team is not as universal. The purpose of this writing is to share one company©s experience in working the first step: establishing an Incident Response Team and Procedure and doing so in a "Follow the Sun" technology support environment. Source: SANS.org (May 2001)

Information Security: Handling Compromises
While the corporate sector may not be guarding national secrets, they are protecting valuable information such as trade secrets, financial documents and personal information. Often this information is kept (or should be kept) sectioned from each other. In the case of trade secrets or financial documents such as earning forecasts, this information could only be available to a select few. Similar to the DoD, companies would want to make sure that this information did not get onto an unsecured part of the network and if it did, make sure it got cleaned in such a way that no one, from the casual user to the determined hacker, could recreate the data. This article discusses exactly how companies should go about eradicating confidential information from unsecured areas of their network.  Source: SANS.org (August 2001)

Handbook for Computer Security Incident Response Teams
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. Source: Carnegie Mellon

Practical IR - Sooner or later, you'll have a security event. If you fail to plan, you plan to fail
It's hard to plan for the unexpected. Yet that's precisely what incident response (IR) teams are required to do. The problem is that many organizations are failing at this task. Nobody said it would be easy. But developing a "living" IR plan shouldn't intimidate you. As always, you have to start with the basics. Source: InfoSecurityMag (April 2002)

Reporting Unauthorized Intrusions: A "How To" Guide
The scope of this document is limited to the actions that should be taken after an illegal infiltration into a private or corporate network. It is assumed that the reader already has a good working knowledge of technology security. Source: SANS.org (July 26, 2001)

Incident Response Teams
CERT
The CERT© Coordination Center (CERT/CC) is a center of Internet security expertise, located at the Software Engineering Institute, a federally funded research and development center operated by Carnegie Mellon University

FedCIRC
The Federal Computer Incident Response Center (FedCIRC) is the central information technology incident coordination and analysis facility of the civilian agencies and departments of the Federal Government. Primary functions include offerings in computer security incident prevention, reporting, analysis, and recovery.

Forum of Incident Response and Security Teams (FIRST)
An almost continuous stream of security-related incidents is affecting millions of computer systems and networks throughout the world. To address this threat, a growing number of government and private sector organizations around the globe have established a coalition to exchange information and coordinate response activities. This coalition, the Forum of Incident Response and Security Teams (FIRST), brings together a variety of computer security incident response teams from government, commercial, and academic organizations. FIRST aims to foster cooperation and coordination in incident prevention, to prompt rapid reaction to incidents, and to promote information sharing among members and the community at large.

 
 

Entire contents
© 1999-2003 LabMice.net and TechTarget
All rights reserved

This site and its contents are Copyright 1999-2003 by LabMice.net. Microsoft, NT, BackOffice, MCSE, and Windows are registered trademarks of Microsoft Corporation. Microsoft Corporation in no way endorses or is affiliated with LabMice.net. The products referenced in this site are provided by parties other than LabMice.net. LabMice.net makes no representations regarding either the products or any information about the products. Any questions, complaints, or claims regarding the products must be directed to the appropriate manufacturer or vendor.