|
Windows 2003 Windows 2000
Windows XP
BackOffice
Best of the Web
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
User Groups
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. |