|
|
ITS 4350 - Disaster Recovery
Chapter 4, Incident Response: Planning
Objectives:
This lesson is about chapter 4. Objectives important to this
lesson:
- Incident response policy
- Incident response planning
- During the incident and after
- Before the incident
Concepts:
Chapter 4
Incident response covers all incidents handled by a particular
team. In the context of this chapter, incident response will cover the
actions of teams that handle security incidents. Be aware that not all
incidents that threaten a company involve security, but those are the
incidents that concern us in this course.
The text spends several pages on organizing a committee, on
choosing a model to follow, and on getting ready to plan for security
incidents. We can skim that material and continue on page 136, where
the material is still mysteriously engaged in forming an official
statement and commitment from the organization that it is going to
handle incidents. We should all expect that they will, shouldn't we?
Moving on to page 138, the author considers creating an
Incident Response Plan. Some terminology is reviewed:
- adverse event, incident - These are two terms that mean the
same thing in the context of chapter 4. An event that has or may
compromise our security. Be aware that there can be events and incidents that have nothing to do with information security.
- incident response - A set of procedures that will vary with
the nature and severity of the incident. The goals begin with
containment, identification, and remediation.
- information security incident - An incident can be classified as an
information security incident if three tests are met.
- Information assets have been placed at risk.
- The threat may succeed.
- The IT assets' confidentiality, integrity, and/or availability are at risk.
The
text cautions us to remember
that we are assuming that an adverse event has occurred. IR is
concerned with reacting to the event, not preventing it. This is not
helpful, and not very accurate. On page 139, the author introduces the
three aspects to the IR documentation that the IR committee must
produce, one of which addresses a different attitude:
- during the incident - Who must do what, given the kind of incident being discussed.
- after the incident
- How do we proceed once the incident is over? Do we go into disaster
recovery? Do we simply resume normal operations if the incident was not
severe? How about making notes on what went right and what went wrong
with the "during the incident" plan? Revising the plan for next time
can't wait until the next time it happens.
- before the incident
- With their knowledge of the contents of the documents prepared above,
the committee can state what the organization should do in order to be
prepared to carry out the steps listed above. How do we store backups,
and when are they made? How do we notice that an incident is happening,
and how do we handle it as soon as possible? What are the contents of
the Business Continuity plan and the Disaster Recovery plan? What
should we do during an incident to flow into those plans better?
Up
to now, it has not been clear that you should have a separate incident
response plan for each kind of incident that you consider possible. It
may be useful to regularly consider incidents that have occurred to
similar organizations, and to create plans to use should that kind of
incident happen to your organization. The text addresses this on page
141, mentioning that a different skill set will be needed for different
kinds of incidents. This should be addressed in the incident plans as
well.
As an example, the text discusses various steps in the life of an incident:
- a trigger event
occurs - There may be a call from a user, a device failure that
particular staff notice, a performance degradation, or anything else
that causes someone to ask why something is not working.
- IT staff are contacted
- Somehow, possibly through a help desk, a connection is made to IT
staff who become what the text calls a reaction force. In the real
world, this is not very formal, except in the cases of high priority
callers or security related events.
- actions are taken - The actions taken depend greatly on the nature of the event, but we can assume that they will include gathering facts and evidence, troubleshooting and diagnosing, and containment and remediation. This phase continues until the incident is over.
- after the incident - Typically, information is shared, documents are created and completed, and recommendations are made for changes to the incident plan, or creation of one for new incidents.
- before the incident - See below.
The longest section of the chapter covers the time before an incident
happens. It is placed at this point in the chapter because a proper
plan for any kind of incident is greatly enlightened by the planners
having seen such an incident, and having the insights that come from
dealing with it. It is likely that the material gathered during and
after an incident will include phrases like "if only we had known x, or had watched y".
This kind of insight leads to practices that will create faster, more
accurate diagnoses in the future, and may lead to prevention of such
incidents.
We could also refer to the time before an incident as the time
between incidents. Security incidents do not happen every day. Many are
stopped at firewalls by good firewall rules. However, following the
logic of the text, we will assume that a recent event has been handled
well and is now well documented. An IR plan has been revised or written
for it. In that case, the text recommends that several steps take place
to be ready for next time.
- desk check - Responsible experts should read copies of the plan, suggest revisions, and pass the revised plan to the next stage.
- structured walk-through - People who would be involved in
carrying out the plan read through it together, making sure everyone
understands their intended roles and actions.
- simulation - An exercise is scheduled that requires each
person in the walk-through to "almost" carry out their tasks in the
plan. This will bring out problems that would not appear in the earlier
stages, such as not having a resource, or not having assumed access to
assets.
- parallel testing - This is not really different from the
actions in the simulation, but it is meant to be one step closer to
actually carrying out the plan.
- full interruption - This is a live test of the plan,
actually isolating LAN segments or turning off access as the plan
requires. One learns more about the actual work involved and about the
validity of the plan.
- war gaming - This is a simulation of real system attack and defense. It is compared in the text to the National Collegiate Cyber Defense Competition, and to other events that provide the chance to use real skills.
The last major portion of the chapter discusses training
the writers of plans, the staff who will carry out plans, the general
staff of an organization, and general management of the organization.
Everyone needs to know that things happen, and what to do when they
happen. The chapter finishes with some recommendations about preparing
and storing the IR plan documents.
Note that they recommend a hard copy, easily identified and readable in
case there is an outage that includes limited or no access to your
computer systems.
|