Incident Handling Steps

COMPUTER SECURITY INCIDENT HANDLING STEPS

Computer security incident handling can be divided into six phases:
preparation, identification, containment, eradication, recovery, and
follow-up. Understanding these stages, and what can go wrong in each,
facilitates responding more methodically and avoids duplication of effort.

PHASE 1: PREPARATION: In the heat of the moment, when an incident has been
discovered, decision-making may be haphazard. By establishing policies,
procedures, and agreements in advance, you minimize the chance of making
catastrophic mistakes. The following steps should be taken in the
preparation phase:

Establish a security policy, develop management support for an incident
handling capability, monitor and analyze the network traffic, assess
vulnerabilities, configure your systems wisely, install updates regularly,
and establish training programs.

Post warning banners.

Establish an organizational approach for handling incidents. Select incident
handling team members and organize the team. Establish a primary point of
contact and an incident command and communications center. Conduct training
for team members. Involve system administrators and network managers early.

Establish a policy for notifying outside organizations that may be connected
to operating unit systems.

Update the operating unit's business continuity plan to include computer
incident handling.

Passwords and encryptions should be up-to-date and accessible.

Back up systems on a regular basis.
Develop a listing of law enforcement agencies and Computer Incident Response
Teams (such as FedCIRC at 1-888-282-0870) to notify when an incident occurs.
PHASE 2: IDENTIFICATION: Identification involves determining whether or not
an incident has occurred, and if one has occurred, determining the nature of
the incident. The following steps should be taken in the identification
phase:
Assign a person to be responsible for the incident.

Determine whether or not an event is actually an incident. Check for simple
mistakes such as errors in system configuration or an application program,
hardware failures, and most commonly, user or system administrator errors.

Identify and assess the evidence in detail and maintain a chain of custody.
Control access to the evidence.

Coordinate with the people who provide operating unit network services.

Notify appropriate officials such as immediate supervisors or managers, the
operating unit's IT Security Officer, and the Department of Commerce's IT
Security Program Manager.
PHASE 3: CONTAINMENT: During this phase the goal is to limit the scope and
magnitude of an incident in order to keep the incident from getting worse.
The following steps should be taken in the containment phase:
Deploy the on-site team to survey the situation.

Keep a low profile. Avoid looking for the attacker with obvious methods.

Avoid potentially compromised code. Intruders may install trojan horses and
similar malicious code in system binaries.
Back up the system. It is important to obtain a full back up of the system
in order to acquire evidence of illegal activity. Back up to new (unused)
media. Store backup tapes in a secure location.

Determine the risk of continuing operations.

Change passwords on compromised systems and on all systems that regularly
interact with the compromised systems.
PHASE 4: ERADICATION: This phase ensures that the problem is eliminated and
vulnerabilities that allow re-entry to the system are eliminated. The
following steps should be taken in the eradication phase:
Isolate the attack and determine how it was executed.

Implement appropriate protection techniques such as firewalls and/or router
filters, moving the system to a new name/IP address, or in extreme cases,
porting the machine's function to a more secure operating system.

Perform vulnerability analysis.

Remove the cause of the incident.

Locate the most recent clean back up (to prepare for system recovery).
PHASE 5: RECOVERY: This phase ensures that the system is returned to a fully
operational status. The following steps should be taken in the recovery
phase:
Restore the system.

Validate the system. Once the system has been restored, verify that the
operation was successful and the system is back to its normal condition.
Decide when to restore operations. Management may decide to leave the system
offline while operating system upgrades and patches are installed.

Monitor the systems. Once the system is back on line, continue to monitor
for back doors that escaped detection.
PHASE 6: FOLLOW-UP: This phase is important in identifying lessons learned
that will prevent future incidents.
Develop a detailed incident report and provide copies to management, the
operating unit's IT Security Officer, and the Department of Commerce's IT
Security Program Manager.

Send recommended changes to management.

Implement approved actions.

Note: This listing contains extracts from The SANS INSTITUTE's guide on
"Computer Security Incident Handling: Step-by-Step," version 1.5, 1998.


----------------------------------------------------------------------------
----


  (Operating Unit Name) Information Technology System Incident Report
  1. Date and time of incident:
2. System name/title:
3. System number
4. Responsible official for the system
(name, telephone number, email address)
5. System sensitivity level
(unclassified, confidential, secret, top secret)
6. System category
(major application or general support)
7. Hardware category
(PC, LAN, WAN, minicomputer, mainframe, other)
8. Operating system name & version
9. System location
(address including building & room number)

10. Type of incident or violation
(compromise of integrity, denial of service, misuses, damage, intrusions)


11. Method of discovery and name, telephone number, and email address of
individual making discovery
12. What steps were taken to identify the source.
List source (if known)

13. Apparent effect








14. Impact on operation, type of damage






15. Severity, including hours devoted to recovery and any additional costs
incurred


16. Proliferation, other internal or external systems affected




17. Action taken (was damage corrected, were fixes installed to prevent
further attacks)








18. Who was notified, including outside organizations










19. Additional Comments


Back to the Index