ITS 4350 - Disaster Recovery

Chapter 4, Incident Response: Planning

Objectives:

This lesson is about chapter 4. Objectives important to this lesson:

1. Incident response policy
   
2. Incident response planning
3. During the incident and after
4. 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.
1. Information assets have been placed at risk.
2. The threat may succeed.
3. 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.