Incident Response Plans
An incident response plan tells the staff how to deal with a security
incident. In contrast to the business continuity plan, the goal of incident
response is handling the current security incident, without regard for the
business issues. The security incident may at the same time be a business
catastrophe, as addressed by the business continuity plan. But as a specific
security event, it might be less than catastrophic (that is, it may not
interrupt business severely) but could be a serious breach of security, such as
a hacker attack or a case of internal fraud. An incident could be a single
event, a series of events, or an ongoing problem.
An incident response plan
should
define what constitutes an
incident
identify who is responsible
for taking charge of the situation
describe the plan of action
The plan usually has three
phases: advance planning, triage, and running the incident. A fourth phase,
review, is useful after the situation abates so that this incident can lead to
improvement for future incidents.
Advance Planning
As with all planning
functions, advance planning works best because people can think logically,
unhurried, and without pressure. What constitutes an incident may be vague. We
cannot know the details of an incident in advance. Typical characteristics
include harm or risk of harm to computer systems, data, or processing; initial
uncertainty as to the extent of damage; and similar uncertainty as to the
source or method of the incident. For example, you can see that the file is
missing or the home page has been defaced, but you do not know how or by whom
or what other damage there may be.
In organizations that have
not done incident planning, chaos may develop at this point. Someone calls the
network manager. Someone sends e-mail to the help desk. Someone calls the FBI,
the CERT, the newspapers, or the fire department. People start to investigate
on their own, without coordinating with the relevant staff in other
departments, agencies, or businesses. And there is a lot of conversation,
rumor, and misinformation: more heat than light.
With an incident response
plan in place, everybody is trained in advance to call the designated leader.
There is an established list of people to call, in order, in case the first
person is unavailable. The leader decides what to do next, and he or she begins
by determining if this is a real incident or a false alarm. Indeed, natural
events sometimes look like incidents, and the facts of the situation should be
established first. If the leader decides this may be a real incident, he or she
invokes the response team.
Response Team
The response team is the set
of people charged with responding to the incident. The response team may
include
director: person in charge of
the incident, who decides what actions to take and when to terminate the
response. The director is typically a management employee.
lead technician: person who
directs and coordinates the response. The lead technician decides where to
focus attention, analyzes situation data, documents the incident and how it was
handled, and calls for other technical people to assist with the analysis.
advisor(s): legal, human
resources, or public relations staff members as appropriate.
In a small incident a single
person can handle more than one of these roles. Nevertheless, it is important
that a single person be in charge, a single person who directs the response
work, a single point of contact for "insiders" (employees, users),
and a single point of contact for "the public."
To develop policy and
identify a response team, you need to consider certain matters.
Legal issues: An incident has
legal ramifications. In some countries, computer intrusions are illegal, so law
enforcement officials must be involved in the investigation. In other places,
you have discretion in deciding whether to ask law enforcement to participate.
In addition to criminal action, you may be able to bring a civil case. Both
kinds of legal action have serious implications for the response. For example,
evidence must be gathered and maintained in specific ways in order to be usable
in court. Similarly, laws may limit what you can do against the alleged
attacker: Cutting off a connection is probably acceptable, but launching a
retaliatory denial-of-service attack may not be.
Preserving evidence: The most
common reaction in an incident is to assume the cause was internal or
accidental. For instance, you may surmise that the hardware has failed or that
the software isn't working correctly. The staff may be directed to change the
configuration, reload the software, reboot the system, or similarly attempt to
resolve the problem by adjusting the software. Unfortunately, each of these
acts can irreparably distort or destroy evidence. When dealing with a possible
incident, do as little as possible before "dusting for fingerprints."
Records: It may be difficult
to remember what you have already done: Have you already reloaded a particular
file? What steps got you to the prompt asking for the new DNS server's address?
If you call in an outside forensic investigator or the police, you will need to
tell exactly what you have already done.
Public relations: In handling
an incident your organization should speak with one voice. You risk sending
confusing messages if too many people speak. It is especially important that
only one person speak publicly if legal action may be taken. An unguarded
comment may tip off the attacker or have a negative effect on the case. You can
simply say that an incident occurred, tell briefly and generally what it was,
and state that the incident is now under control and normal operation is
resuming.
After the Incident Is Resolved
Eventually, the incident
response team closes the case. At this point it will hold a review after the
incident to consider two things:
Is any security control
action to be taken? Did an intruder compromise a system because security
patches were not up-to-date; if so, should there be a procedure to ensure that
patches are applied when they become available? Was access obtained because of
a poorly chosen password; if so, should there be a campaign to educate users on
how to strong passwords? If there were control failures, what should be done to
prevent similar attacks in the future?
Did the incident response
plan work? Did everyone know whom to notify? Did the team have needed
resources? Was the response fast enough? What should be done differently next
time?
The incident response plan
ensures that incidents are handled promptly, efficiently, and with minimal
harm.
Related Topics
Privacy Policy, Terms and Conditions, DMCA Policy and Compliant
Copyright © 2018-2023 BrainKart.com; All Rights Reserved. Developed by Therithal info, Chennai.