In the last chapter, we were treated to a brief exposure to
Disaster Recovery Plans in the recovery phase of a Business Continuity
Plan. The biggest difference about a Disaster
Recovery Plan is that it is activated and used once the disaster is over. In the opinion of
our current author, the DRP may actually be part of the BCP. I think I
see his point, that we begin to transition to normal operations while
still using a BCP. However we ended the last chapter with the thought
that we would stop using the BCP when the disaster ends, and we have
just settled on the idea that the DRP starts once the disaster is over,
so the most I think we should allow is a little overlap from the BCP to
On page 372, the text offers five more terms that the author associates with DRPs. However, some of them (like business interruption planning) sound too much like BCP, and not enough like DRP.
The author continues his custom of assuming we did not read the previous chapter by presenting a set of five critical concepts, four of which we have seen before (in this book, blast it!). There is one new one:
The text briefly addresses reasons for having a DRP, which
should be known to us by now. If there is a disaster, the other plans
we have prepare for it, deal with it, and carry on during it. The DRP
covers returning to normal operations, which our organization needs to
do. The author complicates the issue on page 373, discussing saving
lives and ensuring business continuity, which were covered in other
chapters, in other plans. I suppose he is taking the point of view that
if we only had a DRP, it
would have to include the others plans as well. Aye, and if
my grandmother had wheels, she'd be a wagon. (Go to video time 1:20.)
When our plan book has a chapter for every type of plan, we are most likely to use a DRP for its intended purpose, which is returning to our pre-crisis operational state.
The text cautions us to include Critical Success Factors (CSFs) when we write a DRP. These are things that make it possible to create a useful DRP. You could argue that they would contribute to the success of any of our plans. These CSFs are focused to help create a good DRP.
The text lists nine elements of a DRP on page 384. It elaborates on them through page 394. You should glance at this material to get an idea about each area that is not familiar to you. Try not to get confused by the overlap with other plans. I believe that the author is working from the point of view that the DRP may be our only contingency plan.
As should be familiar by now, the text cautions us to test and
update a DRP as often as we can. When reviewing a DRP, make sure to
review the systems, assets, and locations that are parts of it, to
determine whether changes in them require changes in the DRP.
The text explains, in more words than it takes, that a DRP reduces risk by reducing the impact of a disaster. A good plan keeps us going, and puts us back in working order as soon as possible.
The best practices mentioned at the end of the chapter should sound very familiar:
The last chapter in our first text presents another opportunity to misunderstand the author. He tells us that there is no difference between a computer incident and a computer security incident. This is not so in all organizations, and it is not so in the one where I work. We call the part of our help desk that handles calls about problems with computers our Incident Response Team. What my organization calls incidents, the text calls events. We have a separate division that deals with computer security issues. Customized terminology is not a useful thing if you and I call the same things by different names. In the context of this chapter, the author is only talking about the people and procedures that address computer security incidents, not the day to day problems that are also called incidents by people taking calls at a general help desk.
So, in the context of the author's terminology, a computer
incident is a violation of a security policy or a security practice.
The organizations where you will work may or may not have the same
The text offers a short list of examples of security incidents:
In the context of the chapter, we are talking about the creation of a Computer Incident Response Team plan. (Again, he is talking about security incidents. I wish he would use the word more often. Our second text refers to this team as the Security Incident Response Team. And both acronyms would be pronounced the same way.) On page 403, the text discusses the purpose of this plan: to prepare for security incidents. That is a very broad concept, considering the variety of security incidents that can occur. The author sensibly proposes that we begin dealing with an incident by seeking to understand what is happening. He suggests using a familiar framework. Explain the situation in terms a reporter would use. A good idea is to memorize a line from Rudyard Kipling about six honest serving men:
(The rest of the poem is not important in this context. Yes, you should read poetry. And science fiction, and detective stories, and lots of other things. In case you don't know, Kipling was a soldier, a poet, a writer, and a reporter. A human being should be able to do many things.)
In the context of this chapter, we are asking:
The text moves on to the elements of a CIRT (SIRT, CERT, etc.)
plan. We are informed that a plan
should list people (or job roles) that will be involved,
and should include information on the policies
that will be enforced by this staff.
The text describes three models from NIST SP 800-61 Revision 2, which relate to organizing your CIRT staff with different scopes of authority and responsibility.
The list of roles on page 406 may bear no resemblance to the
roles you may see in an actual organization. The lesson to take from
the list is that there are many jobs in large organizations, some of
which are quite specialized, but everyone contributes in some way to
the security of those organizations. CIRT staff are more directly
involved in security than HR staff, but everyone participates in
his/her own security experience.
The list of duties on page 407 captures the essence of what people working in this field do:
In addition to these bullets, the text offers three suggestions on page 408 about investigating: acquire evidence, authenticate the evidence (prove it is what you say it is), and analyze the evidence.
The text provides a lengthy discussion of policies and procedures that guide the actions of a CIRT employee. Note the discussion on page 408 about attacking an attacker. This might make sense to many of us, but the reality is that counter attacking may only increase the animosity of the attacker. Our objective is to defend, which is often best done without emotional investment. Some advice is offered for specific types of frequently seen attacks:
The chapter ends with some recommendations for best practices: